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

[Vladimir Ivanov]

On Tue, 25 Apr 2023 00:10:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> 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?

I don't mind there's caching happening if it gives any noticeable benefit. As of now, the code around doesn't care, probably, because it is allocated in resource arena.

What I'm against is repurposing existing instances: don't modify a candidate object into a "real object", allocate a fresh one instead.

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

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