RFR Backport 8165808: Add release barriers when allocating objects with concurrent collection

[Andrew Haley]

On 25/08/2020 09:05, Yangfei (Felix) wrote:
> JDK-8165808 is the first subtask of JDK-8160369.
> Original bug:https://bugs.openjdk.java.net/browse/JDK-8165808
> Original patch:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fd16b627ebc5  
> Original review thread:http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-September/024487.html  
> 
> The original patch does not apply cleanly to jdk8u-dev due to path and code refactoring work in jdk9+.
> Webrev for 8u:http://cr.openjdk.java.net/~fyang/8165808-8u/webrev.00/  
> 
> 1. The changes in CollectedHeap::post_allocation_setup_class of the original patch is not necessary for backport as this function is not there in jdk8u.
>      For jdk9+, the call chain is:
>          InstanceMirrorKlass::allocate_instance -> CollectedHeap::class_allocate -> CollectedHeap::post_allocation_setup_class -> CollectedHeap::post_allocation_setup_common
>      For jdk8u, we have:
>          InstanceMirrorKlass::allocate_instance -> CollectedHeap::obj_allocate -> CollectedHeap::post_allocation_setup_obj -> CollectedHeap::post_allocation_setup_common
> 
> 2. Also adapted the way of adding inline keyword for new function oopDesc::release_set_klass.
> 
> Performed full jtreg test with release & fastdebug builds both on aarch64-linux and x86_64-linux platforms.
> OK to backport?

Yes, certainly. Thanks.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671