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
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 sh
Or maybe an array of GWTs?
Sent from my iPhone
> On Jul 25, 2016, at 9:04 AM, Remi Forax 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
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"
> À: "Da Vinci Machine Project"
> Envoyé: Lundi 25 Juillet 2016 18:12:25
> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
> Or may
In my perfect world a pic looks like this
at the lowest level
mov
object field ==> eax
je
eax=test1 to implementation1 " the special GWT you mention
"
je
eax=test2 to implementation2
...
handle
miss
I would want to move the testN order
to optimize, rep