Someone registers thousands of Object's and MethodRef's (was/is: gc times doubling)

David Daney ddaney@avtrex.com
Thu Mar 30 19:11:00 GMT 2006


Martin Egholm Nielsen wrote:
> Hi,
>> I wouldn't state that I'm actually getting closer to understanding my GC 
> time-doubling problem (just track my postings), but I'm getting more 
> information.
>> _Old facts_: On my slow target my GC times are about 200ms, but suddenly 
> and out of no where, it increases to some 400ms.
> By printf-tracing the GC/libgcj source, I discovered that the increase 
> is due to a "huge" increase in an array and it's marking in 
> "_Jv_MarkArray".
> Suddenly the array increases its length from some 21.000 to (approx) 
> eight times the length - namely 170.000.
> This increases my GC times with some 200ms.
>> And I (still) don't understand why the array increases, so I begun 
> dumping info about the array content, and finally today I managed to 
> hack my intentions into "libjava/boehm.cc".
>> _New stuff_: I've only dumped the content of the small array (21.000) 
> yet, (but that is still interesting, since I don't understand the nature 
> of that one either). The content is the following:
>>> 15179 of 21504 entries are non-null (points inside feasable heap-region)
> 6326 elements are of class "gnu.gcj.runtime.MethodRef"
> 8854 elements are of class "java.lang.Object"
>>> Now, that's many MethodRef's!
> And invoking "toString()" on these elements reveals nothing of value - 
> e.g.:
>>> MEN: element 21499: java.lang.Object@10534fd0
> MEN: element 21501: gnu.gcj.runtime.MethodRef@105eb9f0
>>> Still, I know nothing of what the large array (170.000) consist of, but 
> since it "replaces" the small array (it disappears from marking when the 
> large enters the scene), I reckon it's something similar.
>>> Can anybody tell me anything of value wrt. this?
> Why the many method-ref's?
> Why doesn't toString() reveal anything of value - I would expect only 
> such Object output from java.lang.Object it self?
>The MethodRefs are used in the generation of stack traces. libgcj keeps 
a cache of them so that printing of stack traces is faster.
I think that each time each time an exception is thrown the cache can 
grow. Thus your array keeps getting bigger.
David Daney


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /