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"
wrote:
>On May 31, 2016, at 12:41 PM, Mark Roos 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
Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
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)"
> À: "Da Vinci Machine Project"
> 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"
>
> wrote:
>>On May 31, 2016, at 12:41 PM, Mark Roos 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
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 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)"
>> À: "Da Vinci Machine Project"
>> 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"
>>
>> wrote:
>>>> On May 31, 2016, at 12:41 PM, Mark Roos 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
Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
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"
> À: "Da Vinci Machine Project"
> 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 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)"
> >> À: "Da Vinci Machine Project"
> >> 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"
> >>
> >> wrote:
> >>>> On May 31, 2016, at 12:41 PM, Mark Roos 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
Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
In my perfect world a pic looks like this at the lowest level mov object field ==> eax je eax=test1 to implementation1 " the special GWT you mention " je eax=test2 to implementation2 ... handle miss I would want to move the testN order to optimize, replace implementations, and of course extend the list without lots of overhead or deopt. The question is how to get the JIT to emit code like this. I was thinking that I may have to wait for Panama to give me a way to insert the code directly and then hoping its fast. But maybe the array idea has merit. mark p.s. Perhaps for small PICs ( the majority ) cpu branch prediction could help ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
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"
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)"
>>
>> À: "Da Vinci Machine Project"
>> 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"
>>
>> wrote:
>>>On May 31, 2016, at 12:41 PM, Mark Roos 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
Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
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)" > À: "Da Vinci Machine Project" > 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" > 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)" >>> >>> À: "Da Vinci Machine Project" >>> 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" >>> >>> wrote: >>>>On May 31, 2016, at 12:41 PM, Mark Roos 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 >>>>
Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
Interesting, thx, I was just this morning thinking that adding the new GWTs to the end of 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" wrote on 07/29/2016 08:08:56 AM: > From: Remi Forax > To: Da Vinci Machine Project > Date: 07/29/2016 08:09 AM > Subject: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > Sent by: "mlvm-dev" > > 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)" > > À: "Da Vinci Machine Project" > > 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" > > 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)" > >>> > >>> À: "Da Vinci Machine Project" > >>> 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" > >>> > >>> wrote: > >>>>On May 31, 2016, at 12:41 PM, Mark Roos wrote: > >>>>> > >>>>> It looks like, from some fine timing, that each time the Smalltalk > >>>>>class changes the
