JDK-8188785 : CCP sets invalid type for java mirror load
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-10-04
  • Updated: 2020-09-01
  • Resolved: 2017-10-25
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 10
10 b31Fixed
Related Reports
Duplicate :  
JDK-8188835 - AllocateUninitializedArray fails with "IllegalStateException: Wrong class: expected = class [I, but got class [C "
Relates :  
JDK-8186777 - Make Klass::_java_mirror an OopHandle
Relates :  
JDK-8189856 - Revisit type propagation with nodes that don't depend on their direct inputs
Description
----------System.out:(4/26)----------

Test4

global run method
----------System.err:(15/1045)----------
java.lang.ClassCastException: Cannot cast jdk.nashorn.internal.scripts.JD4 to jdk.nashorn.internal.objects.Global
	at java.base/java.lang.Class.cast(Class.java:3569)
	at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.getInterfaceInner(NashornScriptEngine.java:279)
	at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.getInterface(NashornScriptEngine.java:211)
	at Test4.main(Test4.java:53)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230)
	at java.base/java.lang.Thread.run(Thread.java:844)

JavaTest Message: Test threw exception: java.lang.ClassCastException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.ClassCastException: Cannot cast jdk.nashorn.internal.scripts.JD4 to jdk.nashorn.internal.objects.Global
Comments
thank you [~thartmann]!
25-10-2017
Fix: http://cr.openjdk.java.net/~thartmann/8188785/webrev.00/
20-10-2017
During CCP, we compute the type of a Phi that merges oops of type A and B where B is a subtype of A. Since the type of the A input was not computed yet (it was initialized to TOP at the beginning of CCP), the Phi temporarily ends up with type B (i.e. with a type that is too strict). This type is propagated downwards and is being used to optimize a java mirror load from the klass corresponding to the oop: LoadP(LoadP(AddP(DecodeNKlass(LoadNKlass(AddP(CastPP(Phi))))))) This is then folded to TypeInstPtr::make(B) which is not correct because the oop can be of type A at runtime. The problem is the new LoadP(LoadP( .. )) graph shape. The type of the outermost LoadP does not depend on the type of the input LoadP (which has type rawptr) but on the type of the AddP. CPP only propagates the type downwards to the direct user but does not update the nodes one step deeper. Quick prototype fix that solves the problem: --- a/src/hotspot/share/opto/phaseX.cpp Wed Oct 18 19:36:17 2017 -0700 +++ b/src/hotspot/share/opto/phaseX.cpp Thu Oct 19 18:58:04 2017 +0200 @@ -1751,6 +1751,14 @@ } } } + if (m_op == Op_LoadP) { + for (DUIterator_Fast i2max, i2 = m->fast_outs(i2max); i2 < i2max; i2++) { + Node* u = m->fast_out(i2); + if (u->Opcode() == Op_LoadP) { + worklist.push(u); + } + } + } // If n is used in a counted loop exit condition then the type // of the counted loop's Phi depends on the type of n. See // PhiNode::Value().
19-10-2017
http://cr.openjdk.java.net/~coleenp/8186777.01/webrev/src/share/vm/opto/memnode.cpp.udiff.html and http://cr.openjdk.java.net/~coleenp/8186777.01/webrev/src/share/vm/opto/subnode.cpp.udiff.html or less likely http://cr.openjdk.java.net/~coleenp/8186777.01/webrev/src/share/vm/opto/library_call.cpp.udiff.html I did run all the tiers and don't remember seeing this failure (or thought it was an expected one, most likely) thank you [~thartmann]
19-10-2017
The problem is that a LoadKlass from an Object is folded and incorrectly replaced by 935 ConP === 0 [[ 531 547 ]] #java/lang/Class:exact * Oop:java/lang/Class:exact * I've verified that the bug was introduced by JDK-8186777. ILW = Wrong execution due to invalid optimization in C2 compiled method, easy to reproduce, -XX:DisableIntrinsic=_getClass = HHM = P1
19-10-2017
I'm able to reproduce this and it's definitely a C2 issue when compiling "jdk.nashorn.api.scripting.NashornScriptEngine::getInterfaceInner": -Xcomp -XX:-TieredCompilation -XX:CompileCommand=compileonly,jdk.nashorn.api.scripting.NashornScriptEngine::getInterface* Workaround: -XX:DisableIntrinsic=_getClass
19-10-2017
Reassigning to compiler. Without dkfl this shows up for everybody to look at. [~sundar] thank you for narrowing it down.
12-10-2017
I could also run javax/script/Test4.java along with/without flags on jdk10-master repo. Hannes reproduced failure with flags (-Xcomp -XX:MaxRAMPercentage=12.5 -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation) with jdk10/hs. Without flags, the test passed on jdk10-hs. => this is a hotspot compiler issue reproducible only on jdk10/hs with specific flags.
12-10-2017
I was able to reproduce the failure with above VM flags on jdk10/hs on Mac OS. However, the test runs successfully with the same flags on jdk10/master, so it seems to be something specific to the hs repository.
12-10-2017
This failure happened again with jdk10-hs-nightly-all-2017-10 http://java.se.oracle.com/mdash/jobs/mach5-one-jdk10-hs-nightly-all-2017-10-11-1-20171011-1347-2847/results http://java.se.oracle.com/mdash/jobs/mach5-one-jdk10-hs-nightly-all-2017-10-11-1-20171011-1347-2847?search=mach5-one-jdk10-hs-nightly-all-2017-10-11-1-20171011-1347-2847-tier4-comp-jdk_open_test_jdk_javax_script-linux-x64-debug-198 http://java.se.oracle.com/mdash/jobs/mach5-one-jdk10-hs-nightly-all-2017-10-11-1-20171011-1347-2847?search=mach5-one-jdk10-hs-nightly-all-2017-10-11-1-20171011-1347-2847-tier4-comp-jdk_open_test_jdk_javax_script-solaris-sparcv9-debug-200 I think it will be easiest to test on linux-x64 using jdk10/hs. I suspect the problem is with the particular VM flags. -Xcomp -XX:MaxRAMPercentage=12.5 -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation Please try to see if you can reproduce with these flags. If so, it's likely to be a compiler issue and you can change the bug category to hotspot/compiler.
12-10-2017
Hannes helped me with jdk10-hs repo - because I could not clone jdk10-hs locally due to net connectivity issues. But I eventually managed to clone jdk10/hs and reproduce the test failure on Mac. Minimal commands needed to reproduce: $ cd $jdk10_hs/test/jdk/javax/script $ jtreg -jdk:<jdk_10_hs_images_jdk_dir> -Xcomp -server -XX:-TieredCompilation Test4.java
12-10-2017
I just ran the tests in test/jdk/javax/script with http://hg.openjdk.java.net/jdk10/hs/ and couldn't reproduce the problem. All 19 tests in that directory pass. The changeset was 47383:fd0db78ac8d4 8188802: PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX))
05-10-2017
I ran javax.script [ and other jtreg & ant based nashorn/scripting related ] tests with jdk10-master tip this morning. All ran fine. ( changeset: 47312:d4f959806fe9 tag: tip user: joehw date: Wed Oct 04 10:54:18 2017 -0700 summary: 8187593: Cleanup: removing SecuritySupport files )
05-10-2017