New candidate JEP: 370: Foreign-Memory Access API

[Florian Weimer]

* 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.