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