Re: 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  wrote:
> 
> Hi Steve,
> 
>> On 8 Apr 2016, at 00:03, Dohrmann, Steve  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 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 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
>> 

Re: 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  wrote:
> 
> Hi Steve,
> 
>> On 8 Apr 2016, at 00:03, Dohrmann, Steve  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 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 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
>> 

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[mark . reinhold]

2016/4/8 1:41:47 -0700, paul.san...@oracle.com:
> On 8 Apr 2016, at 00:03, Dohrmann, Steve  wrote:
>> 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.

I agree with Paul on this.  It seems premature to introduce some kind of
grand "Memory" abstraction.  Without actual experience with a broad set
of use cases we're almost certain to get it wrong.  If what you want to
do now can be expressed via IntFunction then that seems a
good basis for further experimentation.

- Mark

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Dohrmann, Steve]

Hi Paul,

One point I meant to call out in the last message but did not...

Consistent with current ByteBuffers, we don't foresee public constructors on 
any ByteBuffer implementation classes themselves.  Public constructors are only 
proposed for the class that implements the Memory interface with its ByteBuffer 
factory method.

Thanks,
Steve

On Apr 7, 2016, at 3:03 PM, Dohrmann, Steve 
> 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.

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.

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.  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).  We 
currently don't need our own subclass and return the ByteBuffer returned by the 
JNI call.

Thanks,
Steve

On Apr 6, 2016, at 4:10 AM, Paul Sandoz 
> wrote:

Hi Steve,

My feeling is it’s too premature to introduce a general Memory (region) 
allocation interface at this moment. What is currently specified can be 
supported using:

 IntFunction

But i don’t wanna discourage you! this thread has raised some interesting 
points.

Project Panama is gonna take a swing at defining a more general notion of a 
memory region and the Arrays 2.0 work should support indexes greater than 
Integer.MAX_VALUE.

In this respect I think we should hold off doing anything premature for Java 9 
(feature freeze is getting closer), and i encourage you to participate on the 
Panama lists.


—

Here is some context some of which you probably know and some which you might 
not:

- ByteBuffer constructors are deliberately package scoped, as there are some 
intricate dependencies between the implementations and we want control over who 
can implement. Any new form of allocation will require changes here (package 
scoped or otherwise).

- current ByteBuffer implementations are either backed by a byte[] (managed or 
non-direct) or an off-heap allocated (direct) region. At the moment access to 
both those regions go through separate code paths, but they could be unified 
using the Unsafe double addressing mode, which should greatly simplify the 
implementations. I have started making some small steps towards that 
(JDK-8149469 and JDK-8151163). Even these small steps require careful analysis 
to evaluate performance across multiple platforms.

- VarHandles leverages the Unsafe double addressing mode to support enhanced 
atomic access to heap or direct ByteBuffers [1], thus the same code is used in 
both kinds of buffer.


—

I am not sure what plans you have for buffer implementations themselves.

How do you propose to allocate a ByteBuffer instance that covers a region of 3D 
XPoint memory?

Would it be similar to that of direct buffers, e.g. a variation of 
DirectByteBuffer, but with different factory constructor code to allocate the 
memory region within the XPoint memory system and assign the buffer base 
address to the start of that allocated region?

Thanks,
Paul.

[1] 
http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/java/lang/invoke/MethodHandles-report.html#method:byteBufferViewVarHandle(java.lang.Class,
 boolean)


On 6 Apr 2016, at 03:49, Dohrmann, Steve 
> wrote:

Re: JDK-8153111


Hi,

Below are responses to some of the points brought up in the discussion as well 
as is a little expansion of the reasoning that went into the proposed API.

One motivation we saw for doing anything beyond a concrete ByteBuffer class was 
application code (e.g. Cassandra) that allocates many off-heap ByteBuffers 
using ByteBuffer#allocateDirect.  We reasoned that if the allocation of 
ByteBuffers could be done using a common memory interface then only the code 
that provisioned instances of the the memory spaces would have to change in 
order to switch or mix memory types.

We did think of overloading the ByteBuffer#allocateDirect method with memory 
space info and avoid an allocation interface.  We ended up with a separate user 
called interface scheme because we imagined that extensions of the memory 
interface would enable new 

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Paul Sandoz]

Hi Steve,

> On 8 Apr 2016, at 00:03, Dohrmann, Steve  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.

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.

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


> 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 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).

(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.

Paul.

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

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Dohrmann, Steve]

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.

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.

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.  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).  We 
currently don't need our own subclass and return the ByteBuffer returned by the 
JNI call.

Thanks,
Steve

On Apr 6, 2016, at 4:10 AM, Paul Sandoz 
> wrote:

Hi Steve,

My feeling is it’s too premature to introduce a general Memory (region) 
allocation interface at this moment. What is currently specified can be 
supported using:

 IntFunction

But i don’t wanna discourage you! this thread has raised some interesting 
points.

Project Panama is gonna take a swing at defining a more general notion of a 
memory region and the Arrays 2.0 work should support indexes greater than 
Integer.MAX_VALUE.

In this respect I think we should hold off doing anything premature for Java 9 
(feature freeze is getting closer), and i encourage you to participate on the 
Panama lists.


—

Here is some context some of which you probably know and some which you might 
not:

- ByteBuffer constructors are deliberately package scoped, as there are some 
intricate dependencies between the implementations and we want control over who 
can implement. Any new form of allocation will require changes here (package 
scoped or otherwise).

- current ByteBuffer implementations are either backed by a byte[] (managed or 
non-direct) or an off-heap allocated (direct) region. At the moment access to 
both those regions go through separate code paths, but they could be unified 
using the Unsafe double addressing mode, which should greatly simplify the 
implementations. I have started making some small steps towards that 
(JDK-8149469 and JDK-8151163). Even these small steps require careful analysis 
to evaluate performance across multiple platforms.

- VarHandles leverages the Unsafe double addressing mode to support enhanced 
atomic access to heap or direct ByteBuffers [1], thus the same code is used in 
both kinds of buffer.


—

I am not sure what plans you have for buffer implementations themselves.

How do you propose to allocate a ByteBuffer instance that covers a region of 3D 
XPoint memory?

Would it be similar to that of direct buffers, e.g. a variation of 
DirectByteBuffer, but with different factory constructor code to allocate the 
memory region within the XPoint memory system and assign the buffer base 
address to the start of that allocated region?

Thanks,
Paul.

[1] 
http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/java/lang/invoke/MethodHandles-report.html#method:byteBufferViewVarHandle(java.lang.Class,
 boolean)


On 6 Apr 2016, at 03:49, Dohrmann, Steve 
> wrote:

Re: JDK-8153111


Hi,

Below are responses to some of the points brought up in the discussion as well 
as is a little expansion of the reasoning that went into the proposed API.

One motivation we saw for doing anything beyond a concrete ByteBuffer class was 
application code (e.g. Cassandra) that allocates many off-heap ByteBuffers 
using ByteBuffer#allocateDirect.  We reasoned that if the allocation of 
ByteBuffers could be done using a common memory interface then only the code 
that provisioned instances of the the memory spaces would have to change in 
order to switch or mix memory types.

We did think of overloading the ByteBuffer#allocateDirect method with memory 
space info and avoid an allocation interface.  We ended up with a separate user 
called interface scheme because we imagined that extensions of the memory 
interface would enable new memory functionality that required new methods (e.g. 
memory transactions for persistence).  Without a separate callable interface, 
the static method space in ByteBuffer might have to change again.

For any API In general we saw the need for two things 1) something to represent 
a memory space from which objects are allocated (a Memory instance) and 2) a 
broadly usable familiar "anchor" type as the common data object 
(java.nio.ByteBuffer).

The two points 

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Paul Sandoz]

Hi Steve,

My feeling is it’s too premature to introduce a general Memory (region) 
allocation interface at this moment. What is currently specified can be 
supported using:

  IntFunction

But i don’t wanna discourage you! this thread has raised some interesting 
points.

Project Panama is gonna take a swing at defining a more general notion of a 
memory region and the Arrays 2.0 work should support indexes greater than 
Integer.MAX_VALUE.

In this respect I think we should hold off doing anything premature for Java 9 
(feature freeze is getting closer), and i encourage you to participate on the 
Panama lists.


—

Here is some context some of which you probably know and some which you might 
not:

- ByteBuffer constructors are deliberately package scoped, as there are some 
intricate dependencies between the implementations and we want control over who 
can implement. Any new form of allocation will require changes here (package 
scoped or otherwise).

- current ByteBuffer implementations are either backed by a byte[] (managed or 
non-direct) or an off-heap allocated (direct) region. At the moment access to 
both those regions go through separate code paths, but they could be unified 
using the Unsafe double addressing mode, which should greatly simplify the 
implementations. I have started making some small steps towards that 
(JDK-8149469 and JDK-8151163). Even these small steps require careful analysis 
to evaluate performance across multiple platforms.

- VarHandles leverages the Unsafe double addressing mode to support enhanced 
atomic access to heap or direct ByteBuffers [1], thus the same code is used in 
both kinds of buffer.


—

I am not sure what plans you have for buffer implementations themselves.

How do you propose to allocate a ByteBuffer instance that covers a region of 3D 
XPoint memory?

Would it be similar to that of direct buffers, e.g. a variation of 
DirectByteBuffer, but with different factory constructor code to allocate the 
memory region within the XPoint memory system and assign the buffer base 
address to the start of that allocated region?

Thanks,
Paul.

[1] 
http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/java/lang/invoke/MethodHandles-report.html#method:byteBufferViewVarHandle(java.lang.Class,
 boolean)


> On 6 Apr 2016, at 03:49, Dohrmann, Steve  wrote:
> 
> Re: JDK-8153111
> 
> 
> Hi,
> 
> Below are responses to some of the points brought up in the discussion as 
> well as is a little expansion of the reasoning that went into the proposed 
> API.
> 
> One motivation we saw for doing anything beyond a concrete ByteBuffer class 
> was application code (e.g. Cassandra) that allocates many off-heap 
> ByteBuffers using ByteBuffer#allocateDirect.  We reasoned that if the 
> allocation of ByteBuffers could be done using a common memory interface then 
> only the code that provisioned instances of the the memory spaces would have 
> to change in order to switch or mix memory types.
> 
> We did think of overloading the ByteBuffer#allocateDirect method with memory 
> space info and avoid an allocation interface.  We ended up with a separate 
> user called interface scheme because we imagined that extensions of the 
> memory interface would enable new memory functionality that required new 
> methods (e.g. memory transactions for persistence).  Without a separate 
> callable interface, the static method space in ByteBuffer might have to 
> change again.
> 
> For any API In general we saw the need for two things 1) something to 
> represent a memory space from which objects are allocated (a Memory instance) 
> and 2) a broadly usable familiar "anchor" type as the common data object 
> (java.nio.ByteBuffer).
> 
> The two points for extension with the current proposal are: 1) Constructors 
> on Memory implementation classes -- allow implementors the ability to offer 
> features on the memory space itself (e.g. partitioning, size limits) and 2) 
> future extensions on the Memory interface -- for example PersistentMemory.
> 
> Regarding a more elaborate scheme for memory space creation -- we did 
> consider a factory scheme for memory object allocation but could not get 
> comfortable with either a) standardized method signatures suitable for 
> various kinds of memory or b) the complexity that something like a 
> general-purpose "spec" format would add, even if we could come up with it.  
> Direct construction does expose more to the user but it seems sufficient and 
> might be the best given what we can say about the future of heterogeneous 
> memory at this point.
> 
> Regarding the suggested addition of keyed access to ByteBuffers, we are 
> assuming this is only proposed to enable sharing?  We thought it might take a 
> while to properly explore the details (i.e. semantics / thread safety / 
> predicable performance) of sharing such that it would work well and maybe 
> even extend well to 

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Bernd Eckenfels]

Hello Steve,

Thank you for addressing all concerns raised in the discussion.

For my points:

Using BufferSupplier or similar as the interface name can be mixed with 
class/constructor names which describe the actual type of memory. However yes I 
agree that “Memory” has the additional benefit that it can be used directly as 
a postfix in the class name, so thinking more about it, I agree with the nice 
and concrete “Memory” name.

I shortened the method to “allocate()”,  but you are right it might be better 
to make it a bit more specific if extensions are to be expected.

My main motivation behind a long key was, that in most scenarios which come to 
my mind (NVRAM, Flash, mmaped, shmem) the position of the allocated segment is 
relevant for cross VM (concurrent or sequential, as in the persisted case)  
sharing. As a ByteBuffer is not only a window into those memory segments but 
also a active datastructure (pos) it would be ugly to request only a single 
buffer to cover a large region. Especially with a 32bit size limit.

But yes it might also be possible to setup the position/sharing details with 
the Memory constructor request a large ByteBuffer and then split the actual 
buffers mapped on top of it (and do the allocation management based on start 
positions by hand)

The meaning of size in combination with the allocation key would be provider 
dependent. One option would be to refuse overlapping allocations but a more 
common implementation would simply allocate the segments (and if two VMs use 
overlapping regions they will exactly receive them). In all cases it should 
describe the capacity of the buffer.

Greetings
bernd
-- 
http://bernd.eckenfels.net

Von: Dohrmann, Steve
Gesendet: Mittwoch, 6. April 2016 03:59
An: core-libs-dev@openjdk.java.net
Betreff: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Re: JDK-8153111<https://bugs.openjdk.java.net/browse/JDK-8153111>


Hi,

Below are responses to some of the points brought up in the discussion as well 
as is a little expansion of the reasoning that went into the proposed API.

One motivation we saw for doing anything beyond a concrete ByteBuffer class was 
application code (e.g. Cassandra) that allocates many off-heap ByteBuffers 
using ByteBuffer#allocateDirect.  We reasoned that if the allocation of 
ByteBuffers could be done using a common memory interface then only the code 
that provisioned instances of the the memory spaces would have to change in 
order to switch or mix memory types.

We did think of overloading the ByteBuffer#allocateDirect method with memory 
space info and avoid an allocation interface.  We ended up with a separate user 
called interface scheme because we imagined that extensions of the memory 
interface would enable new memory functionality that required new methods (e.g. 
memory transactions for persistence).  Without a separate callable interface, 
the static method space in ByteBuffer might have to change again.

For any API In general we saw the need for two things 1) something to represent 
a memory space from which objects are allocated (a Memory instance) and 2) a 
broadly usable familiar "anchor" type as the common data object 
(java.nio.ByteBuffer).

The two points for extension with the current proposal are: 1) Constructors on 
Memory implementation classes -- allow implementors the ability to offer 
features on the memory space itself (e.g. partitioning, size limits) and 2) 
future extensions on the Memory interface -- for example PersistentMemory.

Regarding a more elaborate scheme for memory space creation -- we did consider 
a factory scheme for memory object allocation but could not get comfortable 
with either a) standardized method signatures suitable for various kinds of 
memory or b) the complexity that something like a general-purpose "spec" format 
would add, even if we could come up with it.  Direct construction does expose 
more to the user but it seems sufficient and might be the best given what we 
can say about the future of heterogeneous memory at this point.

Regarding the suggested addition of keyed access to ByteBuffers, we are 
assuming this is only proposed to enable sharing?  We thought it might take a 
while to properly explore the details (i.e. semantics / thread safety / 
predicable performance) of sharing such that it would work well and maybe even 
extend well to things like process-shared and cluster-shared ByteBuffers.  We 
elected to propose nothing for JDK 9 beyond what developers can already do with 
schemes based on e.g. ByteBuffer#duplicate.  We were thinking shared buffers 
could appear later, possibly as an extension of the Memory interface.   The 
keyed access scheme is simple and appealing, however.  One question: how is the 
request method's size parameter to be interpreted?

The suggestion of parameterizing the Memory interface bounded by ByteBuffers 
seems useful as it gives a clean way to support extended ByteBuffers

JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Dohrmann, Steve]

Re: JDK-8153111


Hi,

Below are responses to some of the points brought up in the discussion as well 
as is a little expansion of the reasoning that went into the proposed API.

One motivation we saw for doing anything beyond a concrete ByteBuffer class was 
application code (e.g. Cassandra) that allocates many off-heap ByteBuffers 
using ByteBuffer#allocateDirect.  We reasoned that if the allocation of 
ByteBuffers could be done using a common memory interface then only the code 
that provisioned instances of the the memory spaces would have to change in 
order to switch or mix memory types.

We did think of overloading the ByteBuffer#allocateDirect method with memory 
space info and avoid an allocation interface.  We ended up with a separate user 
called interface scheme because we imagined that extensions of the memory 
interface would enable new memory functionality that required new methods (e.g. 
memory transactions for persistence).  Without a separate callable interface, 
the static method space in ByteBuffer might have to change again.

For any API In general we saw the need for two things 1) something to represent 
a memory space from which objects are allocated (a Memory instance) and 2) a 
broadly usable familiar "anchor" type as the common data object 
(java.nio.ByteBuffer).

The two points for extension with the current proposal are: 1) Constructors on 
Memory implementation classes -- allow implementors the ability to offer 
features on the memory space itself (e.g. partitioning, size limits) and 2) 
future extensions on the Memory interface -- for example PersistentMemory.

Regarding a more elaborate scheme for memory space creation -- we did consider 
a factory scheme for memory object allocation but could not get comfortable 
with either a) standardized method signatures suitable for various kinds of 
memory or b) the complexity that something like a general-purpose "spec" format 
would add, even if we could come up with it.  Direct construction does expose 
more to the user but it seems sufficient and might be the best given what we 
can say about the future of heterogeneous memory at this point.

Regarding the suggested addition of keyed access to ByteBuffers, we are 
assuming this is only proposed to enable sharing?  We thought it might take a 
while to properly explore the details (i.e. semantics / thread safety / 
predicable performance) of sharing such that it would work well and maybe even 
extend well to things like process-shared and cluster-shared ByteBuffers.  We 
elected to propose nothing for JDK 9 beyond what developers can already do with 
schemes based on e.g. ByteBuffer#duplicate.  We were thinking shared buffers 
could appear later, possibly as an extension of the Memory interface.   The 
keyed access scheme is simple and appealing, however.  One question: how is the 
request method's size parameter to be interpreted?

The suggestion of parameterizing the Memory interface bounded by ByteBuffers 
seems useful as it gives a clean way to support extended ByteBuffers.  Not sure 
if the change of the allocation method name from #allocateByteBuffer to 
#allocate was incidental or not?

Alternates to the "Memory" interface name might be preferred, BufferSupplier is 
certainly reasonable.  We imagined instances that name different memory spaces 
(e.g. OffHeapRAM) for allocation rather that the role played -- thinking the 
role is explicit in the allocation method name (allocateByteBuffer).

Regarding changing the allocation size parameter to a long, this would be very 
nice to have.  We avoided it in order to match the existing ByteBuffer API.  If 
64-bit ByteBuffers are planned, sticking with int sizes might have been the 
wrong call.

We are still coming up to speed on VarHandles (JEP 193), atomics for 
ByteBuffers (JDK-8008240), and ByteBuffer consistency (JDK-6476827).

We hope there is continued interest in this proposal and happy to provide a 
modified patch.

Best regards,
Steve Dohrmann

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Dohrmann, Steve]

Hi everyone,

The questions and suggestions regarding this proposal 
(JDK-8153111) are interesting 
and useful.  We are still digesting the feedback; next week we'll do our best 
to respond to items raised and add to the discussion.  I hope this list 
captures the main concerns and suggestions seen so far in the discussion:

1. Why not enhance ByteBuffer allocation methods rather that create a new 
Memory interface
2. Does this proposal buy us anything over exposing special memory as a file 
mappable via the OS?
3. Possibly more elaborate SPI scheme for memory space creation
4. Provide keyed (e.g. long "slot") allocation of ByteBuffers in a memory space
5. Generic interfaces on Memory (alternate name: BufferSupplier) interface 
methods
6. Clearer shared / private ByteBuffer semantics within a memory space
7. 64-bit allocation / addressing in Memory interface, at least as prep for a 
less-restricted ByteBuffer interface
8. Importance of atomics for ByteBuffers 
(JDK-8008240) and ByteBuffer 
consistency (JDK-6476827) in 
the context of this proposal
9. Connection between this proposal and VarHandles

Best regards,
Steve Dohrmann

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Andrew Haley]

On 04/01/2016 06:05 PM, David M. Lloyd wrote:
> 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?

That's on the list of things to get fixed with VarHandles.  It's worth
discussing in this context.  The probelm is that "memory" with odd
semantics may not map well onto the JMM.

Andrew.

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[David M. Lloyd]

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  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

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Andrew Haley]

On 04/01/2016 09:54 AM, Attila Szegedi wrote:

> I can think of several differences. For one, you can’t presume the
> availability of a filesystem (Java doesn’t require that the host
> system give it access to a filesystem), nor the ability of the
> filesystem to expose all desired kinds of memory as files.

OK.  I have no sympathy with operating systems that can't do this, but
that's just MO.  :-)

> Next, every such solution is OS specific and we love having OS
> independent APIs in Java.

I would have thought that by definition memory with odd semantics is
OS-dependent and non-portable.

> An aspect of OS-specific functionality would also be access controls
> to these files, while with a Java API such controls can (if needed)
> be managed by Java security policy (again, in OS independent
> fashion).

Eh?  Any OS has access controls on its files.

> Finally, even if all of this is present in the system, exposing
> memory as files can be a security issue if an external process can
> also gain access to them.

Exposing memory to an external process in any way can be a security
issue.  It doesn't matter if it's a file or not.  This is irrelevant.

Andrew.

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Attila Szegedi]

I can think of several differences. For one, you can’t presume the availability 
of a filesystem (Java doesn’t require that the host system give it access to a 
filesystem), nor the ability of the filesystem to expose all desired kinds of 
memory as files. Next, every such solution is OS specific and we love having OS 
independent APIs in Java. An aspect of OS-specific functionality would also be 
access controls to these files, while with a Java API such controls can (if 
needed) be managed by Java security policy (again, in OS independent fashion). 
Finally, even if all of this is present in the system, exposing memory as files 
can be a security issue if an external process can also gain access to them.

So a simple in-process, OS-independent API is definitely better suited for the 
task.

Just my opinion,
  Attila.

On 01 Apr 2016, at 09:49, Andrew Haley  wrote:
> 
> On 31/03/16 22:14, 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 must be missing something.  How is this different from exposing
> special memory via the filesystem and mapping a file?
> 
> Andrew.
> 

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Andrew Haley]

On 31/03/16 22:14, 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 must be missing something.  How is this different from exposing
special memory via the filesystem and mapping a file?

Andrew.

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Christoph Engelbert]

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 <e...@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  Memory {
>  T allocate(int size);
>  T request(long slot, int size);
> }
> 
> ShmMemory implements Memory { ... }
> 
> 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);
>   }
> }
> 
> T

AW: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Bernd Eckenfels]

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  Memory {
  T allocate(int size);
  T request(long slot, int size);
}

ShmMemory implements Memory { ... }

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

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Hans Boehm]

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  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
>>
>>
>>
>

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Doug Lea]

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

JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Dohrmann, Steve]

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