JDK-8161210 : slowdown in MHs.iteratedLoop handles
Type:Bug
Component:core-libs
Sub-Component:java.lang.invoke
Affected Version:9
Priority:P3
Status:Open
Resolution:Unresolved
Submitted:2016-07-12
Updated:2017-02-14
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
The introduction of bytecode intrinsics (JDK-8143211) caused a slowdown for handles resulting from MHs.iteratedLoop().
Comments
The micro at hand uses List<Integer> in all signatures while the actual list used is always an ArrayList. So it appears we're intermittently losing or never creating a correct type profile somewhere along the way (invokeExact?).
Specializing all methods in the microbenchmark to produce/consume ArrayList appear to always get us the "fast" performance (around 100-110ns/op on my machine).
27-09-2016
On my benchmarking machine, baseline (bytecode) performance for 100 iterations of the microbenchmark is 81 ns/op, the "slow" runs of iteratedLoop are at 289 ns/op, and the "fast" runs at 110. This is a result from one measurement run (10 warmup, 5 measurement iterations).
27-09-2016
Simply inserting an empty default constructor in the ArrayList.Itr class, the resulting JDK now refuses to inline at that place for a different reason:
1068 java.lang.invoke.LambdaForm$MH016/2032680247::loop_002 (unknown bytes)
@ 43 java.lang.invoke.DirectMethodHandle$Holder::invokeStatic succeed: force inline by annotation (end time: 0,5940 nodes: 101 live: 98)
@ 1 java.lang.invoke.DirectMethodHandle::internalMemberName succeed: force inline by annotation (end time: 0,5940 nodes: 67 live: 66)
@ 10 net.openjdk.micro.jep274.MethodHandlesIteratedLoop::iterator succeed: inline (hot) (end time: 0,5940 nodes: 98 live: 96)
@ 1 java.util.List::iterator fail: virtual call (end time: 0,0000)
This is an intermittent thing - some runs (!) report this instead, and also visibly improve performance:
@ 43 java.lang.invoke.DirectMethodHandle$Holder::invokeStatic (14 bytes) force inline by annotation
@ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation
@ 10 org.openjdk.MethodHandlesIteratedLoop::iterator (7 bytes) inline (hot)
@ 1 java.util.ArrayList::iterator (9 bytes) inline (hot)
\-> TypeProfile (11913/11913 counts) = java/util/ArrayList
@ 5 java.util.ArrayList$Itr::<init> (26 bytes) inline (hot)
@ 6 java.lang.Object::<init> (1 bytes) inline (hot)
27-09-2016
A relevant excerpt from the compilation log:
1062 java.lang.invoke.LambdaForm$MH016/1925405953::loop_002 (unknown bytes)
@ 43 java.lang.invoke.DirectMethodHandle$Holder::invokeStatic succeed: force inline by annotation (end time: 0,6520 nodes: 175 live: 169)
@ 1 java.lang.invoke.DirectMethodHandle::internalMemberName succeed: force inline by annotation (end time: 0,6510 nodes: 67 live: 66)
@ 10 net.openjdk.micro.jep274.MethodHandlesIteratedLoop::iterator succeed: inline (hot) (end time: 0,6520 nodes: 173 live: 168)
@ 1 java.util.List::iterator (0 bytes) (end time: 0,0000)
type profile java.util.List -> java.util.ArrayList (100%)
@ 1 java.util.ArrayList::iterator succeed: inline (hot) (end time: 0,6520 nodes: 170 live: 166)
@ 6 java.util.ArrayList$Itr::<init> fail: unloaded signature classes (end time: 0,0000)
[~vlivanov] points to a hotspot-compiler-dev thread where this issue is discussed; there appears to be a fix for it that needs to be pushed upstream: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024407.html