RFR: 8285820: C2: LCM prioritizes locally dependent CreateEx nodes over projections after 8270090

[Tobias Hartmann]

On Fri, 6 May 2022 10:42:52 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset lowers the priority of locally-dependent CreateEx nodes, that is CreateEx nodes that are not initially ready for scheduling in LCM. The proposed scheme assigns them the same priority as projection nodes when selecting the next node to be scheduled, restoring the relative prioritization between projections and CreateEx nodes to the state it was before [JDK-8270090](https://bugs.openjdk.java.net/browse/JDK-8270090). JDK-8270090 wrongly gave all CreateEx nodes the highest priority, which leads to failures whenever projection nodes are expected to get higher priority than locally-dependent CreateEx nodes. See the [JBS issue report](https://bugs.openjdk.java.net/browse/JDK-8285820) for further detail.
> 
> More specifically, the current ranking to select the next node to be scheduled in `PhaseCFG::select()` is:
> 
> 1. CreateEx nodes (initially ready or not)
> 2. Projections
> 3. Constants and CheckCastPP nodes (tie)
> 4. ...
> 
> After this changeset, the ranking becomes:
> 
> 1. Initially ready CreateEx nodes
> 2. Projections and other CreateEx nodes (tie)
> 3. Constants and CheckCastPP nodes (tie)
> 4. ...
> 
> which still addresses the issue handled by JDK-8270090 but in a form that is closer to the original ranking before JDK-8270090:
> 
> 1. Initially ready CreateEx nodes
> 2. Projections, other CreateEx nodes, constants and CheckCastPP nodes (tie)
> 3. ...
> 
> This changeset implements the minimal changes to restore the relative prioritization between CreateEx nodes and projections to the state it was before JDK-8270090, for risk minimization and ease of backporting. I will file a separate RFE proposing a more robust alternative than altering the order of the LCM worklist for ensuring that initially ready CreateEx nodes are scheduled at the block start.
> 
> #### Testing
> 
> ##### Functionality
> 
> - Original failure on x86_32 using `-XX:+UseShenandoahGC` (thanks to Aleksey Shipilev for testing).
> - Original failure of JDK-8270090 on arm32 (thanks to Marc Hoffmann for testing).
> - hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; release and debug mode).
> - hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; debug mode) with StressLCM and StressGCM (5 different seeds).
> 
> ##### Performance
> 
> Tested performance on a set of standard benchmark suites (DaCapo, SPECjbb2015, SPECjvm2008, ...) and on linux-x64, linux-aarch64, windows-x64, and macosx-x64. No significant regression was observed.

Looks reasonable to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8568