RFR: 8345067: C2: enable implicit null checks for ZGC reads

[Emanuel Peter]

On Thu, 8 May 2025 10:21:14 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Currently, C2 cannot exploit late-expanded GC memory accesses as implicit null checks because of their use of temporary operands (`MachTemp`), which prevents `PhaseCFG::implicit_null_check` from [hoisting the memory accesses to the test basic block](https://github.com/openjdk/jdk/blob/f88c1c6ff86b8f29a71647e46136b6432bb67619/src/hotspot/share/opto/lcm.cpp#L319-L335).
>> 
>> This changeset extends the scope of the implicit null check optimization so that it can exploit ZGC object loads. It introduces a platform-dependent predicate (`MachNode::is_late_expanded_null_check_candidate`) to mark late-expanded instructions that emit a suitable memory access as a first instruction as candidates, and extends the optimization to recognize and hoist candidate memory accesses that use temporary operands:
>> 
>> ![example](https://github.com/user-attachments/assets/b5f9bbc8-d75d-4cf3-841e-73db3dbae753)
>> 
>> ZGC object loads are marked as late-expanded null-check candidates unconditionally on all ZGC-supported platforms except on aarch64, where only loads that do not require an initial `lea` instruction (due to [address legitimization](https://github.com/openjdk/jdk/blob/ddd07b107e814ec846579a66d4f2005b7db9bb2f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L132-L144)) are marked as candidates. Fortunately, most aarch64 loads seen in practice use small offsets and can be marked as candidates.
>> 
>> Exploiting ZGC loads increases the effectiveness of the implicit null check optimization (percent of explicit null checks turned into implicit ones at compile time) by around 10% in the DaCapo23 benchmarks. This results in slight performance improvements (in the 1-2% range) in a few DaCapo and SPECjvm2008 benchmarks and an overall slight improvement across Renaissance benchmarks.
>> 
>> #### Testing
>> - tier1-5, compiler stress test (linux-x64, macosx-x64, windows-x64, linux-aarch64, macosx-aarch64; release and debug mode).
>
> src/hotspot/share/opto/block.hpp line 468:
> 
>> 466: 
>> 467:   // If necessary, hoist orphan node n into the end of block b.
>> 468:   void maybe_hoist_into(Node* n, Block* b);
> 
> Hmm. It is "if necessary" or "if possible"?
> I wonder if we could come up with a name that is a little longer and expresses this condition?

Ah no, I'm starting to understand that it is rather a `if necessary`...

> src/hotspot/share/opto/lcm.cpp line 428:
> 
>> 426:         maybe_hoist_into(val->in(i), block);
>> 427:       }
>> 428:       move_into(val, block);
> 
> Suggestion:
> 
>         // Inputs of val may already be early enough, but if not move them together with val.
>         ensure_node_is_at_block_or_before(val->in(i), block);
>       }
>       move_node_and_its_projections_to_block(val, block);

It's a little hard to see here: did you just refactor this code, or make any changes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25066#discussion_r2079450181
PR Review Comment: https://git.openjdk.org/jdk/pull/25066#discussion_r2079507708