the chain would be a way to avoid the deopt. I do this now to keep some methodHandles
at the beginning of the chain but had not thought to apply it it each addition.
will give it a try
mark
"mlvm-dev" <mlvm-dev-boun...@openjdk.java.net> wrote on 07/29/2016 08:08:56 AM:
> From: Remi Forax <fo...@univ-mlv.fr>
> To: Da Vinci Machine Project <mlvm-dev@openjdk.java.net>
> Date: 07/29/2016 08:09 AM
> Subject: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
> Sent by: "mlvm-dev" <mlvm-dev-boun...@openjdk.java.net>
>
> 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
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
