InvokeDynamic PIC Slowdown (deopt issue?) need advice

[Remi Forax]

It seems to work :)

Same code for the PIC, with a different test code:
https://gist.github.com/forax/2ea146eacaf5608cec93e8066e9ae665

with:
/usr/jdk/jdk-9/bin/java -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:+PrintCompilation -Xpatch:java.base=../classes -m java.base/java.lang.invoke.FunPIC

When the deopt() is called because test() see an URL instead of a String,
you can see in the trace below that just after "deopt 1", test() is "made not entrant", but you can not see the same message for test2().
So only the inline blob that see an URL is deoptimized and not all blobs that share the same PIC.

very good idea, John !
i believe a PIC like that should be added to java.lang.invoke.MethodHandles. 

Rémi

deopt 0
    325  409     n 0       java.lang.invoke.MethodHandle::invokeBasic(LL)I (native)   
    325  410     n 0       java.lang.invoke.MethodHandle::linkToSpecial(LLLL)I (native)   (static)
    326  411    b  3       java.util.HashMap$ValueIterator::next (8 bytes)
    326  412     n 0       java.lang.invoke.MethodHandle::invokeBasic(L)I (native)   
    326  413     n 0       java.lang.invoke.MethodHandle::linkToSpecial(LLL)I (native)   (static)
    327  414    b  1       java.lang.invoke.MethodHandleImpl::isCompileConstant (2 bytes)
    327  415    b  3       java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes)
    328  416    b  3       java.lang.invoke.Invokers::checkCustomized (23 bytes)
    328  417    b  3       java.lang.invoke.Invokers::maybeCustomize (28 bytes)
    328  418    b  3       java.lang.invoke.LambdaForm$MH/1836643189::invokeExact_MT (23 bytes)
    329  419     n 0       java.lang.Class::isInstance (native)   
    329  420    b  3       java.lang.invoke.LambdaForm$BMH/429313384::reinvoke (25 bytes)
    329  421    b  3       java.lang.invoke.LambdaForm$DMH/344560770::invokeSpecial_LL_L (15 bytes)
    330  422    b  3       java.lang.Class::cast (27 bytes)
    330  423    b  3       java.lang.invoke.FunPIC::m (78 bytes)
    331  424   !b  3       java.lang.invoke.FunPIC::test (15 bytes)
    332  425   !b  3       java.lang.invoke.FunPIC::test2 (15 bytes)
    335  426   !b  4       java.lang.invoke.FunPIC::test (15 bytes)
    336  424   !   3       java.lang.invoke.FunPIC::test (15 bytes)   made not entrant
    336  427   !b  4       java.lang.invoke.FunPIC::test2 (15 bytes)
    337  425   !   3       java.lang.invoke.FunPIC::test2 (15 bytes)   made not entrant
deopt 1
    340  426   !   4       java.lang.invoke.FunPIC::test (15 bytes)   made not entrant
    340  428    b  4       java.lang.invoke.LambdaForm$DMH/166239592::invokeStatic_LL_I (15 bytes)
    341  429    b  4       java.lang.invoke.FunPIC::typeCheck (14 bytes)
    341  430    b  4       java.lang.invoke.LambdaForm$DMH/1967205423::invokeStatic_L_I (14 bytes)
    343  431    b  3       java.lang.StringLatin1::inflate (34 bytes)
    343  432   !b  4       java.lang.invoke.FunPIC::test (15 bytes)
500000




----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
> Envoyé: Samedi 23 Juillet 2016 12:39:08
> Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

> At least the PIC usual test seems to work :)
> 
> https://gist.github.com/forax/7d1c06df9546baf9d98e8c0c1f255e05
> 
> The instructions are for JDK9 and i've put the class in java.lang.invoke to
> access to the annotations @Stable, @DontInline and @ForceInline.
> 
> Rémi
> 
> ----- Mail original -----
>> De: "John Rose" <john.r.rose at oracle.com>
>> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
>> Envoyé: Samedi 23 Juillet 2016 01:25:32
>> Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice
> 
>> 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
>> 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