On May 31, 2016, at 12:41 PM, Mark Roos <mr...@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 
Editing the PIC would involve changing the array instead of recompiling a call 

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 
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 
and short-circuit over irrelevant PIC entries, if the pattern-matching logic 
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 
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
mlvm-dev mailing list

Reply via email to