Bug 111299 - JavaModelCache may overflow the memory.
Summary: JavaModelCache may overflow the memory.
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.1.2   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-02 09:10 EDT by Guilhem Lavaux CLA
Modified: 2006-01-10 10:23 EST (History)
3 users (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 Guilhem Lavaux CLA 2005-10-02 09:10:08 EDT 
JavaModelCache assumes that the underlying VM has a finite heap. Many free VMs
(kaffe,gcj) offer the possibility to unlimit the heap. In that case maxMemory()
returns Long.MAX_VALUE. The initialization of the hashtable then overflow
irremediably the memory. I suggest to put put some limit to the ratio or at
least limit it to some value extracted from the current state of the heap if the
maxMemory() returns Long.MAX_VALUE.

A quick fix would also be to add "ratio = Math.max(ratio, 2d);"
Comment 1 Jerome Lanneluc CLA 2005-10-05 07:05:19 EDT 
Fixed JavaModelCache constructor as suggested except for the default ratio which
I set to 4d that corresponds to the 256MB that Eclipse defaults to in the
"eclipse.ini" file.

BTW, don't kaffe and gcj support the -Xmx argument defined in "eclipse.ini" ? Or
is this value just ignored by these VMs ?
Comment 2 Jerome Lanneluc CLA 2005-10-05 09:15:11 EDT 
Backported fix to R3_1_maintenance branch.
Comment 3 Guilhem Lavaux CLA 2005-10-05 12:28:10 EDT 
There is a -Xmx option. However we (gcj/kaffe) consider that it is an
interesting feature for most java applications to allow them an infinite heap.
So now this is the default behaviour. If the user wants to limit the heap he is
free to do so using the argument.
Comment 4 Maxime Daniel CLA 2006-01-10 04:35:33 EST 
Verified for 3.1.2 using build M20060109-1200.
Verified by comparing the code with previous versions.
Would suggest that 64000000 be replaced by 64Mb (but this does not affect this bug).
Comment 5 Frederic Fusier CLA 2006-01-10 05:04:17 EST 
Verified for 3.1.2 using build M20060109-1200 (maxime)
Comment 6 Maxime Daniel CLA 2006-01-10 10:23:14 EST 
Verified for 3.2 M4 using build I20051215-1506.
(On a source code basis.)