[9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

[Remi Forax]

Hi Vladimir,
in Invokers.java, I think that checkCustomized should take an Object and 
not a MethodHandle
exactly like getCallSiteTarget takes an Object and not a CallSite.

in MethodHandle.java, customizationCount is declared as a byte and there 
is no check that
the CUSTOMIZE_THRESHOLD is not greater than 127.

cheers,
Rémi

On 01/21/2015 05:25 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8069591/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8069591
>
> Overhead of non-inlined MH.invoke/invokeExact calls significantly 
> increased with LambdaForm sharing. The cause is JIT compiler can't 
> produce a single nmethod for the whole MethodHandle chain, so the 
> execution is spread around numerous nmethods (1 per each MethodHandle 
> in the chain). The longer the chain the larger overhead.
>
> The fix is to customize LambdaForms (create a dedicated LambdaForm for 
> a MethodHandle). Per-MethodHandle count is introduced, which is 
> incremented every time a MethodHandle is invoked using 
> MethodHandle.invoke/invokeExact. Once CUSTOMIZE_THRESHOLD is reached 
> for a particular MethodHandle, it's LambdaForm is substituted with a 
> customized one, which has it's MethodHandle embedded. It allows JIT to 
> see actual MethodHandle during compilation and produce more efficient 
> code.
>
> This fix completely recovers Gbemu peak performance to pre-LambdaForm 
> sharing level.
>
> Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, nashorn 
> tests, nashorn/octane
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev