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