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

[Cesar Soares Lucas]

On Tue, 25 Apr 2023 21:19:06 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> @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.

Thanks for clarifying. There is one scenario where turning the candidate into a "real object" simplify the implementation _greatly_. The scenario is when the ObjectValue is not just a candidate. I.e., the ObjectValue is also used independently of the merge. Example:


Point p = new Point();
Point q = new Point();
if (cond) p = q;
trap(p, q);


Second issue, is that allocating a fresh ObjectValue will require copying the array of field values from the candidate object to the newly allocated object. That's not a big issue, just pointing that out, though.

I propose that we allocate a fresh ObjectValue if the candidate is just a candidate (not used independent of merge) and if the candidate is not just a candidate we return the existing ObjectValue (turned 'real object'). I have that implemented, I can push it for you to take a look. What do you think?

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

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