RFD: JDK-8221477, JDK-8221397, JDK-8221696, JDK-8224974

[Andrew Dinn]

Hi,

I would like to discuss a proposal to backport of the patches listed in
the Subject line to JDK11 and also solicit reviews for my current patch.
Specifically, the patches are:

JDK-8221477: Inject os/cpu-specific constants into Unsafe from JVM
JDK-8221397: Support implementation-defined Map Modes
JDK-8221696: MappedByteBuffer.force method to specify range
JDK-8224974: Implement JEP 352

n.b.they need to be applied in order as listed (as per addition to JDK13/14)

These 4 patches implement support for access to non-volatile RAM
(persistent memory) via a MappedByteBuffer. The full API is currently
only available for use in JDK14+. That means that anyone wishing to use
it now in product software is unable to do so in an LTS release and will
not be able to do so until JDK17 arrives (over 18 months from now).
Given that this is the only efficient means for accessing persistent
memory available from Java at present I am recommending remedying that
situation with a backport to the current LTS release.

Details of Backport:

I have applied the patches to the current jdk11-dev head to obtain the
following webrev:

  http://cr.openjdk.java.net/~adinn/pmem-backport-webrev/webrev.00

For the moment I have presented a combined patch (but I can provide
individual patches if required). The first two patches backported
cleanly with no change. Two small modifications were required to the
patches for JDK-8221696, JDK-8224974. These arose because of the need to
respect the expectations of the TCK regarding the API of class
MappedByteBuffer.

1) The fix for JDK-8221696 overloaded public method force() with a new
public variant force(int, int) which the old method indirects to i.e. it
changed the API of MappedByteBuffer. The revised version includes a
one-line change which makes this a private method. This change allows
the TCK to pass without problem.

2) The above revision leaves an important element of the new API
inaccessible to client code. The force API is needed in order to allow a
client to persist changes written to a pmem backed MappedByteBuffer.

The new fix for JDK-8224974 resolves this omission by adding a new class
called StaticForce to package jdk.nio.mapmode. The new class exposes a
new static API method force(MappedByteBuffer, int, int) which uses a
method handle to indirect the call to the private instance method
MappedByteBuffer.force.

Class MappedByteBuffer co-operates with class StaticForce to enable this
indirect invocation by creating a method handle for this instance method
which is installed in a private staic field forceHandle at class init.
The handle is retrieved by class StaticForce at class init (using Unsafe).

Implications for Client:
Class StaticForce cannot be expected to be available in later JDK
revisions. It is simply a heuristic device to work around the TCK's
strict requirements regarding changes to core APIs. So, clients wishing
to use both the backported functionality on JDK11 and the new
functionality on JDK14+ will need to be aware of the JDK version they
are using and, when on JDK11, invoke the force operation via the static
method of class StaticForce rather than via the instance method of the
MappedByteBuffer.

For libraries that aim to expose the pmem capability to client this
should be a relatively small and localized change that will be easy to
accommodate.

Testing:

The patched jdk11-dev passes the TCK with these changes. It also passes
the JDK tier1 tests and the new tests relevant to NVRAM-backed
MappedByteBuffers. Finally, it has also passed the tests for the library
implemented by Jonathan Halliday of Red Hat that provides a general
purpose client API for managing persistent storage via byte buffers
including making it available for use in Rad Hat's transaction and data
grid software.

n.b. I have not yet added backport requests to the relevant JIRA issues.
I will do so once this patch has been discussed and reviewed.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill