Hi John

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


"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
mlvm-dev mailing list

Reply via email to