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

[Aleksey Shipilev]

On Mon, 25 Oct 2021 14:33:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> [JDK-8275645](https://bugs.openjdk.java.net/browse/JDK-8275645) resulted in loosing single-copy atomicity for reads in `c2v_readFieldValue`. This PR fixes that by using `<type>_field_acquire` accessors for all aligned reads and only using `<type>_field` accessors for unaligned reads.

> > 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: [...] This implies there's no way someone can ask (in Java) for an unaligned volatile access.

No, I don't think it does imply so. Note that `getLongUnaligned` is the addition for `getLong`, not `getLongVolatile`. "volatility" is not something optional, it is explicit, this is why there are `getLong` and `getLongVolatile`. The `getLong`/`getLongUnaligned` access is already non-volatile, and so it can be non-aligned. The job for `getLongUnaligned` is to then figure out if hardware can withstand the coarse unaligned load, or, if not, split it in the individual non-atomic accesses. The `getLongVolatile` is volatile, full stop. If it is called on unaligned offset, receiving `SIGBUS` or other kind of error is the expected behavior.

In other words, if caller _asks for volatile access_, it should either get the volatile (atomic) access, or get the error if such access is not possible, or do some sort of atomic recovery (probably involves heavy locking, so this is seldom an option).  The access handling code _should not be allowed_ to decay bad volatile loads into "good" non-volatile loads to avoid the reasonable hardware exception. Instead, it should explicitly fail on bad accesses, thus communicating to the caller that the requested "volatility" property cannot be satisfied for non-aligned accesses.

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

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