Mon Nov 8 21:05:00 GMT 2004
> From: Rutger Ovidius [mailto:firstname.lastname@example.org]
> 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)?
It's probably not an easily fixable bug, but something we need to work on.
On Linux, I see static data areas of up to about 5MB with relatively small
apps. I consider this to be a problem, and we've talked about getting the
GC better root information.
Does your app loads lots of dlls? Is it known to need lots of static data,
especially in native code? The collector will currently trace that.
Part of this also seems due to gcc leaving things writable that shouldn't
be written by the application itself.
People with more Windows experience might no more about exactly where all
of this is coming from.
> 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 noticeably 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?
You should ignore them. I might need to worry about why there aren't
more of them, but GC_find_leak should never be turned on for 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.
It means I'm even more suspicious of WeakHashMap, or something related to it,
and I need to find some time to look there ...
> 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?
It will probably help with the space issue. It will probably cause your
app to spend more CPU cycles in the GC, though. That may be a good trade-off.
More information about the Java