RFR: 8331295: C2: High memory usage reported in PhaseChaitin::Split

[Daniel Lundén]

On Sat, 16 Nov 2024 00:57:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> On aarch64, the C2 instruction matcher often clones addressing expressions, expecting them to be subsumed (during later stages of matching) into complex load/store instructions. However, volatile aarch64 load and store instructions have indirect memory inputs and therefore cannot subsume the addressing computation. In one case that we investigated, the result is a very large number of cloned identical instructions for address computations that, in combination with how the instruction scheduler currently hoists instructions, create major difficulties for the register allocator.
>> 
>> ### Changeset
>> 
>> - Add a guard that ensures the instruction matcher does not clone addressing expressions that have at least one successor load/store that cannot subsume the addressing computation. One could argue that, in cases where there is at least one such successor, other successors may be able to subsume the computation and we should therefore still clone the expression. The benefit of subsuming in such a case is unclear, however, as we in any case need to generate at least one separate instruction for the addressing computation.
>> - Remove temporary `-XX:CompileCommand=memlimit,...,0` for tests that previously failed.
>> - Add a new IR framework regression test.
>> 
>> ### Testing
>> 
>> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/11859255022)
>> - `tier1` to `tier4` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64.
>> - Performance benchmarks: DaCapo, SPECjbb, and SPECjvm on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64. No clear regressions.
>
> Hi, after this PR integrated, should we backout the change of https://github.com/openjdk/jdk/pull/21586

@sendaoYan Thanks for checking! It has already been reverted in [JDK-8344018](https://bugs.openjdk.org/browse/JDK-8344018) (and also turned out to be a separate issue: [JDK-8343038](https://bugs.openjdk.org/browse/JDK-8343038)).

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

PR Comment: https://git.openjdk.org/jdk/pull/22157#issuecomment-2480491521