GC/Heap usage

Mon Nov 8 19:41:00 GMT 2004

Hi,
Monday, November 8, 2004, 9:57:40 AM, you wrote:
BH> Looking at the log, some other things stand out:
BH> 1) The collector is tracing 15 MB of roots. Somehow it's finding
BH> 15 MB of writable and accessible data segments outside
BH> the GC heap. A lot of that seems
BH> to be in 4K and 8K sections. There is no way for the collector
BH> to both maintain a reasonable heap size and get reasonable
BH> performance in light of that. By default it will tend to grow
BH> the heap to amortize the tracing cost over more allocation.
Pardon my ignorance of GCs, but are you saying something is wrong? If so,
where? In the GC? In the app? In the way gcj is using the GC and
marking things? What determines what is a root? Is there something I can do?
Does 15MB of roots seem incorrect? Would it be the same in sun's java
(why does it perform well in sun's java)?
BH> 2) Where are the "Leaked ..." messages coming from? Those
BH> should only be generated with leak finding turned on, which really
BH> only makes sense for C or C++ programs that attempt to explicitly
BH> deallocate all unused memory. If that accidentally got turned on,
BH> I'm very surprised there aren't many more such messages. (Turning that
BH> on also has other negative effects on the GC, but I'm not sure they
BH> should be major.)
The gc.log was created with env variables print_stats and
dump_regularly, but might have also had find_leak (I was trying to get
as many stats as possible). The app's mem use is the same
according to task manager with these env variables off. Performance is
certainly noticably slower with them on though.
I still don't know what to conclude about the Leaked lines... should
they be ignored since this is java?
BH> 3) The "ready-to-be-finalized" list seems to be long and getting
BH> longer.
BH> Hans
Again, I'm not sure what I am to conclude from this. What can I do?
All I know is that the app is well behaved in java and profiles
without leaks. I'm trying to get the same with gcj, but have no
experience with the underlying workings of the gcj/gc.
In your opinion, would the posted suggestion to change the default
GC_free_space_divisor from 3 to something else help much?
Regards,
Rutger Ovidius