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

[Martin Egholm Nielsen]

>> 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?
Well, not that easily on target, but maybe on my desktop i686...

> 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.
I could certain live without stack-traces (at least in final build), but 
"calling-classloader" check?

> 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.
This is indeed a large application, but only small parts of the code is 
actually "active" when the array of 21k is registered, and close to no 
stacktraces (maybe the first stack-trace is responsible for the initial 
registration?).
However, the alarming, and supporting your "something is going wrong 
here" theory, is that the array increases suddenly by a factor of 8 "out 
of nowhere" (requires "touching" some [though different] parts of the 
application)...

In really short terms the application is an embedded multithreaded 
webserver with http(s) support for webservices (using GNU-Crypto and 
Jessie)... Some 2000 classes (GNU-Crypto supplying many of these)...

// Martin