New candidate JEP: 370: Foreign-Memory Access API

[Maurizio Cimadamore]

On 25/11/2019 20:04, David Lloyd wrote:
> On Mon, Nov 25, 2019 at 11:28 AM <mark.reinhold at oracle.com> wrote:
>> https://openjdk.java.net/jeps/370
> Looks pretty interesting!  Why make the API user deal with VarHandles
> though, as opposed to (say) putting accessor methods directly onto
> MemoryAddress?

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. The second motivation is that memory 
access VarHandles are pretty clever things - once you define e.g. a 
layout for a bidimensional matrix like this:

[
[1, 2, 3, 4, 5 ],
[6, 7, 8, 9, 10 ]
]

Then you can get a memory access VarHandle which access the following slice:

[
[1, 3, 5]
[6, 8, 10]
]

(or even obtain the element 'backwards' using a negative step!). Stuff 
like this would be hard to achieve with instance methods on 
MemoryAddress/Segment. In other words, decoupling access from the 
description of a segment allows us to be more expressive in how access 
is achieved, which is, I think, a benefit of the design.

To address basic usability concerns (e.g. I just want to dereference an 
int at a given address), it would be best to provide a bunch of _static_ 
dereference helpers for the common cases, so that users won't have to 
create var handles manually, in all cases. I suspect that, during 
incubation, we will get a better sense of which "usability" shortcuts 
would make more sense to invest into, given some concrete feedback.

Cheers
Maurizio