JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[David M. Lloyd]

Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240 
(atomics for buffers) or 
https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency 
properties of buffers), how meaningful is this?

On 03/31/2016 07:06 PM, Hans Boehm wrote:
> The expectation would be that such memory would still be mapped with the
> same caching behavior as normal memory, e.g. writeback-cacheable, so that
> it would follow normal Java memory model rules when accessed as normal
> memory?  AFAICT, mapping any kind of memory with different caching behavior
> is likely to be highly problematic on most architectures.
>
> Hans
>
> On Thu, Mar 31, 2016 at 4:19 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>
>> On 03/31/2016 05:14 PM, Dohrmann, Steve wrote:
>>
>>> This is a JDK 9 proposal to support allocation of direct
>>> java.nio.ByteBuffer
>>> instances backed by memory other than off-heap RAM.
>>>
>>
>> I like it. Various kinds of heterogeneous memories are becoming more
>> common, and this seems like the simplest accommodation that at least
>> gets ByteBuffer functionality.
>>
>> With such a simple API, it is hard to imagine fundamental problems
>> fitting to other heterogeneous systems, but it would still be great
>> if anyone dealing with non-Intel systems (TI/KeyStone?) could
>> sanity-check this.
>>
>> I suspect some people would prefer a more elaborate SPI scheme,
>> but this seems fine to me:
>>
>>
>> package java.nio;
>>>
>>> interface Memory { public ByteBuffer allocateByteBuffer(int size); }
>>>
>>> Developers would obtain instances of these Memory objects by calling
>>> public
>>> constructors on specific memory classes.  We propose having developers
>>> call
>>> constructors directly because it is a simple way to accommodate varying
>>> initialization requirements (e.g. partitioning) that specific memory
>>> instances may have.
>>>
>>> For uniformity, we propose mirroring the existing off-heap
>>> java.nio.ByteBuffer allocation through an off-heap RAM class that
>>> implements
>>> the Memory interface:
>>>
>>> package java.nio;
>>>
>>> public class OffHeapRAM implements Memory { @Override public ByteBuffer
>>> allocateByteBuffer(int size) { return ByteBuffer.allocateDirect(size); } }
>>>
>>> Uniform access could be extended to on-heap ByteBuffers with a class that
>>> wraps the non-direct allocation method in ByteBuffer:
>>>
>>> package java.nio;
>>>
>>> public class HeapRAM implements Memory { @Override public ByteBuffer
>>> allocateByteBuffer(int size) { return ByteBuffer.allocate(size); } }
>>>
>>> The 3 additions above are the only changes proposed.  Links to a bug
>>> report
>>> and to a JDK 9 patch containing these additions are shown below.  For
>>> sample
>>> code, we are also creating a class that implements the Memory interface
>>> for
>>> java.nio.ByteBuffers backed by Intel's 3D XPoint memory.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153111
>>>
>>> patch: http://cr.openjdk.java.net/~vdeshpande/8153111/webrev.00/
>>>
>>> While other useful capabilities in this space (e.g. persistent memory,
>>> process-shared memory) are being explored, they are specifically not
>>> addressed or proposed here.  We believe that supporting
>>> java.nio.ByteBuffer
>>> allocation on other memory spaces is sufficiently useful to propose it now
>>> for JDK 9.
>>>
>>> Please let us know if there is interest in this proposal and if you would
>>> like to sponsor a patch.
>>>
>>> Best regards, Steve Dohrmann
>>>
>>>
>>>
>>

-- 
- DML