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

[Andrew Dinn]

Hi Stuart,

On 28/09/18 06:51, Stuart Marks wrote:
> Let me first stay that this issue of "ByteBuffer might not be the right
> answer" is something of a digression from the JEP discussion. I think
> the JEP should proceed forward using MBB with the API that you and Alan
> had discussed previously. At most, the discussion of the "right thing"
> issue might affect a side note in the JEP text about possible
> limitations and future directions of this effort. However, it's not a
> blocker to the JEP making progress as far as I'm concerned.

Thanks for clarifying that point. I have already added a note to that
effect to the JEP. I take your other point that these limitations make
this JEP a less useful addition than it could be. However, it's hard to
see what else might usefully be provided that does not involve a
reworking of JDK core-lib (and, potentially, JVM) functionality that has
a much larger scope than is needed to crack the specific nut the JEP
addresses.

> With that in mind, I'll discuss the issue of multithreaded access to
> ByteBuffers and how this bears on whether buffers are or aren't the
> "right answer." There are actually several issues that figure into the
> "right answer" analysis. In this message, though, I'll just focus on the
> issue of multithreaded access.

Thank you for a very clear and interesting summary of the limitations of
the Buffer API. I have cut it from this reply for the sake of brevity
but I will respond to a few points.

I think the limitations you point out regarding concurrent clients' mode
of operation are less severe in this specific case because there is not
really a need for those client threads to reach a rendezvous point in
order to execute some form of FileChannel update. The buffer content is
persistent memory. So, essentially, the data writes constitute the update.

If independent threads can arrange to coordinate over carving up
separate regions of a persistent mapped buffer for parallel update then
they can also write and flush (by which I mean force cache writeback
for) those regions independently.

Clearly there will also be a need for threads to write common index
regions of the persistent mapped buffer in order to ensure that the
associated data updates are committed. That means the writes and flushes
for those common regions need to synchronize. However, that is simply
business as usual for persistent data management code. A TX manager will
already have code in place for this purpose, for example. Certainly,
that synchronized update will not need to rely on buffer cursor
(position) management.

Also, I am not sure I see any problem arising from your point about
absolute puts (and gets) depending on the 'limit' property. The various
put operations do indeed /read/ the current limit but they do not update
it. So, you are right to state that a persistent store management
library built over this API would need to ensure that put operations
were reined in via some form of rendezvous if it ever wanted to adjust
the limit. However, I don't think that is going to happen with a librray
that manages a mapped persistent store. I would expect that any such
code is never going to call clear(), flip(), truncate() -- nor make a
direct call to limit() --  except as part of the initialization or
reconciliation performed at startup before concurrent clients are unleashed.

Anyway, thank you for a clear warning as to the precise perils faced in
implementing correct client libraries over the base layer this JEP proposes.

> If we were designing an API to support multi-threaded access to memory
> regions, it would almost certainly look nothing like the buffer API.
> This is what Alan means by "buffers might not be the right answer." As
> things stand, it appears quite difficult to me to fix the multi-threaded
> access problem without turning buffers into something they aren't, or
> fragmenting the API in some complex and uncomfortable way.

Agreed.

> Finally, note that this is not an argument against adding bulk absolute
> operations! I think we should probably go ahead and do that anyway. But
> let's not fool ourselves into thinking that bulk absolute operations
> solve the multi-threaded buffer access problem.
Also agreed.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander