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.
