[Gc] Re: Understanding why GC'ing increases to the double in time?

Boehm, Hans hans.boehm at hp.com
Tue Mar 14 10:47:25 PST 2006


Off the top of my head, with no testing, something like

1) Remove the static declaration from gcj_describe_type_fn.  If you
can't recompile, it is in a table somewhere.  But that gets messier.

2) You might add the actual printing code to GC_print_block_descr.
Declare a buffer

char type_buf[GC_TYPE_DESCR_LEN];

When you see a sufficiently large block h with hhdr -> hb_obj_kind !=
PTRFREE, walk the beginning of the object, a word at a time, with
something like

word *p;

for (p = (word *)h; 0 != ; ++p) {
    if (GC_base(*p) != 0) {
      gcj_describe_type_fn((void *)(*p), type_buf);
	... print p and type_buf ...
    }
}

3) Continue to call GC_dump(), which should now also print this stuff.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Martin 
> Egholm Nielsen
> Sent: Tuesday, March 14, 2006 7:00 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Re: Understanding why GC'ing increases to the 
> double in time?
> 
> > I actually wasn't expecting this to be a single object.
> Heh, see what ignorance can result in :-)
> 
> > I would guess that it's an array of references.
> > 
> > The real question might be what any nonzero components point to.
> > 
> > There is a gcj_describe_type_fn function in gcc/libjava/boehm.cc in 
> > the gcc source tree, which is unfortunately declared 
> static.  It tries 
> > to write the class name for a gcj object into a buffer.  
> Invoking that 
> > on the object as a whole, and on nested pointers (e.g. words with 
> > GC_base(word) != 0) might tell you where this is coming from.
> Aheem, I have to admit I have no idea how to invoke that 
> function from within the GC code - it would have to be from 
> GCJ context (as I see it).
> Help?
> (I tried dumping the object char for char, but that didn't 
> result in anything helpfull - at least not the way I did it, anyway)
> 
> > I think your best hope is that there will be an easy way to avoid 
> > allocating this object.
> I vote for this approach.
> 
> However, I still think it is funny that the moment the large 
> composite object appear, the next-to-largest from before disappears:
> 
> === Small ===
>      MEN adding composite with size 8192
>      MEN adding composite with size 128
>      MEN adding composite with size 128
>      MEN adding composite with size 340
>      MEN adding composite with size 340
>      MEN adding composite with size 146
>      MEN adding composite with size 146
>      MEN adding composite with size 256
>      MEN adding composite with size 128
>      MEN adding composite with size 128
> --> MEN adding composite with size 21506
>      MEN adding composite with size 769
>      MEN adding composite with size 1127
>      MEN adding composite with size 128
>      MEN adding composite with size 256
>      MEN adding composite with size 204
>      MEN adding composite with size 128
> 
> === Large ===
>      MEN adding composite with size 8192
>      MEN adding composite with size 128
>      MEN adding composite with size 128
>      MEN adding composite with size 340
>      MEN adding composite with size 340
>      MEN adding composite with size 146
>      MEN adding composite with size 146
> --> MEN adding composite with size 172034
>      MEN adding composite with size 256
>      MEN adding composite with size 128
>      MEN adding composite with size 128
>      MEN adding composite with size 769
>      MEN adding composite with size 1127
>      MEN adding composite with size 128
>      MEN adding composite with size 256
>      MEN adding composite with size 204
>      MEN adding composite with size 128
> 
> and the rest of the composites (>100) can be matched one-to-one.
> Further, the the composite of word-size 21506 appear 
> extremely early in the application, before anything has been 
> done, actually (some few Java API invocations - but no one 
> specific)...
> 
> Don't know if this has anything to say?!
> 
> // Martin
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list