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 <[email protected]> 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
