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

Doerr, Martin martin.doerr at sap.com
Tue Dec 3 14:48:02 UTC 2019


Hi,

I think there are already sufficient StoreStore barriers:

Regarding the Runtime1 calls, there's a full fence in ~ThreadInVMfromJava() (introduced by JRT_ENTRY) which is called before returning from the C++ code.

Seems like the eden allocation parts have explicit StoreStore barriers AFAICS.

Did I miss anything? Which path is it exactly where you miss such a barrier?

Best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Liu, Xin
> Sent: Dienstag, 3. Dezember 2019 12:01
> To: 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-
> dev at openjdk.java.net>
> Subject: [DMARC FAILURE] RFR(XS): 8234977: [Aarch64] C1 lacks a membar
> store in slowpath of allocate_array
> 
> Hi,
> 
> C1 misses a member for the slow path of alloc_array or alloc_obj on aarch64.
> We met this problem when we ran jcstress on AWS graviton processor,
> which might reorder stores.   Without a storestore member, put_field behind
> might commit to memory ahead of array/object initialization.
> This change tries to fix that by adjusting bound location. Could reviewers help
> me  to review this change?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234977
> Webrev: https://cr.openjdk.java.net/~xliu/8234977/00/webrev/
> 
> Validation:  I passed jcstress and hotspot tier1 on arch64.
> 
> Thanks,
> --lx
> 
> 



More information about the hotspot-compiler-dev mailing list