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

[Stuart Marks]

On 9/28/18 2:16 AM, Andrew Dinn wrote:
> 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.

I'm not sure I'd put it quite that way, "less useful than it could be."

I guess it depends on what you think the JEP is about. If the JEP is about MBB, 
and MBB is at some point superseded by something else, then yes, I suppose that 
means this JEP is less useful than it might be.

On the other hand, suppose that this JEP is primarily about NVM, including 
access, operations, API, architecture, life cycle issues, etc., and these happen 
to be surfaced through MBB today. If something supersedes MBB, then the concepts 
developed by this JEP can be retargeted to that other thing at the appropriate 
time. Or are the concepts developed by this JEP so closely intertwined with MBB 
that this idea of "retargeting" doesn't make sense? I don't know.

> 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.

Great, I'm glad this helped. I'm never quite sure whether writing these big 
essays is helpful.

(Note also that there are OTHER limitations of the buffer API that I didn't 
cover, since the message was getting too long as it was. Example: 2GB limit.)

> 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.

Sure. It may be that the use cases for NVM aren't particularly affected by 
limitations of the Buffer APIs. If so, so much the better! But there are other 
systems where the limitations imposed by buffers are so onerous that they've had 
to go directly to Unsafe.

> 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.

Yes, this is essentially it. When you run into a problem -- as every project 
does -- think about whether it's inherent to NVM, or whether it's incidental to 
NVM and is rooted in the use of Buffers.

s'marks