RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v3]

[Cesar Soares Lucas]

> Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges?
> 
> 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:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> 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:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently.
> 
> The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Fix some typos and do some small refactorings.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/ea67a304..3b492d2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01-02

  Stats: 72 lines in 8 files changed: 1 ins; 7 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897