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

Fri Mar 31 17:00:00 GMT 2006

Martin Egholm Nielsen wrote:
>> MEN> Suddenly the array increases its length from some 21.000 to 
>> (approx) MEN> eight times the length - namely 170.000.
>> MEN> This increases my GC times with some 200ms.
>> Sounds related to this:
>> http://gcc.gnu.org/ml/java/2004-11/msg00153.html
> Arrghh!! It's more than related - it is identical to that posting! :-)
> Hahhahaha! I feel like such a fool - rediscovering a 2 year old bug!

Wow, I had totally forgotten about that one. Pity that the fix was never 
put into 3.4.
Another optimization that I think could be made here:
 /**
 * This object is used to mark empty slots. We need this because
 * using null is ambiguous. Package visible for use by nested classes.
 */
 static final Object emptyslot = new Object();
Instead of using an Object to represent empty slots, we could use "null" 
to represent empty slots and an Object to represent the "null" key. This 
would at least avoid the Array.fill() calls, and it sounds like it 
should be more efficient for marking too.
> I would consider making this different, or disabling the registration 
> of MethodRef, at all. Or maybe only do partial caching: only cache the 
> MethodRef actually being used!
Only Methods from classes that are used (initialized) should be in 
there. This is not a cache, its a map - every method that could 
potentially be on the stack must be in there in order for the stack 
trace to work. There's no other way to find them unless you want to 
traverse through every initialized class for every stack frame.
Bryce