On 25/11/2019 20:04, David Lloyd wrote:
On Mon, Nov 25, 2019 at 11:28 AM <mark.reinh...@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
