RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Alan Bateman Alan.Bateman at oracle.com
Fri Jan 18 13:32:37 UTC 2019

On 17/01/2019 14:27, Andrew Dinn wrote:
> :
>> Vladimir and I have reviewed the JEP, it will need an area lead to
>> endorse, I think it can be Brian or Mikael in this case.
> Ok, thanks for the above answers. Looking forward to hearing further
> from Brian and/or Mikael (Vidstedt, I assume? :-).
I had a brief discussion with Brian about this yesterday. He brought up 
the same concern about using MBB as it's not the right API for this in 
the longer term.  So this JEP is very much about a short term/tactical 
solution as we've already concluded here. This leads to the question as 
to whether this JEP needs to evolve the standard/Java SE API or not. 
It's convenient for the implementation of course but we should at least 
explore doing this as a JDK-specific feature.

To that end, one approach to explore is allowing the FC.map method 
accept map modes beyond those defined by MapMode. There is precedence 
for extensibility in this area already, e.g. FC.open allows you to 
specify options beyond the standard options specified by the method. It 
would require MapMode to define a protected constructor and would 
require a bit of plumbing to support MapMode defined in a JDK-specific 
module but there are examples to point to. Another approach is aanother 
class in a JDK-specific module to define the map method. It would 
require the same plumbing under the covers but would avoid touch the FC 


More information about the hotspot-compiler-dev mailing list