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]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
