RFR: 8367627: C2: Missed Ideal() optimization opportunity with MemBar [v2]

Benoît Maillard bmaillard at openjdk.org
Mon Nov 24 09:30:12 UTC 2025


> This PR addresses a missed optimization in `PhaseIterGVN` for `MemBarAcquire` nodes caused by a missing notification during parsing.
> 
> The missed optimization in question is the removal of the the `in(MemBarNode::Precedent)` edge for
> `MemBarAcquire` nodes when the the `MemBar` is the only user of its input. This was intially
> introduced to get rid of unused `Load` nodes that were only kept alive by such an edge.
> 
> 
> 
> https://github.com/openjdk/jdk/blob/eeb7c3f2e8e645938d9db0cf61c1d98d751f2845/src/hotspot/share/opto/memnode.cpp#L4254-L4259
> 
> In our case, it happens that the `Load` node gets folded to a constant during the initial
> `_gvn.transform` call in `GraphKit::make_load`. Because the value is converted before being
> returned, we end up with two constant nodes: one `ConL` and one `ConI`. The `ConL` only
> has one usage, and this triggers the optimization during verification.
> 
> 
> static int test0() {
>     var c = new MyClass();
>     // the conversion ensures that the ConL node only has one use
>     // in the end, which triggers the optimization
>     return (int) c.l;
> }
> 
> 
> The optimization is not triggered earlier during when we apply `_gvn.transform` on the membar,
> because it requires `can_reshape`, which is set to `false` in when we call `apply_ideal` in
> `PhaseGVN::transform`.
> 
> For this reason, we should call `record_for_igvn(membar)` after the `MemBar` is created
> and transformed in `GraphKit::insert_mem_bar` to make sure it gets an `Ideal` pass with
> `can_reshape` later.
> 
> 
> This issue was initially filed for Valhalla, because a condition in `GraphKit::make_load`
> prevents its from occurring when boxing elimination is enabled. Boxing elimination is
> disabled temporarily in Valhalla (see [JDK-8328675](https://bugs.openjdk.org/browse/JDK-8328675)),
> which caused the issue to appear, but by using `-XX:-EliminateAutoBox` it became clear
> that the issue was on mainline.
> 
> ### Testing
> - [x] [GitHub Actions](TODO)
> - [x] tier1-3, plus some internal testing
> 
> Thank you for reviewing!

Benoît Maillard has updated the pull request incrementally with one additional commit since the last revision:

  Add run with -XX:+AlwaysIncrementalInline, and add intermediate run for -XX:-DoEscapeAnalysis

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28448/files
  - new: https://git.openjdk.org/jdk/pull/28448/files/64ada0cb..c3c2ceee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28448&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28448&range=00-01

  Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28448/head:pull/28448

PR: https://git.openjdk.org/jdk/pull/28448


More information about the hotspot-compiler-dev mailing list