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

[Cesar Soares Lucas]

On Sat, 22 Apr 2023 01:52:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> 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 10 commits:
>> 
>>  - 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.
>>  - Merge with Master
>>  - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
>>  - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>>  - Add support for SR'ing some inputs of merges used for field loads
>>  - Fix some typos and do some small refactorings.
>>  - Merge master
>>  - Add support for rematerializing scalar replaced objects participating in allocation merges
>
> src/hotspot/share/code/debugInfo.cpp line 257:
> 
>> 255:   } else {
>> 256:     assert(selector < _possible_objects.length(), "sanity");
>> 257:     _selected = (ObjectValue*) _possible_objects.at(selector);
> 
> Any particular reason to reuse `ObjectValue` from `_possible_objects` instead of allocating a fresh one (as you do on `selector == -1` bracnh)? I'd prefer `ObjectMergeValue::select()` to always allocate a fresh `ObjectValue` when converting `ObjectMergeValue` + `ObjectMergeCandidateValue` into `ObjectValue`.

@iwanowww - may I ask why always allocating a fresh object might be better than returning a pointer to a previous "selected" object?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1175897406