RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Andrew Haley aph at redhat.com
Wed Sep 26 09:53:23 UTC 2018

On 09/26/2018 09:44 AM, Andrew Dinn wrote:
> As regards the latter issue, I am not really sure what you are
> suggesting would be a better alternative to using ByteBuffer get and put
> methods? Are you perhaps thinking of some way of overlaying a record (or
> object?) structure over the mapped memory that might allow a compiler to
> provide an equivalent to these ByteBuffer method calls as direct memory
> loads and stores? Of course, a Java library built on top of this
> proposal could provide a similar abstraction, although perhaps not with
> as firm guarantees for compiler optimization and certainly not with the
> possibility of direct language integration.

Thinking about it some more, I guess that being able to say something

  aFoo.bar = n;

rather than


is preferable, although common Java practice (and indeed good OOP
practice) is to provide getters and setters rather than directly
expose fields. I suppose one advantage of being able to use an object
structure is that the compiler can do better (type-based) alias
analysis, can track dead stores, etc. But from a language design
perspective, the fact that classes internally use direct field
accesses but expose a completely different get/set notation is
something of a linguistic wart.

[ The BETA language used a single notation, the pattern, for
assignment, method calls, and argument passing. Therefore, in BETA
there would be no API difference between the two exaples above. They'd
both be something like

  n -> aFoo.bar

Curiously, the first commercial licences for BETA were acquired by
Bill Joy and James Gosling, so they knew about this, but I suppose a
more C-like notation for Java was the right decision. The BETA
notation would have been too frightening for the target audience. :-) ]

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the core-libs-dev mailing list