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" <fo...@univ-mlv.fr>
> À: "Da Vinci Machine Project" <mlvm-dev@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.r...@oracle.com>
>> À: "Da Vinci Machine Project" <mlvm-dev@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 <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
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
