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-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
