JDK-8218201 : Failures when vmIntrinsics::_getClass is not inlined
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7u201,8u192,9,10,11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2019-02-01
  • Updated: 2019-11-21
  • Resolved: 2019-03-11
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.

To download the current JDK release, click here.
JDK 11 JDK 13 Other
11.0.5Fixed 13 b12Fixed openjdk8u232Fixed
Related Reports
Duplicate :  
JDK-8219725 - C2 generates wrong code with -XX:-InlineNatives for java/lang/invoke/ClassSpecializer.findSpecies
Relates :  
JDK-7105605 - Use EA info to optimize pointers compare
Description
Several tests fail when running with -XX:-InlineNatives or -XX:-InlineClassNatives.

For example, jdk/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java:

java.lang.ClassCastException: Cannot cast java.lang.Object to java.lang.invoke.BoundMethodHandle$SpeciesData
	at java.base/java.lang.Class.cast(Class.java:3613)
	at java.base/java.lang.invoke.ClassSpecializer.findSpecies(ClassSpecializer.java:202)
	at java.base/java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:352)
	at java.base/java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:392)
	at java.base/java.lang.invoke.LambdaFormEditor.bindArgumentForm(LambdaFormEditor.java:455)
	at java.base/java.lang.invoke.LambdaFormEditor.bindArgumentI(LambdaFormEditor.java:406)
	at java.base/java.lang.invoke.BoundMethodHandle.bindArgumentI(BoundMethodHandle.java:100)
	at java.base/java.lang.invoke.MethodHandles.insertArgumentPrimitive(MethodHandles.java:3534)
	at java.base/java.lang.invoke.MethodHandles.insertArguments(MethodHandles.java:3515)
...


With sun/invoke/util/ValueConversionsTest.java:

JavaTest Message: JUnit Failure: testConvert(test.sun.invoke.util.ValueConversionsTest): null
java.lang.AssertionError
	at java.base/sun.invoke.util.Wrapper.convert(Wrapper.java:537)
	at java.base/sun.invoke.util.Wrapper.cast(Wrapper.java:495)
	at test.sun.invoke.util.ValueConversionsTest.testConvert(ValueConversionsTest.java:189)
	at test.sun.invoke.util.ValueConversionsTest.testConvert(ValueConversionsTest.java:173)
...
Comments
Fix Request (8u) Same rationale as with 11u. 8u RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009982.html
08-08-2019
Fix Request (11u) This solves the corner case that leads to C2 miscompilation. Patch applies to 11u cleanly after JDK-8216199 backport. New test fails without the product fix and passes with it. Updated builds also pass tier1.
08-08-2019
I can reproduce this with a simple: bin/java -Xcomp -XX:-TieredCompilation -XX:DisableIntrinsic=_getClass Error occurred during initialization of boot layer java.lang.ExceptionInInitializerError Caused by: java.lang.ClassCastException: Cannot cast java.lang.Object to java.lang.invoke.BoundMethodHandle$SpeciesData Attached a regression test (Test.java) that fails with -XX:-TieredCompilation -Xcomp -XX:DisableIntrinsic=_getClass -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::test. The problem is that the BCEscapeAnalyzer assigns a wrong escape state to the getClass return value: [EA] computing results for java/lang/Object.getClass [EA] estimating escape information for intrinsic java.lang.Object::getClass (0 bytes) [EA] estimated escape information for java.lang.Object::getClass non-escaping args: {0} stack-allocatable args: {0} return allocated value modified args: 0 flags: return_allocated Workarounds: -XX:-OptimizePtrCompare or -XX:-EstimateArgEscape http://cr.openjdk.java.net/~thartmann/8218201/webrev.00/
07-03-2019
Also reported by JDK-8219725. Increasing priority: ILW = Incorrect C2 compiled code, several tests but only with diagnostic flag -XX:-InlineNatives or -XX:-InlineClassNatives, no workaround (but to use default flags) = HLM = P3
26-02-2019