JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Chris Vest]

Could “keyd” memory - the request method Bernd proposed - not be given as constructor parameters to the Memory implementation? For instance, an ShmMemory implementation that allocates out of /dev/shm, could take a filename through its constructor, and allocate by mapping that file in /dev/shm. Unfortunately this would make it implementation defined, if the allocate method returns the same memory every time, or new memory. To solve that, I would add a boolean isShared method to the Memory interface, so you can tell programatically if the buffers allocated from a given memory instance can be expected to be private (only accessible through the returned ByteBuffer) or shared (others might look at or modify this memory even if I keep my ByteBuffer secret).

I would also like the allocate method to take a long size, instead of an int. Implementations are free to throw exceptions if clients ask to allocate more memory than is available, or can fit in the given buffer implementation. And with the current ByteBuffer interface, all implementations would have to throw for allocations greater than 2 GiBs, but if that limitation of the ByteBuffer interface were to be removed, then the Memory interface would be ready for it.

Cheers,
Chris

> On 01 Apr 2016, at 06:57, Christoph Engelbert <me at noctarius.com> wrote:
> 
> Hey guys,
> 
> I really like the proposal! I also have the strong feeling it should be proposed with an VarHandles in mind. So far VarHandles can only build views on top of ByteBuffers, which stuck with 32bit indexing. Wouldn’t it make sense to also support 64bit addressing when allocating memory?
> 
> Apart from that I really love Bernd’s comment. Having an option to share memory potions without the need to put another layer on top sounds amazingly useful to me. Also the generic option makes perfect sense (for example if we ever get a 64BitByteBuffer ;-)).
> 
> Chris
> 
>> On 01 Apr 2016, at 04:30, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>> 
>> 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 at 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
>> 
>> 
>