Minimal Value Types and VarHandles

[Doug Lea]

Even the most minimal versions of Minimal Value Types need
to work with VarHandles. We should check if anything about this
would force adjustments in VarHandle spec that might be possible
before jdk9 ships. Current version of spec is at:
http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html

After walking through the issues, I think specs are (barely) OK
as there are. But further sanity checks would be welcome.

First, there's nothing in the spec that says that VarHandles
for value fields of other objects/arrays must be allowed to be
constructed, but it would be unexpected and hostile not to allow them.

Second, even if VarHandles can be constructed, most (but not all)
methods are allowed to throw UnsupportedOperationException.
This includes all non-Plain mode accesses (setAcquire, getVolatile,
compareAndSet, and so on). But that would also be unexpected and
hostile.

Notice that atomic VarHandle method specs are independent of
whether fields are declared as "volatile". So, the VM does not
necessarily get any advance warning that a value field/element
may be accessed atomically. This was a pragmatically
forced decision because array elements cannot be syntactically
declared as volatile. It is good practice to do so in other cases,
but not enforced. Although because of looseness of VarHandle specs,
it seems legal to throw UnsupportedOperationException if not on
a volatile field (thus, always for array elements). But again, this
would be unexpected and hostile.

If the decision is made to always allow atomic operations (which
seems most desirable), there a few implementation choices, that
might differ across value types, platforms, and JVMs. Options that
appear to be legal wrt the current VarHandle spec include:

1. For small (<= 64bit) types, mapping to existing scalar intrinsics.

2. Wrapping V operations within a possibly-global lock.
Mote that it is not possible in general to use the builtin
"synchronized" monitor lock of the enclosing object, because that could
interfere with other uses, leading to liveness failures. However,
implementations could use other non-global schemes, for example
address-range or hashed locks (almost equivalent to displaced headers).
Of course, locking an entire large array to access one element
would disable parallelism for array processing. One might expect
users to notice this :-)

3. Using transactional memory (on recent x86 and Power), and/or a
partial emulation of it using variants of (2).

It might be possible to further refine such techniques to cover nested
composite values (for example Polygons composed of Lines composed
of Points). Some techniques for doing so for IBM packed objects
were explored in a few papers including
  http://dl.acm.org/citation.cfm?id=2972213
Multi-tier Data Synchronization Based on an Optimized Concurrent
Linked-list. Bing Yang et al, PPPJ 2017).

-Doug