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

[Yangfei (Felix)]

Hi,

As mentioned in [1], JDK-8160369 have not been backported to JDK8u.  This is necessary for RMO architectures like aarch64.

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?

Thanks,
Felix

[1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030313.html