RFR (S): 8033380: Experimental VM flag to enforce access atomicity (original) (raw)

Igor Veresov igor.veresov at oracle.com
Tue Feb 11 04:10:02 PST 2014

• Previous message: RFR (S): 8033380: Experimental VM flag to enforce access atomicity
• Next message: RFR (S): 8033380: Experimental VM flag to enforce access atomicity
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

For C1 you also have to consider the “patching” case.

For correctness you need to at least do something like: diff --git a/src/share/vm/c1/c1_Runtime1.cpp b/src/share/vm/c1/c1_Runtime1.cpp --- a/src/share/vm/c1/c1_Runtime1.cpp +++ b/src/share/vm/c1/c1_Runtime1.cpp @@ -839,11 +839,9 @@ // is the path for patching field offsets. load_klass is only // used for patching references to oops which don't need special // handling in the volatile case.

• deoptimize_for_volatile = result.access_flags().is_volatile();

• patch_field_type = result.field_type();
• deoptimize_for_volatile = result.access_flags().is_volatile() || (AlwaysAtomicAccesses && is_access_not_atomic(patch_field_type));

-#ifndef PRODUCT

• patch_field_type = result.field_type();

-#endif } else if (load_klass_or_mirror_patch_id) { Klass* k = NULL; switch (code) {

Where is_access_not_atomic(type) will have to be defined for each architecture to check if a regular store of a given type is atomic. I guess it’s only T_LONG on 32bit?

But anyway, you’re going to deopt on all long accesses to unknown long fields in C1. If you want to go full speed, then you would need to generate special patchable accesses for longs on 32bit.

igor

On Feb 11, 2014, at 3:02 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

Hi,

I understand we are still closed for integration? Please review this small feature meanwhile: https://bugs.openjdk.java.net/browse/JDK-8033380 http://cr.openjdk.java.net/~shade/8033380/webrev.02/ TL;DR: JMM 9 may need to extend the access atomicity over longs and doubles. Luckily, our logic in emitting the relevant access-atomic instructions is decoupled from memory barriers logic, and so we can "just" unconditionally go through needsatomicaccess where appropriate. Testing: - full cycle JPRT - targeted microbenchmarks on x86/ARM/PPC Thanks, -Aleksey

• Previous message: RFR (S): 8033380: Experimental VM flag to enforce access atomicity
• Next message: RFR (S): 8033380: Experimental VM flag to enforce access atomicity
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the hotspot-compiler-dev mailing list