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