RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory
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