RFR: 8300148: Consider using a StoreStore barrier instead of Release barrier on ctor exit [v9]

[Joshua Cao]

On Fri, 5 Apr 2024 20:26:08 GMT, Dean Long <dlong at openjdk.org> wrote:

> This case and the next case could use a more detailed explanation. We have 4 different possible inputs:
{StoreStore, Release} x {w/ Precedent, w/o Precedent} and 2 possible outcomes: worklist or record_for_optimizer.

We can eliminate barriers when it's precedent is an escaping object. If the barrier does not have a precedent, we cannot elide it, which is why we don't include it in the worklist / `record_for_optimizer`.

I think its confusing because StoreStore barriers are optimized in `escape.cpp`, while `Release` barriers are optimized in [memnode.cpp](https://github.com/openjdk/jdk/blob/115f4193eb39d8469ac8127e38798a3f041c22e0/src/hotspot/share/opto/memnode.cpp#L3431). I would have preferred if all escape-based on optimizations of barriers were just done in one place.

> Previously, I believe this optimization did not apply to the end-of-ctor-with-final barrier, but now it does.

This is correct. End of ctor did not have `StoreStore` barriers. They had `Release` barriers, which escape analysis already handles. We have to check `n->req() > MemBarNode::Precedent`, or else we run into assertion errors [here](https://github.com/openjdk/jdk/blob/9ac3b77d0d69227ded6ef3843ebf5c18ceee37b5/src/hotspot/share/opto/escape.cpp#L2590)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18505#discussion_r1556115517