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.


----- Mail original -----
> De: "MacGregor, Duncan (GE Energy Connections)" <duncan.macgre...@ge.com>
> À: "Da Vinci Machine Project" <mlvm-dev@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-boun...@openjdk.java.net on behalf of john.r.r...@oracle.com>
> wrote:
>>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
>>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
>>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
>>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
>>‹ John
>>mlvm-dev mailing list
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
mlvm-dev mailing list

Reply via email to