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

[Martin Egholm Nielsen]

>>> 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 reckon that too, yes.
>> However, I'm little afraid of doing so due to the note "Package 
>> visible for use by nested classes".

> Don't worry about that, this comment is just to remind us that the 
> package visibility is there to improve performance when it is accessed 
> by keySet, IdentityIterator, etc.
Ok, but the task is not trivial (well, maybe it is, but tedious). 
Besides put() and get(), it requires modification and handling in the 
internal classes, IdentityEntry and IdentityIterator. And maybe other 
places - hash()... Needs some study before doing so :-)

But I think I will - that'll save me some 20-40 ms, as well.
(But I guess stripping libgcj.jar even further could give that, as well 
- knowing now that every method is registered there.)

>> In my situation, a stacktrace is seldom (if ever) needed - unless I 
>> misinterpret the term "stacktrace" as being only the stuff comming 
>> from "printStackTrace()" on an Exception?!
> Yes, there are various places, other than Exceptions, where stack 
> inspection is needed. Often, a method needs to find out who called it. 
> Security checks are one example, but there are others. eg: 
> ResourceBundle does this in order to determine what classloader should 
> be used to load a resource.
Eeeew. Ok - I'll abandon that idea for now, then...

Thanks for all the help! I'll return with the outcome soon ;-)

// Martin