Mon Nov 8 16:51:00 GMT 2004
Rutger Ovidius wrote:
> I'm looking for a way to make the gcj GC manage my heap more similarly
> to sun's java. Heap use seems tremendously excessive with my app
> (compared to java) and I'm out of ideas on how to keep it under
> I compile with gcj win32 gcc version 4.0.0 20041014 (experimental).
> I let 3 instances of my app run for a few hours. One is gcj compiled,
> one is normal sun's java, and one is under borland optimizeit
> It creates/destroys many strings and other temp objects every second
> of use; it also uses WeakHashTable for weak references. A pretty
> normal app. It looks very well behaved under borland's profiler.
> Collections of all these temp objects occurs regularly with no leaks.
> In Windows XP Task Manager (to compare memory use):
> app.exe is the app compiled with gcj,
> java.exe is the app running under sun's java.
> app.exe Mem Usage: 52,744k VM Size: 46,908k
> java.exe Mem Usage: 19,072k VM Size: 21,948k
> This difference seems very excessive. I turned on the gcj GC stats,
> and from the gc.log the heap has currently grown to:
> Total heap size: 30683136
> And never seems to shrink.
> Borland's optimizeit profiler reports:
> Heap used: 2629kb, Heap size: 4724Kb.
> (wow, what a difference)
> If interested, the full gc.log is here (gc.zip 260k):
> Is there any way to get the heap to be managed more closely to the way
> sun's works? Is there something fundamentally different that would
> cause this disparity? Or perhaps some setting that would make it more
> similar? I've tried playing around with simple test apps looking for a
> 'smoking gun' cause for the crazed heap usage but have come up dry.
> Currently the app looks rather bad to people checking memory stats in
> the Win Task Manager.
> I tried to limit the gc heap size (via env variable) to 7 megs. The
> app runs for a while but I eventually get an out of memory error.
> (Why? If it only has a 5meg heap in borland's profiler I just don't
> understand this..) -- also I don't think limiting the size is the
> correct solution, nor is setting an env variable very portable.
You could try setting the variable GC_free_space_divisor to a different
value. We are running GCC-3.3.1 and have had good results in a limited
memory system with a value of 20.
We have been thinking about changing the GC so that it does not use a fixed
divisor, but instead one that increases the closer you get to the maximum
heap size. But we have not really done enough testing to know if it is
better than using a fixed but larger divisor.
More information about the Java