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

Martin Egholm Nielsen martin at egholm-nielsen.dk
Sat Apr 1 03:57:35 PST 2006

>> 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 ...
>>     }
>> }
> For now I'm take "something like" as "exactly like" (though with "0 !=" 
> as "0 != p").
> It compiles, and now I have a new libgcj ready for testing in the morrow 
> - so so exciting!

Well, just to finish this thread (here, at least): After hours of 
searching, printf'ing, and caching the above pointer and printing in 
non-gc-locked context, I (we [all of you - thx]) finally managed to 
identify the nature of the array-"octa"-doubling as a 1½ years old bug 
in a gcj class (IdentityHashMap).
This doubling was triggered when new classes were initialised and 
suddenly triggering a magic threshold in the map. That's why the problem 
could be provoked by touching various regions of my application.
This wouldn't matter anything, if the content of the empty map was 
null-pointers, but it is not. Empty map entries were filled with a 
specific class instance to allow for null entries. Hence growing the map 
by a factor of eight made the GC work eight times the more - being 
responsible for the additional 180 ms.
Now, fixing/implementing the old bug/fix has now saved me ~150 ms.

So, I'm obviously happy now, and want to thank you _Hans_ for helping me 
identifying the nature of the problem! And thanks for your patience...


More information about the Gc mailing list