On Mon, 8 May 2023 18:21:09 GMT, Vladimir Ivanov <vliva...@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
