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&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
