RFR(XS): 8234977: [Aarch64] C1 lacks a membar store in slowpath of allocate_array

Liu, Xin xxinliu at amazon.com
Wed Dec 4 07:23:06 UTC 2019


Hi, Andrew and Martin, 

The slowpath I refer to is the JRT new_type_array. 
 https://hg.openjdk.java.net/jdk/jdk/file/a1802614d6fe/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp#l855

Martin is right.  the JRT function is actually guarded by a mfence.   Thank you to point it out! 
My previous understanding was wrong.  I acknowledge that the extra "membar(StoreStore)" is unnecessary  when the control flow returns from the slow path. 

I withdraw my webrev.  My fix can  solve our problem on jdk8u and jdk11, but it is too lame. I found that the root cause  is JDK-8233839, so I marked my bug 'duplication'. 
I will propose to backport  JDK-8233839 to jdk8u-aarch64. 

On the other side,  can I say  C2 has a redundant membar(StoreStore). Is it worth optimizing it? 
The branch at  0x0000ffff8056bef0 of https://bugs.openjdk.java.net/secure/attachment/85882/hotspot_pid4218.c2.log is the return from slow-path

Thanks,
--lx



On 12/3/19, 8:18 AM, "aph at redhat.com" <aph at redhat.com> wrote:

    On 12/3/19 6:00 AM, Liu, Xin wrote:
    > C1 misses a member for the slow path of alloc_array or alloc_obj on aarch64. 
    
    I don't understand this. In the slow path, the MemAllocator::finish should
    insert the necessary membar. Can you show us the slow path which does not
    do the membar?
    
    -- 
    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
    
    



More information about the hotspot-compiler-dev mailing list