General, Safe, and Deterministic Foreign Memory Access in JDK 14

In the post "JDK 14 Rampdown: Build 27," I summarized the numerous JDK 14-targeted features newly available with JDK 14 Early Access Build #27. There is already another JDK 14 Early Access Build available and this one [Build 28 (2019/12/18)] includes one particularly interesting feature: Enhancement JDK-8234049 ["Implementation of Memory Access API (Incubator)"]. This is the implementation of JEP 370 ["Foreign-Memory Access API (Incubator)"], which is summarized as, "Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap."

JEP 370 is intended to achieve a "foreign memory API" that provides "generality", "safety", and "determinism" (with each of these means described in further detail in the JEP). The JEP also states that this foreign memory API is intended as an alternative to currently used approaches (java.nio.ByteBuffer and sun.misc.Unsafe). Downsides and limitations of both of these currently available alternates are discussed in the JEP.

The JEP points out that libraries "access foreign memory" to "avoid the cost and unpredictability associated with garbage collection," to "share memory across multiple processes," and to "serialize and deserialize memory content by mapping files into memory." It adds that "the Java API does not provide a satisfactory solution for accessing foreign memory."

JEP 370's "Description" section introduces the implementation of the foreign memory access API. The section begins, "The foreign-memory access API introduces three main abstractions: MemorySegment, MemoryAddress and MemoryLayout." The section then describes these three main abstractions: "A MemorySegment is used to model a contiguous memory region with given spatial and temporal bounds. A MemoryAddress can be thought of as an offset within a segment. Finally, a MemoryLayout is a programmatic description of a memory segment's contents."

After several detailed examples of using the foreign memory access, the JEP's "Description" section states, "The foreign-memory access API will initially be provided as an incubating module, named jdk.incubator.foreign, in a package of the same name."

Additional background details related to JEP 370 are available in OpenJDK mailing list messages. One key thread starts with the message "RFR JDK-8234049: Implementation of Memory Access API (Incubator)." The CSR for this JEP [JDK-8234050: Implementation of Memory Access API (Incubator)] presents alternate useful descriptions. Javadoc-based documentation for the foreign memory access API is also temporarily available at http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html.

The JEP 370 implementation is included in the JDK 14 Early Access Build #28 and available to try.

JDK 14 Rampdown: Build 27

Mark Reinhold's recent post "JDK 14 is now in Rampdown Phase One" announced that "we are now in Rampdown Phase One" and that "the overall feature set is frozen." JDK 14 Early Access Build #27 (2019/12/12) is a hefty build. In this post, I summarize some of the changes associated with JDK 14 Early Access Build 27 that are particularly interesting to me.

One might say that JDK 14 Early Access Build 27 is the "records build." This build is full of updates related to the implementation of the records preview feature (JEP 359). Here are some of the changes associated with this "records build" filled with JEP 359 implementation changes (note that there are already bugs written and fixed for records):

• JEP 359 JDK-8222777: Records (Preview)
• Sub-Task JDK-8227113: Specification for java.lang.Record
• Sub-Task JDK-8225053: Preview APIs support for records
• Sub-Task JDK-8233526: JVM support for records
• Sub-Task JDK-8225054: Compiler implementation for records
• Sub-Task JDK-8225057: Java Language Specification changes for Records
• Sub-Task JDK-8225058: JVM Specification changes for Records
• Sub-Task JDK-8225055: Javadoc for records
• Sub-Task JDK-8225052: javax.lang.model support for records
• Sub-Task JDK-8226314: com.sun.source support for records
• Enhancement JDK-8235359: Simplify method Class.getRecordComponents()
• Bug JDK-8235550: Clarify record reflective support specification
• Bug JDK-8235369: Class.toGenericString need to be updated for records
• Bug JDK-8235446: confusing error message for records with no parens
• Bug JDK-8234101: Compilation error thrown when repeating annotation is used on record component
• Bug JDK-8235474: JShell does not handle records properly

Although JEP 359/Records (Preview) will likely dominate interest of many Java developers in the JDK 14 Early Access Build 27, there are other interesting changes in this build that are summarized here (with links to more details and quotes from the change descriptions):

• Enhancement JDK-8215038: Add a page that lists all system properties
  • "new page that lists all system properties"
  • This new page also shows what accesses each defined system property.
• Enhancement JDK-8235334: Deprecate jcmd GC.class_stats
  • "The output of this jcmd GC.class_stats is lengthy and not well suited to understanding memory used by metaspace objects, nor is it a GC specific facility. It also has some open bugs."
  • Only looks deprecated in JDK 14, but may be removed altogether in JDK 15: "We should deprecate this in 14 and remove in 15."
  • "-Xlog:cds during -Xshare:dump is an example of a better utility that uses a newer better mechanism in the source code."
• Enhancement JDK-8222756: Plural support in CompactNumberFormat
  • Changes to ContactNumberFormat's support for plurals for German and Italian
• Sub-Task JDK-8234542: Remove Pack200 Tools and API
  • Associated with JEP 367 ("Remove the Pack200 Tools and API") [JDK-8232022].
  • Three main motivations listed for removing the Pack200 compression scheme for JAR files:
    1. Download issues historically associated with JDK have been overcome by events and the JDK itself has used compression alternatives instead of Pack200 since JDK 9.
    2. Applets in web browsers (a significant use case for Pack200 compression) are largely unsupported now.
    3. The "complex and elaborate technology" of Pack200 has a "file format is tightly coupled to the class file format and the JAR file format, both of which have evolved in ways unforeseen by JSR 200. ... Overall, the cost of maintaining Pack200 is significant, and outweighs the benefit of including it in Java SE and the JDK."
• Enhancement JDK-8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports
  • Associated with JEP 362 ("Deprecate the Solaris and SPARC Ports") [JDK-8231554]
  • "Deprecate the Solaris/SPARC, Solaris/x64, and Linux/SPARC ports, with the intent to remove them in a future release."
  • Deprecation typically signals the beginning of the end and some will miss these ports when/if they are eventually removed.
• Sub-Task JDK-8233319: Deprecate MulticastSocket methods that operate on java.net.InetAddress
  • Associated CSR JDK-8235330 ("Deprecate MulticastSocket methods that operate on java.net.InetAddress") states that the following methods on class java.net.MulticastSocket are to be deprecated (but not yet removed and superior alternatives are shown for each):
    • getInterface()
      • Favor class's getNetworkInterface() method
    • setInterface(InetAddress inf)
      • Favor class's setNetworkInterface​(NetworkInterface)
    • joinGroup(InetAddress mcastaddr)
      • Favor class's joinGroup​(SocketAddress, NetworkInterface)
    • leaveGroup(InetAddress mcastaddr)
      • Favor class's leaveGroup​(SocketAddress, NetworkInterface)
    • getLoopbackMode()
      • Favor DatagramSocket's (parent class's) method getOption​(SocketOption), passing StandardSocketOptions.html.IP_MULTICAST_LOOP to it
    • setLoopbackMode(boolean disable)
      • Favor DatagramSocket's (parent class's) method setOption​(SocketOption<T> name, T value), passing StandardSocketOptions.html.IP_MULTICAST_LOOP and true to it

In addition to the changes that I called out above, other changes associated with JDK 14 Early Access Build 27 include changes to areas that have changes in many JDK 14 builds (Shenandoah garbage collector, Z garbage collector [ZGC], Java Flight Recorder, and the Java packaging tool).

The JDK 14 Early Access Build 27 Release Notes state that "SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols." The release notes add that "If a client or server still needs to use the SSLv3 protocol they can do so by enabling it via the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs."

I am excited about Records in Java 14 and look forward to playing with them via the OpenJDK 14 Early Access Build 27.