The specification of the permitted access modes on memory segment var handles states that a memory access operation can be either:

* Fully aligned, when access is aligned with both the size of the accessed element and the layout constraint. (e.g. JAVA_INT)
* Partially aligned, when access is aligned with layout constraint, but not with size of accessed element. (e.g. JAVA_INT_UNALIGNED)
* Unaligned, if access does not respect alignment constraints.

The alignment kind of an access operation determines which access modes will be available on the resulting var handle.

While this classification is morally correct, it mixes together some use-site and decl-site aspects. For instance, the set of supported access modes should be determined at var handle construction, and not left to whether a memory access "happens to be aligned" given the physical address at which memory dereference occurs.

This also results in an important mismatch with the way memory segment var handle are specified and implemented: if an access mode is not supported, then using such access mode should result in an UnsupportedOperationException. But in our implementation, all alignment issues result in IllegalArgumentException.

This means that clients can get the same exception if:

* they try to read a 4-byte aligned int at a physical address that is not multiple of 4 (use-site error, IAE is good)
* they try to do a compareAndSwap on a var handle obtained using an unaligned int layout (decl-site error, IAE is not good, and UOE should be used instead).