InvokeDynamic PIC Slowdown (deopt issue?) need advice

[Jochen Theodorou]

On 23.07.2016 01:25, John Rose wrote:
> On May 31, 2016, at 12:41 PM, Mark Roos <mroos at roos.com> wrote:
>>
>> It looks like, from some fine timing, that each time the Smalltalk class changes there is a large amount
>> of time added to the call.  Which I would expect if there was a deopt whenever a different GWT triggered.
>> There are 6 GWTs in this chain ( idleValue can be one of six Smalltalk classes).
>
> Has anybody on this list played with using a short @Stable array to represent a PIC?
> Editing the PIC would involve changing the array instead of recompiling a call site.

How about making a list of all those annotations that influence 
invokedynamic and inlining? And how likely is it that some of them get 
promoted to official API? And will they be available in JDK9 to non-JDK 
modules?

> The effect would be to preserve existing inlinings of the PIC site (unless they
> self-invalidate) but allow the PIC to update itself over time as new cases arise.
> Previously compiled uses of the PIC would stay optimized as-is.
 >
> The @Stable array would always have a series of zero or more non-null entries,
> followed by at least one null entry.  The search in the @Stable array would inline
> and short-circuit over irrelevant PIC entries, if the pattern-matching logic were
> inlinable.  Entries could be as simple as @Stable 2-arrays of guard MH and target MH.
> (If they are objects, some care with TrustFinalFields would also be needed.)

which means you cannot reorder, nor can you evict the oldest handle

> Using this technique would probably lead to fewer deopts.  The @Stable array could
> also be shared by several PIC sites, if that helps with footprint.
>
> class PIC {
>    @Stable final MethodHandle[][] cache = new MethodHandle[PIC_SIZE+1][];
>    // cache[0] = new MethodHandle[] { guard, target }, etc.
>    // cache[cache.length-1] is either null or some permanent catch-all logic
> }

I would have expected a MethodHandle[] only. The documentation of stable 
is also not so clear to me here. is assumed to be stable, allows only 
setting the element of an array with a stable element... ok... but a 2D 
array is an array of arrays. So the stable values are the arrays itself 
and they are not stable? I wouldn´t have expected this to work.

bye Jochen