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