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
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
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 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
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
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
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
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: InvokeDynamic PIC Slowdown (deopt issue?) need advice
On Jul 24, 2016, at 3:41 PM, Mark Roos wrote: > > A few questions on implementation. > > My old prototype looks like: > private RtObject[] _mDicts = new RtObject[8]; // array of > method dicts > private MethodHandle[] _methods = new MethodHandle[8]; // the > code MH > MethodHandle lookupSelf(RtObject rcvr, RtCallSite site) > RtObject methodDict = rcvr.classField(); > if(_mDicts[0] == methodDict) return _methods[0]; > if(_mDicts[1] == methodDict) return _methods[1]; > > If I fill the arrays I treat them as a circular buffer and overwrite the > existing contents. > > You mention the need for the last element in the arrays to be null. Why? It doesn't; I was thinking of a doubtful loop shape improvement. In you code, there's no loop at all. > If the arrays are declared 'Stable' does this mean that when I fill them I > cannot reuse them? Would > I just replace the arrays with new ones? The documentation for Stable (which is not a standard feature yet, and may not become one) says you are only allowed to set a stable array (any level of structure, from root to leaf) exactly once. The JIT avoids constant folding the stable array structure until it sees a non-default value. If you then change a non-default value to another value, you've broken the rules. Perhaps the real rule is that you have to be willing to live with any of the (non-default) values that the JIT chooses to constant-fold. In any case, that's operationally what the JIT provides for you if you use Stable values. The above set of rules or non-rules is only half-baked. That's why Stable is not a feature. It's merely an internal optimization. > You also mention a concern if the test items are Objects vs MethodHandles. > My test MH does the same > object reference compare and I was trying to avoid executing the > rcvr.classField() for each test. Would > I be better off if I used a test MH instead? If you have a clean token you can use with comparisons, that is fine. The advantage of MH's is simple: They get inlined vigorously. – John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
A few questions on implementation. My old prototype looks like: private RtObject[] _mDicts = new RtObject[8]; // array of method dicts private MethodHandle[] _methods = new MethodHandle[8]; // the code MH MethodHandle lookupSelf(RtObject rcvr, RtCallSite site) RtObject methodDict = rcvr.classField(); if(_mDicts[0] == methodDict) return _methods[0]; if(_mDicts[1] == methodDict) return _methods[1]; If I fill the arrays I treat them as a circular buffer and overwrite the existing contents. You mention the need for the last element in the arrays to be null. Why? If the arrays are declared 'Stable' does this mean that when I fill them I cannot reuse them? Would I just replace the arrays with new ones? You also mention a concern if the test items are Objects vs MethodHandles. My test MH does the same object reference compare and I was trying to avoid executing the rcvr.classField() for each test. Would I be better off if I used a test MH instead? thanks for the ideas mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
It seems to work :) Same code for the PIC, with a different test code: https://gist.github.com/forax/2ea146eacaf5608cec93e8066e9ae665 with: /usr/jdk/jdk-9/bin/java -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:+PrintCompilation -Xpatch:java.base=../classes -m java.base/java.lang.invoke.FunPIC When the deopt() is called because test() see an URL instead of a String, you can see in the trace below that just after "deopt 1", test() is "made not entrant", but you can not see the same message for test2(). So only the inline blob that see an URL is deoptimized and not all blobs that share the same PIC. very good idea, John ! i believe a PIC like that should be added to java.lang.invoke.MethodHandles. Rémi deopt 0 325 409 n 0 java.lang.invoke.MethodHandle::invokeBasic(LL)I (native) 325 410 n 0 java.lang.invoke.MethodHandle::linkToSpecial()I (native) (static) 326 411b 3 java.util.HashMap$ValueIterator::next (8 bytes) 326 412 n 0 java.lang.invoke.MethodHandle::invokeBasic(L)I (native) 326 413 n 0 java.lang.invoke.MethodHandle::linkToSpecial(LLL)I (native) (static) 327 414b 1 java.lang.invoke.MethodHandleImpl::isCompileConstant (2 bytes) 327 415b 3 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) 328 416b 3 java.lang.invoke.Invokers::checkCustomized (23 bytes) 328 417b 3 java.lang.invoke.Invokers::maybeCustomize (28 bytes) 328 418b 3 java.lang.invoke.LambdaForm$MH/1836643189::invokeExact_MT (23 bytes) 329 419 n 0 java.lang.Class::isInstance (native) 329 420b 3 java.lang.invoke.LambdaForm$BMH/429313384::reinvoke (25 bytes) 329 421b 3 java.lang.invoke.LambdaForm$DMH/344560770::invokeSpecial_LL_L (15 bytes) 330 422b 3 java.lang.Class::cast (27 bytes) 330 423b 3 java.lang.invoke.FunPIC::m (78 bytes) 331 424 !b 3 java.lang.invoke.FunPIC::test (15 bytes) 332 425 !b 3 java.lang.invoke.FunPIC::test2 (15 bytes) 335 426 !b 4 java.lang.invoke.FunPIC::test (15 bytes) 336 424 ! 3 java.lang.invoke.FunPIC::test (15 bytes) made not entrant 336 427 !b 4 java.lang.invoke.FunPIC::test2 (15 bytes) 337 425 ! 3 java.lang.invoke.FunPIC::test2 (15 bytes) made not entrant deopt 1 340 426 ! 4 java.lang.invoke.FunPIC::test (15 bytes) made not entrant 340 428b 4 java.lang.invoke.LambdaForm$DMH/166239592::invokeStatic_LL_I (15 bytes) 341 429b 4 java.lang.invoke.FunPIC::typeCheck (14 bytes) 341 430b 4 java.lang.invoke.LambdaForm$DMH/1967205423::invokeStatic_L_I (14 bytes) 343 431b 3 java.lang.StringLatin1::inflate (34 bytes) 343 432 !b 4 java.lang.invoke.FunPIC::test (15 bytes) 50 - Mail original - > De: "Remi Forax" > À: "Da Vinci Machine Project" > Envoyé: Samedi 23 Juillet 2016 12:39:08 > Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > At least the PIC usual test seems to work :) > > https://gist.github.com/forax/7d1c06df9546baf9d98e8c0c1f255e05 > > The instructions are for JDK9 and i've put the class in java.lang.invoke to > access to the annotations @Stable, @DontInline and @ForceInline. > > Rémi > > - Mail original - >> De: "John Rose" >> À: "Da Vinci Machine Project" >> Envoyé: Samedi 23 Juillet 2016 01:25:32 >> Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > >> 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 s
Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
At least the PIC usual test seems to work :)
https://gist.github.com/forax/7d1c06df9546baf9d98e8c0c1f255e05
The instructions are for JDK9 and i've put the class in java.lang.invoke to
access to the annotations @Stable, @DontInline and @ForceInline.
Rémi
- Mail original -
> De: "John Rose"
> À: "Da Vinci Machine Project"
> Envoyé: Samedi 23 Juillet 2016 01:25:32
> Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
> 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
> 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: InvokeDynamic PIC Slowdown (deopt issue?) need advice
On 23.07.2016 01:25, 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.
How about making a list of all those annotations that influence
invokedynamic and inlining? And how likely is it that some of them get
promoted to official API? And will they be available in JDK9 to non-JDK
modules?
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.)
which means you cannot reorder, nor can you evict the oldest handle
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
}
I would have expected a MethodHandle[] only. The documentation of stable
is also not so clear to me here. is assumed to be stable, allows only
setting the element of an array with a stable element... ok... but a 2D
array is an array of arrays. So the stable values are the arrays itself
and they are not stable? I wouldn´t have expected this to work.
bye Jochen
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
Hi John
I did try a variant of this ( did not
know about stable at the time ) where I used two 10 element arrays like
you recommend. The first array
was a set of object references which was the original guard and the
second the matching method handles.
For this experiment I did not change the array contents. I
used
a simple linear search over the object
references to locate the index and then executed the MH.
I found this to be substantially slower
than just a linked set of GWTs. I have thought of changing
the guard to a integer vs the object
ref thinking this would be better but I have not tried it yet. I
also
wrote this in high level java and rather
than at the byte code level which may not have been the best way.
I should have some time in the next
few weeks to look at this again
mark
"mlvm-dev"
wrote on 07/22/2016 04:25:32 PM:
> From: John Rose
> To: Da Vinci Machine Project
> Date: 07/22/2016 04:26 PM
> Subject: Re: InvokeDynamic PIC Slowdown (deopt
issue?) need advice
> Sent by: "mlvm-dev"
>
> 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
> 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: InvokeDynamic PIC Slowdown (deopt issue?) need advice
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
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
Thx Vladimir Turns out this was self inflicted by the means I was using for PIC invalidation. There is an interesting case when only one class returns false and all others true ( isNil). Since this is often in a loop the impact is severe. I see how to handle this corner case but it does reopen my thinking on how to handle PICs in general. Any thoughts are welcome. I am running Hotspot 25.102.b04 and I do read the hotspot mailing list on a regular basis. Nice to see all the work going on. regards mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
Never-taken GWT branches (on per-MH instance basis) are aggressively pruned during JIT-compilation. So, in the worst case, a MH chain containing 6 GWT can experience 6 recompilations. I don't know what Java version you use, but there were a number of bugs fixed in HotSpot, which manifested as methods marked as non-compilable due to profile pollution (e.g., JDK-8074551 [1]). I suggest to monitor JIT compiler activity as well. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8074551 On 5/31/16 10:41 PM, Mark Roos wrote: I have been implementing a Smalltalk on the JVM (Rtalk) which has gone quite well. But recently I was told that one of our key benchmarks had suffered a large slowdown, from a few hundred mS to seconds. And strangely it gets slower the more its executed until we reset all of the call sites. Looking closer I found at least one reproducible cause which leads me to think that there is some issue with how I do PICs and how Hotspot tries to inline them. We have a common case where we reset an array of objects by copying one instance var to another. The Smalltalk class of each value can be one of several so there is some level of polymorphism at each site. Interesting for several of these arrays the reset time was 200uS or so but for one it was 1000 mS. The only difference was that in the fast ones the Smalltalk class types were bunched while in the slow case they were distributed. I found that by setting all of the Smalltalk classes to the same type the time dropped to a few hundred uS. Leading me to think my PIC was the problem. The problem Smalltalk code looks like this: idleValue isNil ifFalse:[finalValue := idleValue deepCopy] ifTrue:[finalValue := default]. There are two invoke dynamic sites, isNil and deepCopy. Removing deepCopy has little effect but removing the isNil test saves most of the time. Interesting isNil is a very small method ( returns a constant of true or false ) so my thought is that it would be logically inlined. While deepCopy is large. 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). Any ideas on how I can avoid this? Notes: Each of my Smalltalk objects is an instance of a single Java class. The Smalltalk class is determined by a compare on one of its instance vars. So looking at the Java class at a callsite it would always be a constant. My call site chain looks like a mutable site whose target is a fixed set of methodHandles terminated by another mutable site whose target is the chain of GWTs. thanks mark ___ 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
