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

[Doerr, Martin]

Hi Gil,

thanks for pointing this out.

In addition to that API backports are problematic in general, backporting from a JDK version which is under development is an even more problematic.
We would backport an API from a not yet finalized JDK version into a productive LTS release.

Isn't it acceptable that users who want to use this brand new feature use it with the latest feature release once it is stabilized?

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Gil Tene
> Sent: Dienstag, 19. November 2019 16:52
> To: Andrew Dinn <adinn at redhat.com>
> Cc: Jonathan Halliday <jonathan.halliday at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: RFD: JDK-8221477, JDK-8221397, JDK-8221696, JDK-8224974
> 
> 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