JDK-8153111 : (bf) Allocating ByteBuffer on heterogeneous memory
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2016-03-30
  • Updated: 2022-08-16
  • Resolved: 2022-08-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14Resolved
Related Reports
Duplicate :  
Description
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.  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.

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.

Comments
See JDK-8207851 JEP 352: Non-Volatile Mapped Byte Buffers
16-08-2022

This issue needs mode detail as to what is being suggested here. Update: the submitter has added text to the issue, it was originally created without any description or text.
01-04-2016

A JDK 9 patch containing the 3 additions described in the bug description. Webrev: http://cr.openjdk.java.net/~vdeshpande/8153111/webrev.00/ Code Cotributed by: Shylaja Kokoori (shylaja.kokoori@intel.com), Lei Fan(Lei.t.fan@intel.com) and Steve Dohrmann(steve.dohrmann@intel.com)
31-03-2016