> 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 20 commits: - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Merge branch 'openjdk:master' into rematerialization-of-merges - Rome minor refactorings. - 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 - ... and 10 more: https://git.openjdk.org/jdk/compare/5ca4cdd2...d7cf00af ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=18 Stats: 2732 lines in 26 files changed: 2484 ins; 108 del; 140 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
