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
