[aarch64-port-dev ] RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire (original) (raw)
Andrew Haley aph at redhat.com
Mon Nov 23 15:15:16 UTC 2015
- Previous message: [aarch64-port-dev ] RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire
- Next message: XS review: 8098557: Eager initialization of a super interface with a default method
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 11/23/2015 03:07 PM, Edward Nevill wrote:
On Fri, 2015-11-20 at 22:07 +0800, Hui Shi wrote: Hi,
Could someone help review and sponsor this fix for aarch64 runtime? Bug: https://bugs.openjdk.java.net/browse/JDK-8143285 webrev: http://cr.openjdk.java.net/~hshi/8143285/webrev/ Hi Shi Hui, Thanks for finding this. Do you think this should be predicated on 'UseBarriersForVolatile'
No, this is fine. This isn't a Java volatile, it's VM-internal. AArch64 ldar/stlr work just fine for it on all hardware.
IE.
if (UseBarrieresForVolatile) { } else { / } This seems to be the only code in the Template Interpreter or C1 that uses acquire release. The only place acquire release is used otherwise is in C2. Do you think we should just use membar to fix this problem and then as a separate issue look at whether we augment the membars in Template Interpreter / C1 to load acquire / store release when possible.
No, this is fine. The wider question of changing the Template Interpreter / C1 to load acquire / store release can wait. I think it's just moving the furniture around for no good reason.
Andrew.
- Previous message: [aarch64-port-dev ] RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire
- Next message: XS review: 8098557: Eager initialization of a super interface with a default method
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]