[aarch64-port-dev ] RFR: 8144993: Elide redundant memory barrier after AllocationNode

[Doerr, Martin]

Hi,

I think this change is good with respect to concurrent java threads.
However, I'm not sure if concurrent GC may have a problem when we optimize out the memory barrier (with or without this change).

Is it guaranteed that no concurrent GC will ever read an object header of such a newly allocated object?
A reference to this object may get written somewhere where GC can find it. If the GC reads the header, it may read stale data.

Best regards,
  Martin


-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Aleksey Shipilev
Sent: Dienstag, 15. Dezember 2015 10:06
To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; Hui Shi <hui.shi at linaro.org>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; aarch64-port-dev <aarch64-port-dev at openjdk.java.net>
Subject: Re: RFR: 8144993: Elide redundant memory barrier after AllocationNode

* PGP Signed by an unknown key

Also, I think this is a duplicate of:
 https://bugs.openjdk.java.net/browse/JDK-8032481

-Aleksey

On 12/15/2015 05:40 AM, Vladimir Kozlov wrote:
> Very interesting!
> 
> Please, add short statement to the comment in /macro.cpp for your case.
> 
> Changes looks fine to me. One nit could be to delay bytecode analysis
> until macro expansion - it may reduce compilation time. Bytecode
> analysis of each constructor could be expensive.
> 
> Thanks,
> Vladimir
> 
> On 12/10/15 6:48 AM, Hui Shi wrote:
>> Hi All,
>>
>>
>> Could some one help comments this change?
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144993
>>
>> webrev: http://cr.openjdk.java.net/~hshi/8144993/webrev/
>>
>>
>> This patch aims to remove redundant memory barrier after allocation
>> node, on AArch64 it removes redundant dmb when creating object. The
>> motivation is dmb instructions after commonly used object allocation,
>> for example string and boxing objects is redundant with dmb inserted for
>> final field write. In following small case:____
>>
>> __ __
>>
>> String foo(String s)____
>>
>> {____
>>
>>     String copy = new String(s);____
>>
>>     return copy;____
>>
>> }____
>>
>> __ __
>>
>> There are two dmb instructions in generated code. First one is
>> membar_storestore, inserted in PhaseMacroExpand::expand_allocate_common.
>> Second one is membar_release, inserted at exit of initializer method as
>> final fields write happens. Allocated String doesn't escape in String
>> initializer method, membar_release includes membar_storestore semantic.
>> So first one can be removed safely.____
>>
>> __ __
>>
>>    0x0000007f85bbfa8c: prfm      pstl1keep, [x11,#256]____
>>
>>    0x0000007f85bbfa90: str       xzr, [x0,#16]____
>>
>>    0x0000007f85bbfa94: dmb       ishst        // first dmb to remove____
>>
>>    ....____
>>
>> ____
>>
>>    0x0000007fa01d83c0: ldrsb     w10, [x20,#20]____
>>
>>    0x0000007fa01d83c4: ldr       w12, [x20,#16]____
>>
>>    0x0000007fa01d83c8: ldr       x11, [sp,#8]____
>>
>>    0x0000007fa01d83cc: strb      w10, [x11,#20]____
>>
>>    0x0000007fa01d83d0: str       w12, [x11,#16]____
>>
>>    0x0000007fa01d83d4: dmb       ish        // second dmb____
>>
>> __ __
>>
>>
>> Patch targets this pattern and remove redundant memory barrier for
>> allocation node.____
>>
>> 1. When inserting memory barrier for final field write. If final fields'
>> object allocation node is available, invoke
>> AllocationNode::compute_MemBar_redundancy(initializer method).____
>>
>> 2. In AllocationNode:____
>>
>>      2.1 Add a new field _is_allocation_MemBar_redundant flag indicate
>> if memory barrier after allocation node is redundant.____
>>
>>     2.2 Add method compute_MemBar_redundancy, set
>>   _is_allocation_MemBar_redundant true if first parameter "this" does
>> not escape in initializer method according to BCEscapeAnalyzer.____
>>
>> 3. skip inserting memory barrier in
>> PhaseMacroExpand::expand_allocate_common, when AllocationNode's
>> _is_allocation_MemBar_redundant flagis true.
>>
>>
>> Regards
>>
>> Hui
>>



* Unknown Key
* 0x62A119A7