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

Thu Mar 30 19:24:00 GMT 2006

Martin Egholm Nielsen wrote:
> 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.
> 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?

This must be an older version of libgcj? The MethodRef class no longer 
exists, but in the past it was used to implement a mapping of function 
addresses to their Java Class and Method, which is needed to implement 
stack traces. The code has changed since libgcj 4.1, but the modern 
equivalent can be found in _Jv_StackTrace::UpdateNCodeMap(). Is there 
any chance you can try it with 4.1?
There should be one entry in this map for every "live" method in the 
system, that is each method in each class that has been initialized. The 
map is updated when stack traces are printed, or when another operation 
that requires stack information, such as a calling-classloader check, is 
executed.
What sort of app is this? There isn't usually anything close to 170k 
methods in any normal app, so something is going wrong here. 
synchronization/locking (or lack thereof) of the map updating code would 
be my first suspect.
Bryce