I did try a variant of this ( did not know about stable at the time ) where I used two 10 element arrays like
you recommend. The first array was a set of object references which was the original guard and the
second the matching method handles. For this experiment I did not change the array contents. I used
a simple linear search over the object references to locate the index and then executed the MH.
I found this to be substantially slower than just a linked set of GWTs. I have thought of changing
the guard to a integer vs the object ref thinking this would be better but I have not tried it yet. I also
wrote this in high level java and rather than at the byte code level which may not have been the best way.
I should have some time in the next few weeks to look at this again
mark
"mlvm-dev" <mlvm-dev-boun...@openjdk.java.net> wrote on 07/22/2016 04:25:32 PM:
> From: John Rose <john.r.r...@oracle.com>
> To: Da Vinci Machine Project <mlvm-dev@openjdk.java.net>
> Date: 07/22/2016 04:26 PM
> Subject: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
> Sent by: "mlvm-dev" <mlvm-dev-boun...@openjdk.java.net>
>
> 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
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
