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

[Martin Egholm Nielsen <martin at egholm-nielsen dot dk>]

> > > 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.
I'll say :-)
But luckily Rutger saw it before I wasted anymore time!

> 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 reckon that too, yes.
However, I'm little afraid of doing so due to the note "Package visible 
for use by nested classes". Changing this to null, and vice versa for 
null-values, may break the use from classes within the package - 
although scanning all the .java files in java.util didn't seem to reveal 
any use at all.

> > 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.
That was actually my idea, yes. I would cache any MethodRef that is used 
by a stacktrace (by looking up every initialized class, yes). After a 
heavy duty transient, this cache should be super small but represent all 
steady-state stacktrace needs.
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?!

// Martin - still happy about having found the solution!