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

[Doerr, Martin]

Hi Gil,

my thoughts were only related to specification relevant backports. I think we are on the same page.

Best regards,
Martin


From: Gil Tene <gil at azul.com>
Sent: Mittwoch, 20. November 2019 18:51
To: Doerr, Martin <martin.doerr at sap.com>
Cc: Andrew Dinn <adinn at redhat.com>; 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




On Nov 19, 2019, at 9:32 AM, Doerr, Martin <martin.doerr at sap.com<mailto: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 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<mailto: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<mailto:adinn at redhat.com>>
Cc: Jonathan Halliday <jonathan.halliday at redhat.com<mailto:jonathan.halliday at redhat.com>>; jdk-updates-
dev at openjdk.java.net<mailto: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<mailto: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