Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

[Mark Roos]

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" <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, "m

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

[Remi Forax]

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 th

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

[MacGregor, Duncan (GE Energy Connections)]

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=CwIGaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3w
>>>Ur
>>>LrDQYWSI=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE=VNUQiU3bdwDRsoH
>>>6K
>>>VkNR_qOt5a2CDuOQTPk7SSpf5E=tOHi6W_nCiTp7Q_l9pyafMNesDW3zc0wOWk-v4sZkHc
>>>
>>>=
>> 
>> ___
>> 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=CwIGaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3w
>>UrLrDQYWSI=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE=j6UFPVZYyrZFKp
>>b86Mngk1T8QcorAG4j-ML_cpvVUhI=RFwWQvDdQhxNJ6u9N3FRoX4WxnUO-am20ogX_nlLo
>>PQ= 
>___
>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=CwIGaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUr
>LrDQYWSI=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE=j6UFPVZYyrZFKpb86
>Mngk1T8QcorAG4j-ML_cpvVUhI=RFwWQvDdQhxNJ6u9N3FRoX4WxnUO-am20ogX_nlLoPQ
>= 

___
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

[Mark Roos]

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

[Mark Roos]

Or maybe an array of GWTs?

Sent from my iPhone

> On Jul 25, 2016, at 9:04 AM, Remi Forax <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.net_
>>> mailman_listinfo_mlvm-2Ddev=CwIGaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUr
>>> LrDQYWSI=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE=VNUQiU3bdwDRsoH6K
>>> VkNR_qOt5a2CDuOQTPk7SSpf5E=tOHi6W_nCiTp7Q_l9pyafMNesDW3zc0wOWk-v4sZkHc
>>> =
>> 
>> ___
>> 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

[Remi Forax]

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=CwIGaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUr
>>LrDQYWSI=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE=VNUQiU3bdwDRsoH6K
>>VkNR_qOt5a2CDuOQTPk7SSpf5E=tOHi6W_nCiTp7Q_l9pyafMNesDW3zc0wOWk-v4sZkHc
>>=
> 
> ___
> 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

[John Rose]

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

[Mark Roos]

 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

[Remi Forax]

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" <john.r.r...@oracle.com>
> À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net>
> 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 <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
> 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

[John Rose]

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

[Mark Roos]

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

[Vladimir Ivanov]

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