JDK-8251925 : C2: RenaissanceStressTest fails with assert(!had_error): bad dominance
Type:Bug
Component:hotspot
Sub-Component:compiler
Affected Version:11.0.10-oracle,16
Priority:P3
Status:Resolved
Resolution:Fixed
Submitted:2020-08-18
Updated:2021-01-04
Resolved:2020-11-23
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.
This appears to be a recent regression and unrelated to JDK-8249607 which is a fuzzer test failure detected some time ago. They both hit the same generic assert(!had_error).
Comments
Fix request (11u)
I would like to downport this for parity with oracle. Applies clean.
This is a follow up for JDK-8249749 which I want to downport to 11.0.11. I would like to push this to 11.0.11, too, as it is a follow up issue of that bug.
We need to backport this fix into 11u-oracle because JDK-8249749 was backported there.
30-10-2020
[~chagedorn] Please share your reproducer command-line. I'd like to use it as a replay test case.
29-10-2020
If you run with
-Djdk.internal.lambda.dumpProxyClasses=DUMP_CLASS_FILES
-Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
do you get the .class files you need for replay?
[~vlivanov] also has a patch that might help.
28-10-2020
[~dlong] Thanks for the tips. Unfortunately, this does not generate the class file I need. It seems that the required class file is generated dynamically by the benchmark itself.
However, I was finally able to reproduce it locally and attach a debugger to it by directly running the benchmark (without going over the RenaissanceStressTest). This should simplify the analysis.
28-10-2020
I think we need to accelerate our Compilation Replay improvement project.
27-10-2020
I attached the latest test failure output lca_output.txt.
Note, JDK-8251994 was fixed in jdk-16+22-1282 but latest failure happened in jdk-16+22-1291.
27-10-2020
So the issue is why early node for Bool node:
early(n): 2928 IfTrue === 2927 [[ 2929 323 2908 3349 ]] #1 !orig=[3305] !jvms: GenericMutableRow::isNullAt @ bci:2 GeneratedClass$SpecificUnsafeProjection::apply @ bci:397
is the node after loop exit ?:
n->out(0): 2899 CountedLoopEnd === 2898 2874 [[ 2900 2923 ]] [lt] P=0.500000, C=13008.000000 !orig=[2386],[1641] !jvms: BaseGenericInternalRow$class::getInt @ bci:5 GenericMutableRow::getInt @ bci:2 GeneratedClass$SpecificUnsafeProjection::apply @ bci:387
2900 IfTrue === 2899 [[ 2893 ]] #1 !orig=[1306] !jvms: BaseGenericInternalRow$class::getInt @ bci:5 GenericMutableRow::getInt @ bci:2 GeneratedClass$SpecificUnsafeProjection::apply @ bci:387
2923 IfFalse === 2899 [[ 2927 ]] #0 !jvms: GenericMutableRow::isNullAt @ bci:2 GeneratedClass$SpecificUnsafeProjection::apply @ bci:397
Looks like domination information for Bool node was not updated when pre-loop was cloned.