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

[Cesar Soares Lucas]

On Mon, 8 May 2023 18:21:09 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 12 commits:
>> 
>>  - 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.
>>  - 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.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1
>
> Speaking of debug info design, it seems there's a need for an additional transformation step now.
> 
> Originally, all the operations were performed right on the deserialized debug info representation. It was well-justified at first, but slowly accrued with special cases (nulls, autobox, vectors) and merges push it over the limit IMO.
> 
> I propose to introduce an additional pass which takes original debug info and, based on current JVM state (`frame` + `RegisterMap`), transforms it into a list of objects to be materialized and a graph of `ScopeValue`s which depend on them. It would isolate preprocessing logic you have scattered across multiple places, simplify rematerialization, make it easier to find out what happens during deoptimizaiton in each particular case. Moreover, it'll enable support for more complex scenarios (e.g., nested merges) which I expect to eventually emerge in followup enhancements.

Thank you @iwanowww for taking the time to review this! Please let me ask you some clarifying questions.

> A couple of minor comments first [...]

I'll address those asap! Thanks.

> I propose to introduce an additional pass which takes original debug info [...]

What kind of pass are you referring to exactly? When would this pass run? By "original debug info" you mean the debug information stream?

> It would isolate preprocessing logic you have scattered across multiple places [...]

Which preprocessing logic are you referring to exactly?

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1539161396