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

[Gil Tene]

IMO at least some of the the API changes below involve spec-breaking
changes to Java SE 11. Such changes only belong in new versions of
Java SE that can actually include them in their specification.

As a rule, any in-version changes to the public Java SE APIs, including
the addition of new methods, are a “don’t do this” sort of thing. In the
extremely rare cases where they are necessary (e.g. security driven)
a rev to the spec (and often to the TCKs) is required.

If the need is critical enough, we can look at providing alternative
means for doing these things in 11 via new APIs outside of the name
spaces controlled by the java SE specification, e.g. create a new org.nvmmaps.MappedByteBuffer, add intrinsic support for it
In OpenJDK 11, and make sure (via reflection or MethodHandles)
thst it uses the new features in 14+ when they show up. But that is
A bigger undertaking.

I think this is a case where people will just have to wait for a java
version that includes them to be released; 14 for those willing to
keep up, or later for those that are looking for longer term continuity.

— Gil.

> On Nov 19, 2019, at 2:24 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> 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