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