In fact, you don't need an array of @Stable values to emulate to write a PIC that doesn't deopt when it should not, here is a code that uses method handles / mutable call sites that achieve the same result, not de-optimizing an inlining blob that doesn't see a new receiver class when another inlining blob see a new receiver class, the two blobs sharing the same PIC.
https://gist.github.com/forax/5876d900cad800d3445f7a07d2daef52 The method createPIC create a PIC from a method type and a code that should be run if the receiver has a class not seen before. Instead of adding a GWT in front of the other when a new receiver class is found, it inserts the GWT after the others GWTs. It works that way, when a PIC is first created, it's just a mutable callsite that has the the deopt lambda as target, thus, the first time the PIC is called the deopt lambda is called. This lambda takes a Control object that takes a test method handle and a target method handle as discussed with Mark (Roos), when the control object is called, it changes the target of the current mutable callsite, installing a GWT with the test, the target and as fallback called recursively createPIC that install a new mutable callsite that by default calls the deopt lambda. The test code is the same as the one that was testing the PIC using two stable arrays and the compilation trace shows that the PIC is rightly inlined in the two test methods (test and test2) and that when only test() see a new receiver, test2 is not make non re-entrant by the VM. cheers, Rémi ----- Mail original ----- > De: "MacGregor, Duncan (GE Energy Connections)" <duncan.macgre...@ge.com> > À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > Envoyé: Mardi 26 Juillet 2016 12:29:59 > Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > D’oh! Yes, it’s perfectly usable for my purposes with just one level of > indirection, I can always invalidate the whole PIC. :-) > > In fact, I’ve pretty much got this code lying around already, it just > needs the annotations slapped on it, and it’s already thread safe. Doubt > I’ll have time to really experiment with it this week though, few too many > other things to get done before JVMLS. > > Duncan. > > On 25/07/2016, 17:03, "mlvm-dev on behalf of Remi Forax" > <mlvm-dev-boun...@openjdk.java.net on behalf of 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.ne >>>>t_ >>>>mailman_listinfo_mlvm-2Ddev&d=CwIGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3w >>>>Ur >>>>LrDQYWSI&r=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE&m=VNUQiU3bdwDRsoH >>>>6K >>>>VkNR_qOt5a2CDuOQTPk7SSpf5E&s=tOHi6W_nCiTp7Q_l9pyafMNesDW3zc0wOWk-v4sZkHc >>>>&e >>>>= >>> >>> _______________________________________________ >>> 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_RiV3w >>>UrLrDQYWSI&r=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE&m=j6UFPVZYyrZFKp >>>b86Mngk1T8QcorAG4j-ML_cpvVUhI&s=RFwWQvDdQhxNJ6u9N3FRoX4WxnUO-am20ogX_nlLo >>>PQ&e= >>_______________________________________________ >>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=j6UFPVZYyrZFKpb86 >>Mngk1T8QcorAG4j-ML_cpvVUhI&s=RFwWQvDdQhxNJ6u9N3FRoX4WxnUO-am20ogX_nlLoPQ&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
