At least the PIC usual test seems to work :)

The instructions are for JDK9 and i've put the class in java.lang.invoke to 
access to the annotations @Stable, @DontInline and @ForceInline.


----- Mail original -----
> De: "John Rose" <>
> À: "Da Vinci Machine Project" <>
> Envoyé: Samedi 23 Juillet 2016 01:25:32
> Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

> On May 31, 2016, at 12:41 PM, Mark Roos <> 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
> _______________________________________________
> mlvm-dev mailing list
mlvm-dev mailing list

Reply via email to