Hello,
I like the proposal. I wonder if minimal support for requesting “keyed” memory
locations should already be present. The absolute minimum here would be a long
(representing any key scheme but of course most natural would be a slot counter
or base address)
Memory { ByteBuffer allocate(int size); ByteBuffer request(long slot, int
size);}
(by Definition each request will produce independent ByteBuffer instances but
sharing the backing)
This would work for shared memory segments and persistent ram.
There might be a need to interrogate the buffers (to get base address or slot
number when allocate was used). So it might be a good idea to introduce generic
signatures:
interface <T ext ByteBuffer> Memory {
T allocate(int size);
T request(long slot, int size);
}
ShmMemory implements Memory<ShmByteBuffer> { ... }
ShmByteBuffer b = new ShmMemory().allocate(1*MB);
I have the feeling the concept is only a bit more complex but covers much more
cases with less wild casting and non standard factories.
I like the Memory name, an alternative would be BufferSupplier (with the idea
it could also be used for logical buffer pools).
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Dohrmann, Steve
Gesendet: Donnerstag, 31. März 2016 23:25
An: core-libs-dev@openjdk.java.net
Cc: Fan, Lei t; Deshpande, Vivek R; Kaczmarek, Eric
Betreff: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory
This is a JDK 9 proposal to support allocation of direct java.nio.ByteBuffer
instances backed by memory other than off-heap RAM.
The current allocateDirect() static method in java.nio.ByteBuffer is being used
by some applications to meet special memory needs -- in particular, allocating
large amounts of memory without contributing significantly to GC pause times.
Other kinds of memory could offer advantages to such applications. For
example, Intel's 3D XPoint memory offers large memory capacities that are more
affordable than RAM and speeds that are much faster than NAND storage.
Currently, there is no well-defined interface that can be used to offer a Java
developer access to these other kinds of memory.
Specifically, we propose adding a common memory interface that can be
implemented by an open-ended set of memory classes. The interface would
provide one method that allocates a java.nio.ByteBuffer on the memory
associated with the specific memory instance.
package java.nio;
interface Memory {
public ByteBuffer allocateByteBuffer(int size);
}
These ByteBuffers will have the same behavior as those allocated by the
allocateDirect method in java.nio.ByteBuffer: 1) the ByteBuffer instance is
managed on the Java heap, 2) the buffer's backing memory resides on whatever
space the memory instance represents, and 3) the backing memory is
automatically freed when the ByteBuffer object is garbage collected.
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
