[Gc] PRINT_STATS kind, and free_space_divisor

Boehm, Hans hans.boehm at hp.com
Mon Nov 22 10:37:10 PST 2004

I just fixed the "3=stubborn" problem in my tree.  Thanks for the
bug report.  (The "stubborn" kind is going away in 7.0, so I applied
a different fix there.)

A large free_space_divisor setting will have the effect you describe.
The gcj root size really needs to get fixed.  You might try adjusting
it dynamically, if you know that you will be going through a phase
during which very little memory is dropped.

(If you want to understand more about where the 15MB of roots are
coming from, check whether your version of the GC checks
DEBUG_VIRTUALQUERY in dyn_load.c.  If so, you can turn that on,
which will produce tons of output.  It looks like the collector
might be able to ignore segments of type MEM_MAPPED(0x40000).
If you see a large number of those, it's easy to patch the
collector to get rid of them.  That will either improve matters,
or cause a crash.  I would guess it will improve matters, but it
would be great to find out either way.  Unless I hear complaints,
gc7.0alpha2 and later will start to ignore MEM_MAPPED segments.)

The rest of this is gcj-specific:

Kind=6 probably refers to Java arrays with more than 16K elements.
Kinds can be created dynamically by the client (through an interface
that's slowly getting less obscure).  This gives Java a way to register
it's own tracing procedure for such arrays, which skips the initial
size field.  (For smaller arrays, we cheat, since we assume that
such sizes can't look like addresses anyway.  Thus the default
conservative scan costs nothing and is faster.)  See _Jv_AllocArray
in gcc/boehm.cc.

The other large objects are probably also Java arrays.  If you really
want to find out what's in them, you'll need to use a debugger.
Setting a suitable conditional breakpoint in GC_print_block_list with
the environment variable GC_DUMP_REGULARLY set, should get you to the
right place.  IIRC correctly, you can get a fair amount of information
by following the vtable pointer in the zeroth slot of the object.

(On other platforms, the heap debugging facilities might also tell you
what you want to know.  But you'd need support for GC stack traces,
which I don't think currently work on Windows.)


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Rutger Ovidius
> Sent: Saturday, November 20, 2004 5:43 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] PRINT_STATS kind, and free_space_divisor
> Hi,
> 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:
> (6:86024,1)
> But later I see it develops another:
> (6:25692,1)
> (6:688136,1)
> 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
> solution.
> Thanks.
> Regards,
> Rutger Ovidius
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list