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

[Andrew Haley]

Hi,

On 25/08/2020 13:53, Yangfei (Felix) wrote:
>
>> -----Original Message-----
>> From: Andrew Haley [mailto:aph at redhat.com]
>> Sent: Tuesday, August 25, 2020 5:18 PM
>> To: Yangfei (Felix) <felix.yang at huawei.com>; jdk8u-dev at openjdk.java.net
>> Subject: Re: RFR Backport 8165808: Add release barriers when allocating
>> objects with concurrent collection
>>
>> On 25/08/2020 09:56, Yangfei (Felix) wrote:
>>>> Yes, certainly. Thanks.
>>> Thanks for quick review.
>>> I have add new label jdk8u-fix-request and necessary comment on the
>> issue.
>>
>> By the way, there are many places where arrays are allocated. Do you know
>> why only this particular one needs a release barrier?
>
> Not sure if I understand the question correctly.
> I think the common entry points are CollectedHeap::obj_allocate & CollectedHeap::array_allocate.  These functions finally calls CollectedHeap::post_allocation_setup_common.
> Many places will call these functions to create objects.  For example,
> InstanceKlass::allocate_objArray -> CollectedHeap::array_allocate -> CollectedHeap::post_allocation_setup_array -> CollectedHeap::post_allocation_setup_common
> Since we do a release store in CollectedHeap::post_allocation_setup_common, so all the places where objects are created will benefit.

There is code at MacroAssembler::eden_allocate and
PhaseMacroExpand::expand_allocate_common which does object
allocation. If CollectedHeap::obj_allocate needs release barriers, why
don't those places need them too? Is there another patch which adds
such release barriers that also needs to be backported?

-- 
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