> 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 incrementally with one additional commit since the last revision: Address part of PR review 4 & fix a bug setting only_candidate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/329d9f40..78435065 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=09-10 Stats: 72 lines in 8 files changed: 15 ins; 17 del; 40 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
