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

[Alan Bateman]

On 26/09/2018 14:27, Andrew Dinn wrote:
> :
> I really don't understand how thread safety comes into the argument
> here. How is some other mechanism going to avoid the need for client
> threads -- or, rather, the applications which create them them -- to
> manage concurrent updates of NVM? Are you perhaps thinking of some form
> of software transactional memory? I'm really struggling to understand
> why you keep raising this point without any further detail to explain
> how the lack of exclusion and synchronization primitives constitutes a
> problem this API that can be bypassed by rolling some equivalent
> alternative into another API.
The reason that we've mentioned it a few times is because it's a 
significant issue. If you have a byte buffer then you can't have 
different threads accessing different parts of the buffer at the same 
time, at least not with any of the relative get/put methods as they 
depend on the buffer position. Sure you can globally synchronize all 
operations but you'll likely want much finer granularity. This bugbear 
comes up periodically, particularly when using buffers for cases that 
they weren't really designed for. Stuart pointed out the lack of 
absolute bulk get/put operations which is something that I think will 
help some of these cases.

>
> Also, can you explain what you mean by confinement? (thread confinement?).
Yes, thread vs. global. I haven't been following Panama close enough to 
say how this is exposed in the API.


>
> Also, I don't think I would label this API an attempt to develop a file
> system. I think that's rather and overblown characterisation of what it
> does.
I think you may have mis-read my mail as was just picking another 
example where MBB would be problematic.


> :
> I'm still not quite sure where this reply leaves the JEP though. Shall I
> update the Risks and Assumptions section to include mention of
> JDK-5029431 as suggested to Stuart? Is there anything else I can do to
> progress things?
>
It wouldn't do any harm to have this section mention that an alternative 
that exposes a more memory centric API may be possible in the future.

-Alan