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

Hans Boehm Hans.Boehm at hp.com
Mon Mar 13 10:26:26 PST 2006

I actually wasn't expecting this to be a single object.

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.

I think your best hope is that there will be an easy way to avoid
allocating this object.  It may be hard to get the collector to reclaim
one specific object, since the pointer to it may happen to fall into some
stack slot that happens to not be overwritten for a long time.  Garbage
collectors, particularly conservative ones, tend to do much better when
you don't care about small fixed numbers of objects staying around.  I
guess, if worse comes to worse, you can make a CNI call to GC_free,
but that's really ugly.


On Mon, 13 Mar 2006, Martin Egholm Nielsen wrote:

> >> It may well be that your operation A allocates and drops a moderately
> >> large strongly-connected data structure, and operation B stores some
> >> large integers in a place in which they are conservatively scanned, and
> >> appear to point to the first data structure.  There are probably other
> >> possible scenarios along these lines, and some of them probably involve
> >> real pointers, instead of misidentified ones.
> > My pursue continues, and I'm now able to provoke it by taking operation
> > A (the complex one) out of the picture, and invoking some other rather
> > simple operation C.
> > That made me suspect that the dropping of "large strongly-connected data
> > structure" you're referring to in the above, is something I drop during
> > the initialisation of my application.
> > However, I tried removing some things in order to make the init-phase
> > simpler, but nevertheless - I still get the 600k composite increase.
> >
> > So, I guess I'm kinda stuck until I get a hint to what these extra 600k
> > may consist of, or some other ideas :-)
> For what it's worth I now added a printf statement to ADD_TO_COMPOSITE:
> #   define ADD_TO_COMPOSITE(sz) \
> { \
> GC_composite_in_use += (sz); \
> if ( sz > 100 ) GC_printf1("MEN adding composite with size %lu\n", (sz) ); \
> }
> and there is indeed a single increase for one object:
> === Small time ===
>      MEN adding composite with size 21506
> === Large time ===
>      MEN adding composite with size 172034
> And this increase does indeed accommodate for the ~600k bytes.
> And maybe I can just dump this object - byte for byte - to see what it is?
> // Martin
> _______________________________________________
> 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