RFR: 8275874: [JVMCI] use volatile accessors for aligned reads in c2v_readFieldValue

Doug Simon dnsimon at openjdk.java.net
Tue Oct 26 09:17:12 UTC 2021


On Tue, 26 Oct 2021 08:44:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> we should not silently downgrade it to non-aligned non-volatile access

I'm not so sure. The [javadoc for `Unsafe.getLongUnaligned`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#L3500) includes:


     * <p> The read will be atomic with respect to the largest power
     * of two that divides the GCD of the offset and the storage size.
     * For example, getLongUnaligned will make atomic reads of 2-, 4-,
     * or 8-byte storage units if the offset is zero mod 2, 4, or 8,
     * respectively.  There are no other guarantees of atomicity.


This implies there's no way someone can ask (in Java) for an unaligned volatile access.

How about I clarify the javadoc for the `CompilerToVM.readFieldValue` methods as follows:

diff --git a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
index 032d21ca235..06c78b37fd8 100644
--- a/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
+++ b/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
@@ -783,15 +783,23 @@ final class CompilerToVM {

     /**
      * Reads the current value of a static field. If {@code expectedType} is non-null, then the
-     * object is exptected to be a subtype of {@code expectedType} and extra sanity checking is
+     * object is expected to be a subtype of {@code expectedType} and extra sanity checking is
      * performed on the offset and kind of the read being performed.
+     *
+     * The read is performed with volatile load semantics if is aligned (i.e.,
+     * {@code offset % kind.getByteCount()) == 0}). For unaligned reads, non-volatile semantics are
+     * used.
      */
     native JavaConstant readFieldValue(HotSpotResolvedObjectTypeImpl object, HotSpotResolvedObjectTypeImpl expectedType, long offset, JavaKind kind);

     /**
      * Reads the current value of an instance field. If {@code expectedType} is non-null, then the
-     * object is exptected to be a subtype of {@code expectedType} and extra sanity checking is
+     * object is expected to be a subtype of {@code expectedType} and extra sanity checking is
      * performed on the offset and kind of the read being performed.
+     *
+     * The read is performed with volatile load semantics if is aligned (i.e.,
+     * {@code offset % kind.getByteCount()) == 0}). For unaligned reads, non-volatile semantics are
+     * used.
      */
     native JavaConstant readFieldValue(HotSpotObjectConstantImpl object, HotSpotResolvedObjectTypeImpl expectedType, long offset, JavaKind kind);

-------------

PR: https://git.openjdk.java.net/jdk/pull/6109


More information about the hotspot-compiler-dev mailing list