Bug ID: JDK-8252219 C2: Randomize IGVN worklist for stress testing

Versions (Unresolved/Resolved/Fixed)

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 16
16 b18Fixed

Bugs often depend on the order in which nodes are processed by IGVN. For example, IGVN worklist order depends on (incremental) inlining decisions that vary from compilation to compilation due to different profiling information which makes some bugs very hard to reproduce.

Randomizing IGVN worklist access might help to trigger some bugs more often:
-    Node* n  = _worklist.pop();
+    // Randomize access to worklist
+    int idx = (os::random() % _worklist.size());
+    Node* n = _worklist.remove(idx);

I gave above code a quick try and executed tier1 - tier5: No new failures but it may still pay off to introduce this for stress testing.

Changeset: fed3636f Author: Roberto Castaneda Lozano <roberto.castaneda.lozano@oracle.com> Committer: Tobias Hartmann <thartmann@openjdk.org> Date: 2020-09-28 06:44:58 +0000 URL: https://git.openjdk.java.net/jdk/commit/fed3636f
28-09-2020
StressLCM and StressGCM were introduced to randomize instruction placement/selection for jcstress. While it might not be immediately useful to discover more concurrency bugs, StressIGVN might also be useful. Filed CODETOOLS-7902768 to support this. (Aside: it would be nice to have StressRA [regalloc] too!)
18-09-2020
That's a good idea.
28-08-2020
Yes, good point. Maybe it's sufficient to just shuffle once after parsing and ignore new nodes added later.
27-08-2020
With a shuffling at the beginning of igvn, we have the advantage that we have a guarantee that we make progress. For example, in MemNode::Ideal_common we can push `this` again to the worklist to wait until the memory is processed. All the nodes that "wait until node X is processed" might be selected again and readded to the list - possibly delaying igvn for an indefinite amount of time if we are unlucky (we would then hit the infinite loop assert in PhaseIterGVN::dump_infinite_loop_into()). So we need to be careful when selecting random indices especially with a fixed seed and when we have only one method to compile, for example.
27-08-2020
> there should be a way to control the randomization to reproduce problematic order Yes, but I think we should use a seed on a per-compilation basis because otherwise the randomization would also depend on the compilation order of methods. > Should we also try to shuffle _worklist after parser? Yes, but I think we would not shuffle the worklist but rather randomize each access.
25-08-2020
Agree. Should we also try to shuffle _worklist after parser?
24-08-2020
Good idea. To help with failure analysis, there should be a way to control the randomization to reproduce problematic order. Tests achieve that by publishing the seed value when it is picked randomly and allowing to override it.
24-08-2020

Relates :	JDK-8253748 - StressIGV tests fail with release VMs
Relates :	JDK-8253766 - compiler/debug/TestGenerateStressSeed.java fails with NoSuchFileException
Relates :	JDK-8253767 - compiler/debug/TestStressIGVN.java fails with RuntimeException: got the same IGVN trace for different seeds: expected to not equal
Relates :	JDK-8254810 - gtest for os::random() fails on windows x64
Relates :	JDK-8325482 - Test that distinct seeds produce distinct traces for compiler stress flags
Relates :	JDK-8311279 - TestStressIGVNAndCCP.java failed with different IGVN traces for the same seed
Relates :	JDK-8272703 - StressSeed should be set via FLAG_SET_ERGO
Relates :	CODETOOLS-7902768 - jcstress should support -XX:+StressIGVN
Relates :	CODETOOLS-7903041 - jcstress: Provide explicit StressSeed when available
Relates :	JDK-8314836 - 4 compiler/debug tests ignore tested VM flags
Relates :	JDK-8253765 - C2: Control randomization in StressLCM and StressGCM