* Maurizio Cimadamore: > While this could be done (and it was considered early during the design > phase), we decided against it for two reasons: first, the VarHandle API > is very expressive and already supports. atomic compareAndSwap > operations out of the box, which are _very_ handy when dealing with > shared memory segments. If we had to add all the methods from the > VarHandle API, multiplied by _each_ possible carrier type, the API > footprint would quickly balloon up.
I think some of the atomic operations for VarHandles are currently specified in such a way that they are only implementable within one JVM on certain architectures because some separate lock is needed, or there is no suitable non-writing atomic load. I expect that the foreign-memory access API is also intended for process-shared mappings or read-only mappings, and supporting those scenarios on such architectures will need kernel assists. On the other hand, it doesn't look like any of the current OpenJDK ports suffer from this problem.
