[Gc] PRINT_STATS kind, and free_space_divisor

Rutger Ovidius r_ovidius at eml.cc
Sat Nov 20 17:42:41 PST 2004


I use gcj, but this is mostly a GC inquiry. I would like to better
understand GC_PRINT_STATS output.

In the section (gc.log):

***Blocks in use:
(kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, #_marks_set)

(side note: maybe this should be "..%lu=stubborn, STUBBORN.." since 3
isn't stubborn on win32?)

I can't figure out what kind=6 are.  When my app first starts I notice
it has one:

But later I see it develops another:

What might these be?
Also, is there a convenient way to figure out what is occupying the
larger items?  Most of my items have a size of 16, 96 or 112.  There
are a few like:

(0:101024,1) (1:131072,1) (0:37744,1) (0:37960,1) (0:38680,1)
(0:38680,1) (0:38680,1) (0:38692,1) (0:399368,1) (0:41660,1)
(0:41772,0) (0:41772,0) (0:42228,0) (0:43080,0) (0:43152,0)
(0:43428,0) (0:43640,0) (0:44004,0) (0:44492,0) (0:44564,0)
(0:44680,0) (0:448,5) (0:44952,0) (0:45064,0) (0:45064,0) (0:45064,0)
(0:45416,0) (0:45988,0) (0:46092,0) (0:46384,0) (0:47392,0)
(0:47392,1) (0:50684,0) (0:50684,0) (0:50684,1) (0:512,4) (0:512,8)
(0:51908,0) (0:55200,0) (0:55200,0) (0:55200,0) (0:67268,1)
(0:67268,1) (0:680,5) (0:77352,1) (0:77352,1) (0:77352,1)

which look suspiciously large to me (a few with exact duplicate sizes,
and sizes which I don't find in any of my app's java objects under a
java profiler). How can I go about better examining things larger than
25000 or so and finding out what they are?

My second question deals with the free_space_divisor setting. I set it
larger than the default (10 or so) and my app seems to collect ram
better while "idling" which mostly means creating/destroying many temp
objects (strings) and more quickly reclaims space. But once it needs
to quickly create a large number of permanent objects this seems to
cause a ton of repeated GCs which kills the cpu and very noticably
slows down this gui app.

Is this due to the Static root size of: 15507456 (a gcj/libjava
problem I'm told)? Would there be any other setting I can adjust to
obtain semi-aggressive collections unless there is a large heap
quickly needed? (I am thinking that if 2 or 3 GCs occur within a certain
timespan, the free_space_divisor can dynamically decrease which would
allow a larger heap to be created and less subsequent GCs and no more
killer CPU use while expanding the heap by X megs... but perhaps this
is the wrong way to think about it?) I don't have any runtime access
to the GC via GCJ as far as I know so I'm looking for a compile time


Rutger Ovidius

More information about the Gc mailing list