D’oh! Yes, it’s perfectly usable for my purposes with just one level of
indirection, I can always invalidate the whole PIC. :-)
In fact, I’ve pretty much got this code lying around already, it just
needs the annotations slapped on it, and it’s already thread safe. Doubt
I’ll have time to really experiment with it this week though, few too many
other things to get done before JVMLS.
Duncan.
On 25/07/2016, 17:03, "mlvm-dev on behalf of Remi Forax"
<mlvm-dev-boun...@openjdk.java.net on behalf of fo...@univ-mlv.fr> wrote:
>Hi Duncan,
>you should see this technique as a new method handle combiner,
>it can be integrated easily with with the rest of java.lang.invoke,
>CallSite, SwitchPoint, etc.
>
>and by the way, the code i've provided has a race issue, two threads can
>changes the two arrays at the same time,
>maybe, it should be implemented with an array of couples instead with a
>couple of arrays.
>
>Rémi
>
>----- Mail original -----
>> De: "MacGregor, Duncan (GE Energy Connections)"
>><duncan.macgre...@ge.com>
>> À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net>
>> Envoyé: Lundi 25 Juillet 2016 11:40:51
>> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need
>>advice
>
>> I like the idea of this, but I¹m not sure it can be applied to Magik due
>> to the ability for methods to redefined and hence our PICs to be
>> invalidated. I¹ll have a look though, there might be a couple of places
>>I
>> could try prototyping this.
>>
>> Duncan.
>>
>> On 23/07/2016, 00:25, "mlvm-dev on behalf of John Rose"
>> <mlvm-dev-boun...@openjdk.java.net on behalf of john.r.r...@oracle.com>
>> wrote:
>>>On May 31, 2016, at 12:41 PM, Mark Roos <mr...@roos.com> wrote:
>>>>
>>>> It looks like, from some fine timing, that each time the Smalltalk
>>>>class changes there is a large amount
>>>> of time added to the call. Which I would expect if there was a deopt
>>>>whenever a different GWT triggered.
>>>> There are 6 GWTs in this chain ( idleValue can be one of six Smalltalk
>>>>classes).
>>>
>>>Has anybody on this list played with using a short @Stable array to
>>>represent a PIC?
>>>Editing the PIC would involve changing the array instead of recompiling
>>>a
>>>call site.
>>>
>>>The effect would be to preserve existing inlinings of the PIC site
>>>(unless they
>>>self-invalidate) but allow the PIC to update itself over time as new
>>>cases arise.
>>>Previously compiled uses of the PIC would stay optimized as-is.
>>>
>>>The @Stable array would always have a series of zero or more non-null
>>>entries,
>>>followed by at least one null entry. The search in the @Stable array
>>>would inline
>>>and short-circuit over irrelevant PIC entries, if the pattern-matching
>>>logic were
>>>inlinable. Entries could be as simple as @Stable 2-arrays of guard MH
>>>and target MH.
>>>(If they are objects, some care with TrustFinalFields would also be
>>>needed.)
>>>
>>>Using this technique would probably lead to fewer deopts. The @Stable
>>>array could
>>>also be shared by several PIC sites, if that helps with footprint.
>>>
>>>class PIC {
>>> @Stable final MethodHandle[][] cache = new MethodHandle[PIC_SIZE+1][];
>>> // cache[0] = new MethodHandle[] { guard, target }, etc.
>>> // cache[cache.length-1] is either null or some permanent catch-all
>>>logic
>>>}
>>>
>>>‹ John
>>>_______________________________________________
>>>mlvm-dev mailing list
>>>mlvm-dev@openjdk.java.net
>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.ne
>>>t_
>>>mailman_listinfo_mlvm-2Ddev&d=CwIGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3w
>>>Ur
>>>LrDQYWSI&r=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE&m=VNUQiU3bdwDRsoH
>>>6K
>>>VkNR_qOt5a2CDuOQTPk7SSpf5E&s=tOHi6W_nCiTp7Q_l9pyafMNesDW3zc0wOWk-v4sZkHc
>>>&e
>>>=
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>>
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net
>>_mailman_listinfo_mlvm-2Ddev&d=CwIGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3w
>>UrLrDQYWSI&r=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE&m=j6UFPVZYyrZFKp
>>b86Mngk1T8QcorAG4j-ML_cpvVUhI&s=RFwWQvDdQhxNJ6u9N3FRoX4WxnUO-am20ogX_nlLo
>>PQ&e=
>_______________________________________________
>mlvm-dev mailing list
>mlvm-dev@openjdk.java.net
>https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_
>mailman_listinfo_mlvm-2Ddev&d=CwIGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUr
>LrDQYWSI&r=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE&m=j6UFPVZYyrZFKpb86
>Mngk1T8QcorAG4j-ML_cpvVUhI&s=RFwWQvDdQhxNJ6u9N3FRoX4WxnUO-am20ogX_nlLoPQ&e
>=
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
