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

[Joshua Cao]

On Wed, 10 Apr 2024 20:09:04 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)
>
>> I would have preferred if all escape-based on optimizations of barriers were just done in one place.
> 
> It sounds like there is still some cleanup that could be done in this area.  Is it worth a separate RFE?

Yes, I think so. Created https://bugs.openjdk.org/browse/JDK-8330062

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

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