Bug ID: JDK-8067250 [mlvm] vm/mlvm/mixed/stress/regression/b6969574 fails and perf regression

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 9,10,11

Priority: P4
Status: Resolved
Resolution: Fixed

Submitted: 2014-12-11
Updated: 2023-11-28
Resolved: 2019-01-25

JDK 11	JDK 12	JDK 13
11.0.22-oracleFixed	12 b30Fixed	13Fixed

It seems that full LF sharing patch was lost during Jigsaw integration. 

[2014-12-07T23:48:58.76] ### TRACE 1: MH.invokeWithArguments(), exact types: 1175.5 ns (stddev: 65.8 = 5%) // 10.5 times slower than Reflection API Method.invoke() 
[2014-12-07T23:48:58.76] ### TRACE 1: MH.invokeWithArguments() + type conv.: 1197.0 ns (stddev: 69.1 = 5%) // 10.7 times slower than Reflection API Method.invoke()

Fix request [11u] I backport this for parity with 11.0.22-oracle. No risk, only a test change. Clean backport. Test passes. SAP nightly testing passed.
27-11-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2294 Date: 2023-11-24 03:24:10 +0000
24-11-2023
URL: http://hg.openjdk.java.net/jdk/jdk12/rev/207d3bb450e5 User: iignatyev Date: 2019-01-25 16:53:55 +0000
25-01-2019
http://cr.openjdk.java.net/~iignatyev//8067250/webrev.00/index.html
25-01-2019
Filed an RFE (JDK-8078511) to consider enhanced invoker for MH.invokeWithArguments().
23-04-2015
MethodHandle.invokeWithArguments() is different from other invocation modes. It doesn't use a special invoker, but prepares new one every time invocation happens. src/java.base/share/classes/java/lang/invoke/MethodHandle.java: public Object invokeWithArguments(Object... arguments) throws Throwable { MethodType invocationType = MethodType.genericMethodType(arguments == null ? 0 : arguments.length); return invocationType.invokers().spreadInvoker(0).invokeExact(asType(invocationType), arguments); } It's still fast (only 5x slower than a direct call) because LambdaForm caching saves lots of work for repeated invocations. But since MethodHandle construction happens on every invocation, it is affected by VM execution mode (product/fastdebug, -Xcomp, -esa) while other invocation modes aren't (mostly; see numbers below). The test fails with -esa -Xcomp flags because verification logic significantly slows down MH.invokeWithArguments() (5x difference -> 10-12x difference). Since MH.invokeWithArguments() performance isn't important, I suggest to adjust the test. I'll file an RFE to consider implementing more efficient representation for MH.invokeWithArguments(). PRODUCT: Direct call: 54.3 ns (stddev: 1.0 = 1%) // 1.0 times FASTER than Reflection API Method.invoke() Reflection API Method.invoke(): 55.6 ns (stddev: 0.7 = 1%) MH.invokeExact(): 61.2 ns (stddev: 0.7 = 1%) // 1.1 times slower than Reflection API Method.invoke() MH.invoke(): 60.8 ns (stddev: 0.4 = 0%) // 1.1 times slower than Reflection API Method.invoke() MH.invokeWithArguments(), exact types: 298.2 ns (stddev: 4.4 = 1%) // 5.4 times slower than Reflection API Method.invoke() MH.invokeWithArguments() + type conv.: 307.6 ns (stddev: 4.1 = 1%) // 5.5 times slower than Reflection API Method.invoke() invokedynamic instruction: 54.2 ns (stddev: 0.4 = 0%) // 1.0 times FASTER than Reflection API Method.invoke() PRODUCT, -Xcomp -esa: Direct call: 56.5 ns (stddev: 4.2 = 7%) // 1.3 times FASTER than Reflection API Method.invoke() Reflection API Method.invoke(): 76.1 ns (stddev: 8.0 = 10%) MH.invokeExact(): 75.6 ns (stddev: 15.8 = 20%) // 1.0 times FASTER than Reflection API Method.invoke() MH.invoke(): 73.9 ns (stddev: 11.1 = 14%) // 1.0 times FASTER than Reflection API Method.invoke() MH.invokeWithArguments(), exact types: 660.1 ns (stddev: 26.4 = 4%) // 8.7 times slower than Reflection API Method.invoke() MH.invokeWithArguments() + type conv.: 689.9 ns (stddev: 4.6 = 0%) // 9.1 times slower than Reflection API Method.invoke() invokedynamic instruction: 54.2 ns (stddev: 0.4 = 0%) // 1.4 times FASTER than Reflection API Method.invoke() FASTDEBUG: Direct call: 54.5 ns (stddev: 1.5 = 2%) // 1.0 times FASTER than Reflection API Method.invoke() Reflection API Method.invoke(): 55.8 ns (stddev: 0.6 = 1%) MH.invokeExact(): 64.5 ns (stddev: 0.8 = 1%) // 1.2 times slower than Reflection API Method.invoke() MH.invoke(): 64.2 ns (stddev: 0.4 = 0%) // 1.2 times slower than Reflection API Method.invoke() MH.invokeWithArguments(), exact types: 490.3 ns (stddev: 51.0 = 10%) // 8.8 times slower than Reflection API Method.invoke() MH.invokeWithArguments() + type conv.: 468.8 ns (stddev: 60.0 = 12%) // 8.4 times slower than Reflection API Method.invoke() invokedynamic instruction: 54.1 ns (stddev: 0.3 = 0%) // 1.0 times FASTER than Reflection API Method.invoke() FASTDEBUG, -Xcomp -esa: Direct call: 58.2 ns (stddev: 6.6 = 11%) // 1.6 times FASTER than Reflection API Method.invoke() Reflection API Method.invoke(): 94.9 ns (stddev: 38.1 = 40%) MH.invokeExact(): 82.2 ns (stddev: 20.6 = 25%) // 1.2 times FASTER than Reflection API Method.invoke() MH.invoke(): 79.9 ns (stddev: 12.0 = 15%) // 1.2 times FASTER than Reflection API Method.invoke() MH.invokeWithArguments(), exact types: 954.4 ns (stddev: 77.6 = 8%) // 10.1 times slower than Reflection API Method.invoke() MH.invokeWithArguments() + type conv.: 1060.7 ns (stddev: 68.9 = 6%) // 11.2 times slower than Reflection API Method.invoke() invokedynamic instruction: 54.6 ns (stddev: 0.9 = 1%) // 1.7 times FASTER than Reflection API Method.invoke()
23-04-2015
failed again, see JDK-8072091
24-02-2015
I tried 9b43, but failed to reproduce the problem: ======== Results (absolute); warmups: 5; measurements: 10; iterations/run: 1000000; micro iterations: 5 ### TRACE 1: Direct call: 68.4 ns (stddev: 1.2 = 1%) // 1.0 times FASTER than Reflection API Method.invoke() ### TRACE 1: Reflection API Method.invoke(): 70.7 ns (stddev: 2.1 = 2%) ### TRACE 1: MH.invokeExact(): 73.5 ns (stddev: 2.9 = 3%) // 1.0 times slower than Reflection API Method.invoke() ### TRACE 1: MH.invoke(): 73.1 ns (stddev: 2.7 = 3%) // 1.0 times slower than Reflection API Method.invoke() ### TRACE 1: MH.invokeWithArguments(), exact types: 388.9 ns (stddev: 3.1 = 0%) // 5.5 times slower than Reflection API Method.invoke() ### TRACE 1: MH.invokeWithArguments() + type conv.: 391.3 ns (stddev: 3.2 = 0%) // 5.5 times slower than Reflection API Method.invoke() ### TRACE 1: invokedynamic instruction: 67.9 ns (stddev: 0.3 = 0%) // 1.0 times FASTER than Reflection API Method.invoke() ### TRACE 1: ======== Conclusions
20-12-2014
JDK-8063135 patch seems to be in the source tree of the build, where it failed (I did not check for completeness, however)
12-12-2014
ILW=performance regression;all platforms;none=MHH=P2
12-12-2014
it's hard to say if it's related to jigsaw m2 integration. we have similar falures in b41, and they are supposed to be fixed by JDK-8063135. so I see two and a half possibility here: - JDK-8063135 doesn't help w/ this - JDK-8063135 helps, but it's not in jigsaw m2 PIT since it was integrated after snap or smth like that - JDK-8063135 helps, but jigsaw m2 breaks/remove it
12-12-2014

Duplicate :	JDK-8072091 - [AARCH64] JSR292: LF sharing regression
Duplicate :	JDK-8217800 - MH.invokeWithArguments(), exact types invocation time > MH.invokeExact()
Relates :	JDK-8063135 - Enable full LF sharing by default
Relates :	JDK-8078511 - Implement special invoker for MH.invokeWithArguments
Relates :	JDK-8061543 - JSR 292: Regression: MethodHandle.invokeWithArguments() became slower in jdk9 b31