JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Hans Boehm]

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