JDK-8286805 : Add stress mode for C2 loop optimizations
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2022-05-16
  • Updated: 2024-11-18
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.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8288981 - C2: Fix issues with skeleton predicates
Description
There are several policies/heuristics in C2's loop optimizations. For example, IdealLoopTree::policy_peeling decides based on the node count if peeling should be attempted. We should add a stress flag that randomizes these decision (50/50 or so). 

We should also consider not hardcoding values like LoopNode::_unswitch_max.
Comments
Yet another idea for stress testing: Randomly not hoist checks out of a loop with Loop Predication which we normally would.
18-11-2024
Another idea unrelated to loopopts: Shuffle outputs for a node such that the DUIterator* choose a different order.
11-01-2024
Another idea for stress testing: Randomize the Split-If node visiting order in PhaseIdealLoop::split_if_with_blocks().
10-01-2024
We should also introduce an OSR compilation stress mode to trigger OSR compilations for loops randomly. I think the easiest way would be to use a low Tier*BackedgeNotifyFreqLog and when calling into the runtime to check if Tier*BackEdgeThreshold is reached, we just say "yes" randomly and trigger an OSR compilation. This gives all loops, no matter how many iterations they execute, a chance to be OSR compiled. Should be straightforward to implement.
16-11-2023
Another thing that could be stressed are random cut off values when limiting the distance to walk through the graph. Example: https://github.com/chhagedorn/jdk/blob/514816ed7d7dea1fb13d32b80aef89774bee13d3/src/hotspot/share/opto/ifnode.cpp#L1468 But might not directly be related to stressing loop opts.
12-07-2023
Another idea: do more loop-opts rounds than required. Often some loops are supposedly "finished", but sometimes create issues when we run loop-opts over them again. That then requires other loops in the reproducer that cause more loop opts. Maybe removing the need for the additional loops could improve stress testing.
08-12-2022
Note: when running stress testing with StressLoopOpts, you may want to also set some loop opts limits high. LoopUnrollLimit LoopMaxUnroll LoopUnswitchingMax etc I still intend to respect those limits, so that we do not bail out because we use too many nodes, or other issues. But setting them higher may allow for more combination, and more stressing, which could be advantageous for testing.
22-06-2022
And bailouts in superword that are due to heuristics suggesting that it's not profitable.
16-06-2022
Other examples are all the policy_* methods.
16-05-2022