GC/Heap usage

Mon Nov 8 23:15:00 GMT 2004

Monday, November 8, 2004, 1:04:29 PM, you wrote:
>> From: Rutger Ovidius [mailto:r_ovidius@eml.cc]
>> 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> It's probably not an easily fixable bug, but something we need to work on.
BH> On Linux, I see static data areas of up to about 5MB with relatively small
BH> apps. I consider this to be a problem, and we've talked about getting the
BH> GC better root information.
I hope it is still being talked about? Sounds rather important.
BH> Does your app loads lots of dlls? Is it known to need lots of static data,
BH> especially in native code? The collector will currently trace that.
It only uses swt.dll (eclipse.org). AFAIK, there isn't any excessive
amount of static data (but I could be wrong).
BH> Part of this also seems due to gcc leaving things writable that shouldn't
BH> be written by the application itself.
BH> People with more Windows experience might no more about exactly where all
BH> of this is coming from.
>>>> 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.
BH> It means I'm even more suspicious of WeakHashMap, or something related to it,
BH> and I need to find some time to look there ...
Ok.. you think it is the sole cause of the long
"ready-to-be-finalized" list? Is there a way to tell where they are
coming from (are they all the same type/size or something?)
WeakHashMap seems to be the culprit for many things lately. Well..
I'll anxiously await what you discover.
>> 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?
BH> It will probably help with the space issue. It will probably cause your
BH> app to spend more CPU cycles in the GC, though. That may be a good trade-off.
BH> Hans
I'll give this a shot soon and see what happens. Thanks.
Regards,
Rutger Ovidius