GC/Heap usage

Rutger Ovidius r_ovidius@eml.cc
Sun Nov 7 23:59:00 GMT 2004


Hi,

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
control.

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
profiler.

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):
http://tinyurl.com/3krqe

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.

Regards,
Rutger Ovidus



(I also notice a bunch of lines like the following in my gc.log. Are
they problems?)

Leaked composite object at start: 0x13c5290, appr. length: 16
Leaked composite object at start: 0x13ff920, appr. length: 584
Leaked atomic object at start: 0x13fe190, appr. length: 40

Since it is windows, I also have a lot of kind=4 type of objects being reported.  
I'm not exactly sure if that is bad or not.

(kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, #_marks_set)
...(4:48,7)(4:16,224)...






More information about the Java mailing list