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/>