New candidate JEP: 370: Foreign-Memory Access API

[Maurizio Cimadamore]

On 29/11/2019 19:32, Florian Weimer wrote:
> * 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.

I was discussing on a similar note with Paul Sandoz - and we agreed 
that, moving forward - it will be likely for a memory segment to have a 
bunch of flags (probably a characteristics() bit mask), which might 
contain OS/platform related details for when a native segment is 
created; e.g. are write operation supported at all? Is unaligned access 
supported? Does a segment needs writeback?

Right now the API is relatively minimal, but I suspect that if we play 
with it a bit we will discover a bunch of properties like these which 
might sense to make available, and allow clients to query them.

Maurizio

>
> On the other hand, it doesn't look like any of the current OpenJDK
> ports suffer from this problem.