RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v16]
Cesar Soares Lucas
cslucas at openjdk.org
Tue Jun 6 16:51:04 UTC 2023
> Can I please get reviews for this PR?
>
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>
> 
>
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>
> 
>
> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
- Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
Catching up with master.
- Address PR review 6: debug format output & some refactoring.
- Catching up with master branch.
Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
- Address PR review 6: refactoring around rematerialization & improve test cases.
- Address PR review 5: refactor on rematerialization & add tests.
- Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
- Address part of PR review 4 & fix a bug setting only_candidate
- Catching up with master
Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
- Fix tests. Remember previous reducible Phis.
- Address PR review 3. Some comments and be able to abort compilation.
- ... and 7 more: https://git.openjdk.org/jdk/compare/ca6f07f9...cb0b6702
-------------
Changes: https://git.openjdk.org/jdk/pull/12897/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=15
Stats: 2741 lines in 26 files changed: 2486 ins; 113 del; 142 mod
Patch: https://git.openjdk.org/jdk/pull/12897.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897
PR: https://git.openjdk.org/jdk/pull/12897
More information about the hotspot-dev
mailing list