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" <[email protected] on behalf of [email protected]> wrote: >On May 31, 2016, at 12:41 PM, Mark Roos <[email protected]> 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 >[email protected] >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 [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
