RFR: 8032218: Emit single post-constructor barrier for chain of superclass constructors

[Dean Long]

On Fri, 19 Apr 2024 22:31:10 GMT, Joshua Cao <duke at openjdk.org> wrote:

> Opening this PR on top of https://github.com/openjdk/jdk/pull/18505. This PR is only valid if we agree it is sufficient to use `StoreStore` barriers at the end of constructors instead of `Release` barriers.
> 
> Currently on master, [C2 emits a Release barrier for each constructor call](https://github.com/openjdk/jdk/blob/32946e1882e9b22c983cbba3c6bda3cc7295946a/src/hotspot/share/opto/parse1.cpp#L1019) in a chain of superclass constructor calls. After https://github.com/openjdk/jdk/pull/18505 is merged, it is the same except that the barrier is a `StoreStore`. It is unnecessary. We only need to emit a single barrier for each object allocation / each pair of `Allocation/InitializeNode`. 
> 
> [Macro expansion emits a trailing StoreStore after an InitializeNode](https://github.com/openjdk/jdk/blob/32946e1882e9b22c983cbba3c6bda3cc7295946a/src/hotspot/share/opto/macro.cpp#L1610-L1628). This `StoreStore` is sufficient as the post-constructor barrier. From the [InitializeNode definition](https://github.com/openjdk/jdk/blob/32946e1882e9b22c983cbba3c6bda3cc7295946a/src/hotspot/share/opto/memnode.cpp#L3639-L3642):
> 
>> // An InitializeNode collects and isolates object initialization after
> // an AllocateNode and before the next possible safepoint.  As a
> // memory barrier (MemBarNode), it keeps critical stores from drifting
> // down past any safepoint or any publication of the allocation.
> 
> All the writes that occur in the constructor will come before the `InitializeNode/StoreStore`. This PR removes the emitting of `StoreStore` barriers in `Parse::do_exits()`. This PR subsumes https://github.com/openjdk/jdk/pull/18505.
> 
> Passes hotspot tier1 locally on x86 linux machine. New tests make sure that there is a single `StoreStore` for chained constructors.

If the subclass ctor inlines the super ctor, it might be safe to omit the barrier from the super ctor.  However, the current approach seem to remove barriers that are needed when the `<init>` is called from the interpter or another compiled method.

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

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18870#pullrequestreview-2018617323