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

Peter Levart peter.levart at gmail.com
Thu Sep 27 10:28:21 UTC 2018


Hi Andrew,

On 09/27/2018 11:23 AM, Andrew Dinn wrote:
> On 26/09/18 17:00, Alan Bateman wrote:
>> 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.
> Ok, I see that there is an issue here where only byte puts at absolute
> positions can be performed concurrently (assuming threads know how to
> avoid overlapping writes) while, by contrast, cursor-based byte[] stores
> require synchronization. Is that the problem in full? Or is there still
> more that I have missed?
>
> I certainly agree that a retro-fit to ByteBuffer which provided for
> byte[] puts at absolute positions would be of benefit for this proposal.
> However, such a retro-fix would be equally as useful for volatile memory
> buffers. I am not clear why this omission suggests to you that we should
> look at a new, alternative model for managing this particular type of
> mapped memory rather than just fixing the current one properly for all
> buffers.

May I just note that multithreaded bulk operations are kind of possible 
without external synchronization (i.e. locks) if you follow a simple 
protocol:

- never use relative operations on the shared ByteBuffer instance
- never use operations that change internal 
mark/position/limit/byteOrder on the shared ByteBuffer instance
- a concurrent bulk operation on 'bb' consists of:

ByteBuffer myBb = bb.slice(0, bb.capacity());
// use myBb to perform concurrent bulk operation (any operations are 
allowed) and then throw it away or cache it in ThreadLocal

If you combine this with explicit fences and/or atomic 16, 32 and 64 bit 
operations via VarHandles. (see 
MethodHandles.byteBufferViewVarHandle(Class, ByteOrder)), concurrent 
programming with ByteBuffer(s) is entirely possible.

Regards, Peter

>
>>> 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.
> Well, my vague stab was obviously in the right ballpark but I'm afraid I
> still don't know what baseball is. Could you explain what you mean by
> confinement?
>
>>> 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.
> Apologies for my very evident confusion here. I'd be very grateful if
> you could talk down a notch or two and/or amplify a bit more to help the
> hard of thinking.
>
>>> 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.
> Ok, I'll certainly add that.
>
> 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



More information about the core-libs-dev mailing list