At least the PIC usual test seems to work :)
https://gist.github.com/forax/7d1c06df9546baf9d98e8c0c1f255e05
The instructions are for JDK9 and i've put the class in java.lang.invoke to
access to the annotations @Stable, @DontInline and @ForceInline.
Rémi
----- Mail original -----
> De: "John Rose" <john.r.r...@oracle.com>
> À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net>
> 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 <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
> 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@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
