JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Dohrmann, Steve]

Hi Paul, 

I have to apologize.  Due to an email error on my part, I just now saw your and Mark's responses (from 4/8/16). 

> On Apr 8, 2016, at 1:41 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Steve,
> 
>> On 8 Apr 2016, at 00:03, Dohrmann, Steve <steve.dohrmann at intel.com> wrote:
>> 
>> Hi Paul,
>> 
>> We would like to have an an API for Intel's 3D XPoint memory sooner than the JDK 10 timeframe and proposed this API because it seems simple enough to consider for JDK 9.  As you suggest, we will participate in the Panama discussions  in this area.  Any additional guidance you have would be appreciated.
>> 
> 
> e.g. clone/build the panama forest, join the pamana-dev email list, and start asking questions :-) I can send you links etc. off-line if need be.
> 
> 
>> Just to clarify, it is incidental that the proposed Memory interface has only one method.  We see the value of the interface as nominative; a new type that can be passed around to abstract various sources of ByteBuffer memory.
>> 
> 
> I suspected as much, but would prefer that we gain more experience on what this interface should be, and how it intersects with other efforts, rather than introducing a skeletal version now.

The feedback is appreciated.  

> 
> I suppose it’s possible for such an interface to extend from IntFunction for compatibility if existing 8 or 9 dependent libraries use IntFunction for abstracting buffer allocation.

I realize the memory interface we proposed is functional but can you describe where you are thinking the IntFunction<ByteBuffer> type might be used to abstract allocation?

> 
> FWIW at one point i did postulate and prototyped a MemoryRegion class but after some thought and feedback made a hasty retreat :-)
> 

We did see MemoryRegion prototype code posted by Mikael on 4/22 and have been looking at that.

> 
>> Regarding construction and allocation, our current Memory implementation allocates ByteBuffers by calling the NewDirectByteBuffer JNI function with a pointer to 3D XPoint memory allocated via a supporting native library.
> 
> Ok, that’s what we thought when some of us had an off-line discussion about this. It slots in quite nicely, and can be easily abstracted by IntFunction<ByteBuffer> i.e. i don’t think there is anything fundamentally stopping you providing something that would work on Java 8 or 9.
> 
> 
> Is there any documentation on the memory ordering properties of 3D XPoint memory? how would it differ from say normal memory? can one access the memory using AVX instructions? does it support unaligned loads/stores? (i am guessing the latter is yes).
> 

AVX use and alignment choices are the same as for DRAM.  When accessed as volatile memory, as with our ByteBuffer proposal, 3D XPoint memory has the same ordering, visibility, and atomicity behavior as DRAM.  Things can be a little more complicated for the programmer when persistence is used because visibility by other threads can precede persistence.  

We are working now on prototypes for Java use of persistent 3D XPoint memory and hope to contribute what we learn to Panama discussions on extended memory.    

> (Separately there is also the question of whether this kind of memory is something HotSpot itself could leverage.)
> 
> 
>> The Linux libraries we have worked with are NVML (https://github.com/pmem/nvml/) and memkind (https://github.com/memkind/memkind).  We recently also became aware of the NVM-Direct library (https://github.com/oracle/NVM-Direct).
> 
> So do you create JNI bindings to NVML?
> 
> Opportunistically perhaps this is also somewhere Panama might be able to help with, since it will provide good improvements over the current JNI experience.
> 

Yes we have (partial) JNI bindings to both the NVML libvmem library and the memkind library.  The access improvements you mention would be very welcome.

Steve

> Paul.
> 
>> We currently don't need our own subclass and return the ByteBuffer returned by the JNI call.
>> 
>> Thanks,
>> Steve
>>