EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

[Remi Forax]

yes, 
an array of a special kind of GWT, which unlike a GWT doesn't have a fallback, only a test and a target. 

Rémi 

> De: "Mark Roos" <mroos at roos.com>
> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
> Envoyé: Lundi 25 Juillet 2016 18:12:25
> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

> Or maybe an array of GWTs?

> Sent from my iPhone

> > On Jul 25, 2016, at 9:04 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> > Hi Duncan,
> > you should see this technique as a new method handle combiner,
>> it can be integrated easily with with the rest of java.lang.invoke, CallSite,
> > SwitchPoint, etc.

>> and by the way, the code i've provided has a race issue, two threads can changes
> > the two arrays at the same time,
>> maybe, it should be implemented with an array of couples instead with a couple
> > of arrays.

> > Rémi

> > ----- Mail original -----
> >> De: "MacGregor, Duncan (GE Energy Connections)" <duncan.macgregor at ge.com>
> >> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
> >> Envoyé: Lundi 25 Juillet 2016 11:40:51
> >> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

> >> 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"
> >> <mlvm-dev-bounces at openjdk.java.net on behalf of john.r.rose at oracle.com>
> >> wrote:
> >>>> On May 31, 2016, at 12:41 PM, Mark Roos <mroos at 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 at openjdk.java.net
> >>> 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
> >> mlvm-dev at openjdk.java.net
> >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> > _______________________________________________
> > mlvm-dev mailing list
> > mlvm-dev at openjdk.java.net
> > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160725/a182b79c/attachment.html>