Bug 99114 - [search] OOM Exception in Java search
Summary: [search] OOM Exception in Java search
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
: 112652 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-09 05:19 EDT by Martin Aeschlimann CLA
Modified: 2006-03-28 10:45 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Aeschlimann CLA 2005-06-09 05:19:36 EDT 
20040509-0010

- new workspace
- use plugin-importer to import jdt.core _with sources_
- open search dialog, type 'java.lang.String', type references

OOM reached shortly after starting
Comment 1 Martin Aeschlimann CLA 2005-06-09 05:41:06 EDT 
from a memory snapshot taken while searching it seems that there is a big array
elements of PossibleMatch still containing the 'parsedUnit'
Comment 2 Frederic Fusier CLA 2005-06-09 05:57:52 EDT 
I guess it's N20050609-0010 (not 200505) and that you haven't set -Xmx vm args 
value.

It seems that -Xmx default value comes back to 64Mo instead of 256Mo in previous
build...
Comment 3 Frederic Fusier CLA 2005-06-09 06:00:02 EDT 
Move to Platform/Runtime for comment
Comment 4 Pascal Rapicault CLA 2005-06-09 06:52:59 EDT 
Will investigate
Comment 5 Frederic Fusier CLA 2005-06-09 10:36:12 EDT 
I used a batch which wrongly -vmargs with no parameter for default...
=> it's not a Platform issue
=> back to JDT/Core
Comment 6 Frederic Fusier CLA 2005-06-09 11:44:21 EDT 
Martin,
I only can reproduce this bug with "-vmargs -Xmx64M" or "-vmargs" (without
parameter) in my command line which launches eclipse executable.
If I have no -vmargs at all in my cmd line, search ends correctly (with heap
size at 105Mo). Could you confirm this?
If so, I'll put this bug in LATER and look at it as soon as 3.1 will be delivered...
Thx
Comment 7 Martin Aeschlimann CLA 2005-06-09 12:00:11 EDT 
Confimed. I also used -vmargs without parameters.
Comment 8 Frederic Fusier CLA 2005-06-09 12:08:30 EDT 
OK, thanks
So, defer post 3.1 but set as P2 to restart on this issue asap...
Comment 9 Frederic Fusier CLA 2005-08-05 03:58:04 EDT 
Reopen for 3.2
Comment 10 Frederic Fusier CLA 2005-10-14 12:24:54 EDT 
*** Bug 112652 has been marked as a duplicate of this bug. ***
Comment 11 Frederic Fusier CLA 2006-03-14 12:03:15 EST 
Fixed and released in HEAD.

To optimize speed of search, search engine tries to locate matches of all documents found in each projects of the given search scope. The speed optimization comes from the fact that bindings are completed only once on all project compilation units.

Of course, as there can be a lot of documents per project, this optimization was limited by a maximum of 400 documents per loop to avoid OOME. This was correct for default Java Heap size but not for smaller ones...

Change MatchLocator.MAX_AT_ONCE static field value to make it dependent of Runtime.maxMemory() value.

New values for this static field are:
Heap size  MAX_AT_ONCE
[0,96M[        100
[96M, 160M[    200
[160M, 218M[   300
[218M , oo[    400

No test case added, just verified that comment 0 scenario does no longer occur...
Comment 12 Olivier Thomann CLA 2006-03-28 10:45:14 EST 
Verified using I20060328-0010 for 3.2M6.
Doesn't go above 160M.