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

[Gil Tene]

> On Nov 19, 2019, at 9:32 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
> 
> 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?

You will find me arguing both sides of this one.

E.g. I'm all for bringing features back to 8 and 11 that do not change anything
in the Java SE parts (e.g. backporting JFR to 8, continuing to improve GC,
CDS, JITs, etc. in existing LTSs).

But touching what Java SE 11 is *and* what it isn't is IMO still a "sacred" thing.
It's not that this is *never* done. But when it is done, we should be willing
to go to the JCP and rev a platform JSR, and get that rev approved.
E.g. https://jcp.org/en/jsr/detail?id=337 <https://jcp.org/en/jsr/detail?id=337> has done this twice is the past 5 years.


> 
> 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