yes, an array of a special kind of GWT, which unlike a GWT doesn't have a fallback, only a test and a target.
Rémi > De: "Mark Roos" <mr...@roos.com> > À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > Envoyé: Lundi 25 Juillet 2016 18:12:25 > Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > Or maybe an array of GWTs? > Sent from my iPhone > > On Jul 25, 2016, at 9:04 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > Hi Duncan, > > you should see this technique as a new method handle combiner, >> it can be integrated easily with with the rest of java.lang.invoke, CallSite, > > SwitchPoint, etc. >> and by the way, the code i've provided has a race issue, two threads can >> changes > > the two arrays at the same time, >> maybe, it should be implemented with an array of couples instead with a >> couple > > of arrays. > > Rémi > > ----- Mail original ----- > >> De: "MacGregor, Duncan (GE Energy Connections)" <duncan.macgre...@ge.com> > >> À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > >> Envoyé: Lundi 25 Juillet 2016 11:40:51 > >> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > >> I like the idea of this, but I¹m not sure it can be applied to Magik due > >> to the ability for methods to redefined and hence our PICs to be > >> invalidated. I¹ll have a look though, there might be a couple of places I > >> could try prototyping this. > >> Duncan. > >> On 23/07/2016, 00:25, "mlvm-dev on behalf of John Rose" > >> <mlvm-dev-boun...@openjdk.java.net on behalf of john.r.r...@oracle.com> > >> wrote: > >>>> 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 > >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_ > >>> mailman_listinfo_mlvm-2Ddev&d=CwIGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUr > >>> LrDQYWSI&r=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE&m=VNUQiU3bdwDRsoH6K > >>> VkNR_qOt5a2CDuOQTPk7SSpf5E&s=tOHi6W_nCiTp7Q_l9pyafMNesDW3zc0wOWk-v4sZkHc&e > >>> = > >> _______________________________________________ > >> 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 > _______________________________________________ > 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