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
