InvokeDynamic PIC Slowdown (deopt issue?) need advice

[John Rose]

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.

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.)

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
}

— John