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
