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

[Joshua Cao]

On Sun, 23 Jun 2024 07:11:41 GMT, Joshua Cao <duke at openjdk.org> wrote:

>> [C2 emits a StoreStore barrier for each constructor call](https://github.com/openjdk/jdk/blob/72ca7bafcd49a98c1fe09da72e4e47683f052e9d/src/hotspot/share/opto/parse1.cpp#L1016) in a chain of superclass constructor calls. 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.
>> 
>> This PR modifies `Parse::do_exits()` such that it only emits a barrier for a constructor if we find that the constructed object does not have an `InitializeNode`. It is possible that we cannot find an `InitializeNode` i.e. if the outermost method of the compilation unit is the constructor. We still need to emit a barrier in these cases.
>> 
>> Passes hotspot tier1 locally on x86 linux machine. New tests make sure that there is a single `StoreStore` for chained constructors.
>
> Joshua Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Attempt2: Only emit StoreStore in do_exits when there is no parent
>    caller
>  - Merge branch 'master' of https://git.openjdk.org/jdk into chainstorestore
>  - 8032218: Emit single post-constructor barrier for chain of superclass constructors
>  - Add riscv64 to test
>  - Merge branch 'master' into storestore
>  - Merge branch 'master' into storestore
>  - Apply suggestions from code review
>    
>    some formatting suggestions from @shipilev
>    
>    Co-authored-by: Aleksey Shipilëv <shipilev at amazon.de>
>  - Guard everything by feature flag
>  - Revert "Statistics for barriers generated/eliminated"
>    
>    This reverts commit 33d23635048afd3a1b40ae91e6fadf577742fa4f.
>  - Make flag product diagnostic and guard string concat storestore by flag
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/72ca7baf...2a201397

Had some merge conflicts with https://bugs.openjdk.org/browse/JDK-8333791. As I understand it, when it comes to post-constructor barriers, we can treat stable and final fields the same. Fixed the merge conflict and added tests to reflect those changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18870#issuecomment-2295161506