JDK 14 Early-Access Release Notes

This is a draft of the release notes that will accompany JDK 14. The contents are subject to change until release.

Build 29

Weak named curves disabled by default in TLS, CertPath, and Signed JAR (JDK-8233228)

security-libs/java.security

Weak named curves are disabled by default by their addition to the disabledAlgorithms security properties. Those properties are 'jdk.tls.disabledAlgorithms', 'jdk.certpath.disabledAlgorithms', and 'jdk.jar.disabledAlgorithms'. The curves are listed below.

With 47 weak named curves to be disabled, adding individual named curves to each disabledAlgorithms properties would be overwhelming. To relieve this, a new security property, 'jdk.disabled.namedCurves', is implemented that can list the named curves common to all the disabledAlgorithms properties. To use the new property in the disabledAlgorithms properties, the keyword include precedes the full property name as an entry. Users can still add individual named curves to disabledAlgorithms properties separate from this new property. No other properties can be included in the disabledAlgorithms properties.

To restore the named curves, remove the include jdk.disabled.namedCurves from all or the particular disabledAlgorithms security properties. To restore one or more curves, remove the particular named curve(s) from the jdk.disabled.namedCurves property.

Curves that are disabled via jdk.disabled.namedCurves: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

Build 27

Shenandoah supports JFR Leak Profiler (JDK-8235685)

hotspot/gc

After the recent improvements in runtime, users should now be able to use JFR Leak Profiler with Shenandoah GC. This is only available with JDK 14 onwards.

Deprecate the OracleUcrypto JCE Provider for removal (JDK-8234870)

security-libs/javax.crypto

The OracleUcrypto JCE Provider and its containing module jdk.crypto.ucrypto have been deprecated and are subject to removal in a future version of the JDK. See [JEP 362|https://openjdk.java.net/jeps/362] for more information.

Allow Discoverable javac Plugins to be Invoked by Default (JDK-8234211)

tools/javac

javac "plugins" can now opt-in to be started by default if not started explicitly in the options passed to javac from the command-line or in the options argument of an API invocation. This behavior is enabled by implementing the method Plugin.isDefault() to return true.

Removed SSLv2Hello and SSLv3 from default enabled TLS protocols (JDK-8190492)

security-libs/javax.net.ssl

SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.

After this update, if SSLv3 is removed from the jdk.tls.disabledAlgorithms security property, the SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() and SSLParameters.getProtocols() APIs will return "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.

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.

Plural support in CompactNumberFormat (JDK-8222756)

core-libs/java.text

java.text.CompactNumberFormat is now capable of dealing with plural forms. For example, the number 2,000,000 is formatted to "2 Millionen" in LONG style, whereas 1,000,000 to "1 Million" in German language.

Build 26

MethodHandles::privateLookupIn may not produce a Lookup with full privilege access (JDK-8233527)

core-libs/java.lang.invoke

The Lookup object produced by MethodHandles::privateLookupIn in this release may not have full privilege access. A lookup which possesses both PRIVATE and MODULE access modes is said to possess full privilege access that can be tested with Lookup::hasFullPrivilegeAccess method. Previously a Lookup returned from MethodHandles::privateLookupIn can be used to look up caller-sensitive methods. In Java SE 14, it may fail to look up caller-sensitive methods if the lookup does not have full privilege access (even it has private access mode).

MulticastSocket getOption(IP_MULTICAST_IF) now returns null when interface is not set (JDK-8233307)

core-libs/java.net

The MulticastSocket method getOption has been changed to conform to the behavior described in StandardSocketOptions.IP_MULTICAST_IF. MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_IF) now returns null if no interface has been set.

Added 4 Amazon Root CA Certificates (JDK-8233223)

security-libs/java.security

The following root certificates have been added to the cacerts truststore:

+ Amazon
  + amazonrootca1
    DN: CN=Amazon Root CA 1, O=Amazon, C=US

  + amazonrootca2
    DN: CN=Amazon Root CA 2, O=Amazon, C=US

  + amazonrootca3
    DN: CN=Amazon Root CA 3, O=Amazon, C=US

  + amazonrootca4
    DN: CN=Amazon Root CA 4, O=Amazon, C=US

Build 25

The behavior of MulticastSocket getOption/setOption for IP_MULTICAST_LOOP is changed to conform the specification of StandardSocketOptions.IP_MULTICAST_LOOP (JDK-8233296)

core-libs/java.net

The MulticastSocket methods getOption and setOption are now changed to conform to the behavior described in StandardSocketOptions.IP_MULTICAST_LOOP. MulticastSocket.getOption(StandardSocketOptions.IP_MULTICAST_LOOP) now returns true if loopback mode is enabled, and MulticastSocket.setOption(StandardSocketOptions.IP_MULTICAST_LOOP, true) enables loopback mode.

JEP 366: Deprecate the ParallelScavenge + SerialOld collector combination (JDK-8233301)

hotspot/gc

The ParallelScavenge + SerialOld garbage collector combination has been deprecated. Any use of the UseParallelOldGC command line option which is used to enable this garbage collection algorithm combination will cause a deprecation warning.

The drop-in replacement is to use the ParallelScavenge + ParallelOld garbage collector via -XX:+UseParallelGC on the command line.

For more information please refer to https://openjdk.java.net/jeps/366.

Build 24

DatagramSocket.send and MulticastSocket.send throw IllegalArgumentException when the socket is not connected and the packet doesn't contain any address (JDK-8233141)

core-libs/java.net

The send methods defined by DatagramSocket and MulticastSocket are changed to throw IllegalArgumentException if the socket is not connected and the DatagramPacket doesn't have a socket address. Prior to this change, these methods threw NullPointerException.

Added LuxTrust Global Root 2 Certificate (JDK-8232019)

security-libs/java.security

The following root certificate has been added to the cacerts truststore:

+ LuxTrust
  + luxtrustglobalroot2ca

    DN: CN=LuxTrust Global Root 2, O=LuxTrust S.A., C=LU

Remove the default keytool -keyalg value (JDK-8214024)

security-libs/java.security

The default key algorithm for the keytool -genkeypair and keytool -genseckey commands has been removed. You must now specify the key algorithm with the -keyalg option when using the -genkeypair or -genseckey commands. If the -keyalg option is not specified, keytool will terminate with the error message: "The -keyalg option must be specified".

Build 22

Thread interrupt state is now always available (JDK-8229516)

core-libs/java.lang

The specification for java.lang.Thread::interrupt allows for an implementation to only track the interrupt state for live threads, and previously this is what occurred. As of this release the interrupt state of a Thread is always available and if you interrupt a thread t before it is started, or after it has terminated, the query t.isInterrupted() will return true.

Thread.countStackFrames changed to unconditionally throw UnsupportedOperationException (JDK-8205132)

core-libs/java.lang

The terminally deprecated method Thread.countStackFrames has changed in this release to unconditionally throw UnsupportedOperationException.

This method will be removed in a future release.

Build 21

Upgrade CLDR to v36 (JDK-8231273)

core-libs/java.util:i18n

Locale data based on Unicode Consortium's CLDR has been upgraded to their version 36. For the detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes:

DelegationPermission allows to create an instance that thows NPE on ::equals call (JDK-8231196)

security-libs/javax.security

When a DelegationPermission object is created and the principals argument does not contain a pair of principals, an IllegalArgumentException is now thrown.

Thread suspend/resume are now deprecated for removal (JDK-8231602)

core-libs/java.lang

The following methods related to thread suspension in java.lang.Thread and java.lang.ThreadGroup have been terminally deprecated in this release:

  • Thread.suspend()
  • Thread.resume()
  • ThreadGroup.suspend()
  • ThreadGroup.resume()
  • ThreadGroup.allowThreadSuspension(boolean)

These methods will be removed in a future release.

Build 20

Shenandoah: asynchronous object/region pinning (JDK-8232575)

hotspot/gc

When dealing with JNI Get*Critical methods, Shenandoah employs object/region pinning, instead of using the GCLocker. Until now, the inefficient pinning implementation have caused real-world scalability problems on workloads that use a lot of JNI, for example gzip and graphics. This was improved, and scalability bottleneck should be resolved. This fix was also backported to 8-shenandoah and 11-shenandoah.

Detailed message in NullPointerExceptions (JDK-8218628)

hotspot/runtime

A new option has been added to the JVM to enable more helpful messages when a Java developer encounters a NullPointerException:

 -XX:+ShowCodeDetailsInExceptionMessages
    Enables printing of improved NullPointerException messages. When an application throws a
   `NullPointerException`, the option enables the JVM to analyze the program's bytecode
    instructions to determine precisely which reference is `null`, and describe the source with a null-detail
    message.
    The null-detail message is calculated and returned by `NullPointerException.getMessage()', and will be printed
    as the exception message along with the method, filename, and line number.
    By default, this option is disabled.

InetSocketAddress.toString format changes for IPv6 literals and unresolved addresses (JDK-8225499)

core-libs/java.net

The method InetSocketAddress::toString has been improved regarding the handling of IPv6 addresses. The implementation now encloses the IPv6 literal in brackets, which adheres to the specification outlined in RFC2732.

Additionally, the string format for unresolved addresses has been changed. The method now represents the IP literal with the token <unresolved>, for example: foo/<unresolved>:80 instead of foo:80.

Build 19

Epsilon warns about Xms/Xmx/AlwaysPreTouch configuration (JDK-8232051)

hotspot/gc

Many Epsilon GC users expect low latency, but may not be aware that additional configuration is needed for GCs to perform well in those conditions. It now warns about Xms/Xmx/AlwaysPreTouch configuration. These settings are not adjusted automatically, because doing so would affect startup time. These new warnings can be shunned by overriding the default logging level with -Xlog:gc=error.

Improved Javadoc Search (JDK-8220497)

tools/javadoc(tool)

The search feature in API documentation generated by Javadoc has been improved. You can now consistently search API documentation using partial terms and camel-case abbreviations. See https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/javadoc-search-spec.html for a full description of search features.

Build 18

DatagramChannel.disconnect may leave the channel's socket in an unspecified state (JDK-8231260)

core-libs/java.nio

The DatagramChannel implementation has been updated in this release so that the disconnect method attempts to workaround Linux kernel behavior that reverts the local port to 0 after dissolving the association. The issue arises when a DatagramChannel is initially bound to an ephemeral port, connected (by calling its connect method), and then disconnected (by calling its disconnect method). The workaround in the DatagramChannel::disconnect is to attempt to re-bind the channel's socket to its original port. This will usually succeed but if it fails then IOException will be thrown. This workaround has been used in the DatagramSocket implementation for several releases.

As part of this change, the javadoc for DatagramChannel::disconnect has been updated with an API note to make it clear that an IOException may leave the channel's socket in an unspecified state. The API note also strongly recommends that the channel be closed when disconnect fails.

Build 16

DnsClient TCP socket timeout (JDK-8228580)

core-libs/javax.naming

The semantics of the com.sun.jndi.dns.timeout.initial property of the JNDI DNS provider implementation have been amended. The value of this timeout now uniformly applies to both UDP and TCP queries. Previously it applied only to UDP queries.

New Method to SAX ContentHandler for Handling XML Declaration (JDK-8230814)

xml/jaxp

A new method declaration is added to SAX ContentHandler in this release to receive notification of the XML declaration. Implementing this method, applications will be able to receive the values of version, encoding, and standalone attributes exactly as declared in the input document.

Build 15

Shenandoah self-fixing barriers (JDK-8231087)

hotspot/gc

Before this improvement, Shenandoah LRB barrier performance penalty for accessing forwarded objects involved resolving through the forwarding pointer, until the Update References phase fixed the affected references. A more efficient implementation ships now, where LRB self-fixes the forwarded reference on the same code path, eliminating continuous resolves for potentially hot accesses.

Self-fixing is implemented for C1 and C2 (JDK-8231087), interpreter (JDK-8232992) and runtime (JDK-8232010) barriers.

Shenandoah arraycopy improvements (JDK-8231086)

hotspot/gc

When handling Object[] arraycopy, Shenandoah used to evacuate array elements / fix references in the destination array after the copy. This is not efficient when multiple copies are done, as fixups would have to run on every copy. Plus, the fixups in the destination array do not improve the accesses to the source array.

Unfortunately, this was the only way to deal with arraycopy until the GC API was extended. In JDK 14 with GC API improvements, Shenandoah is now able to fix up object arrays at source before the arraycopy, which improves performance and opens up other optimization opportunities.

Build 14

Epsilon does not extend TLABs to max size (JDK-8230646)

hotspot/gc

Due to a simple implementation bug, Epsilon GC did not extend the size of the issued TLABs to the max size configured by user, or set by default. This bug might have introduced performance penalties and was generally confusing during performance analysis. This is now fixed and backported to 13u and 11u. Users are advised to double-check their performance results before and after this update.

MethodType::fromMethodDescriptorString requires "getClassLoader" permission (JDK-8229785)

core-libs/java.lang.invoke

MethodType::fromMethodDescriptorString is changed in this release that when security manager is present and loader parameter is null, it will perform RuntimePermission("getClassLoader") security permission check. This is to ensure that access to the system class loader is permitted.

Existing code that calls MethodType.fromMethodDescriptorString(desc, null) may get SecurityException if access the system class loader is denied. The security policy will need to be configured to grant the permission. Applications running without security manager or with non-null loader is not impacted by this change.

Removal of sun.nio.cs.map system property (JDK-8229960)

core-libs/java.nio.charsets

The system property sun.nio.cs.map, added in JDK 1.4.1, has been removed. It was provided for applications to help migrate from old definition of Shift_JIS which was equivalent to MS Windows codepage 932, to the one that is defined by IANA. Applications that are using the mapping property will need to designate the correct charset name based on their needs.

Default ErrorListener No Longer Reports Warnings and Errors to the Console (JDK-8228854)

xml/javax.xml.transform

Prior to this release, the javax.xml.transform.ErrorListener specification defined that the default ErrorListener implementation reported warnings and errors to System.err, and System.out in some cases. This requirement has been removed as of this release and the default ErrorListener now takes no action for warnings and recoverable errors; and in the case of a severe error, throws a TransformerException.

It is recommended that applications always register their own ErrorListener to ensure proper handling of warnings and errors.

Build 12

CDS behavior change with non-existent files during archive creation time (JDK-8227370)

hotspot/runtime

In JDK 14, CDS runtime classpath validation is now more forgiving when dealing with files in the classpath that do not exist.

At CDS archive dump time, all non-existent elements in the classpath are automatically stripped. E.g., if the command is

java -cp nosuchfile.jar:hello.jar -Xshare:dump 
     -XX:SharedClassListFile=hello.classlist 
     -XX:SharedArchiveFile=hello.jsa

After removing the non-existing elements, the classpath recorded in hello.jsa becomes "hello.jar".

Also, at run time, when the CDS archive is loaded, all non-existent elements in the classpath are ignored. With the above example, all of the following commands will successfully load the archive:

(1)

    java -cp nosuchfile.jar:hello.jar -Xshare:on 
         -XX:SharedArchiveFile=hello.jsa 
         Hello

(2)

    java -cp hello.jar -Xshare:on 
         -XX:SharedArchiveFile=hello.jsa 
         Hello

(3)

    java -cp alsonosuchfile.jar:hello.jar -Xshare:on 
         -XX:SharedArchiveFile=hello.jsa 
         Hello

Whereas in JDK 13 and before, only (1) is allowed; (2) and (3) would trigger an error.

Build 11

Parallel GC Improvements (JDK-8224666)

hotspot/gc

Parallel GC adopted the same task management mechanism for scheduling parallel tasks as other collectors. This may result in significant performance improvements. As a result of the change, the following product flags have been obsoleted: -XX:BindGCTaskThreadsToCPUs, -XX:UseGCTaskAffinity, and -XX:GCTaskTimeStampEntries.

Build 10

Accounting currency format support (JDK-8215181)

core-libs

Currency format instances with accounting style, in which the amount is formatted in parentheses in some locales, can be obtained by calling NumberFormat.getCurrencyInstance(Locale) with "u-cf-account" Unicode locale extension. Refer to CLDR's accounting currency format style for additional information.

Turn off AOT by default and change related flags to experimental (JDK-8227439)

hotspot/compiler

Following AOT support related flags have been made experimental: UseAOT, PrintAOT and AOTLibrary. Also default value of UseAOT has been changed from enabled to disabled.

Build 8

SunJCE provider now throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding (JDK-8180392)

security-libs/javax.crypto

Prior to this release, the SunJCE provider incorrectly returned a Cipher instance for the "AES/GCM/NoPadding" transformation when a caller requested "AES/GCM/PKCS5Padding". The SunJCE provider now throws NoSuchAlgorithmException when "AES/GCM/PKCS5Padding" is requested. If you are impacted by this issue, the workaround is to use "AES/GCM/NoPadding" instead.

Removed Deprecated java.security.acl APIs (JDK-8191138)

security-libs/java.security

The deprecated java.security.acl APIs have been removed. This includes the the following classes in that package: Acl, AclEntry, AclNotFoundException, Group, LastOwnerException, NotOwnerException, Owner, and Permission.

MethodHandles::privateLookupIn requires PRIVATE lookup mode (JDK-8173978)

core-libs/java.lang.invoke

MethodHandles::privateLookupIn has changed in this release that the caller Lookup must have both PRIVATE and MODULE access because an application intending to share intra-module access using MODULE alone will inadvertently also share deep reflection to its own module. In addition, if a Lookup object is created by Lookup::in or MethodHandles::privateLookupIn teleporting from one module to another module, MODULE mode is dropped. In other words, MethodHandles::privateLookupIn requires the caller lookup object that must be created by a member from the caller's module and not produced by cross-module teleporting.

If a lookup object L is created by calling MethodHandles.privateLookupIn(C.class, caller) where C is a class in module M1 and the caller's lookup class is in module M0, the resulting lookup object can access public members of public class D in module M2 if M0 and M1 read M2 and D is in a package exported from M2 to at least both M0 and M1. If D in M2 is accessible to M0 but not accessible to M1, then this lookup object L will fail to lookup members in D in this release but succeeds in previous release.

Removal of netscape.javascript.JSObject::getWindow Method (JDK-8222563)

deploy

The obsolete netscape.javascript.JSObject::getWindow method has been removed. This method was deprecated in JDK 9. As of JDK 11, there is no longer a useful way to use this method; it always returns null.

Build 5

Added -XX:+AdjustStackSizeForTLS flag (JDK-8225035)

hotspot/runtime

The glibc library allocates some thread-local storage (TLS) in the stack of a newly created thread, leaving less stack than requested for the thread to do its work. This is particularly a problem for threads with small stack sizes. It is an inherited issue from a well-known glibc problem, 'Program with large TLS segments fail' [0] and has been observed in Java applications. In one of the reported JVM failure instances, the issue manifests as a StackOverflowError on the process reaper thread, which has a small stack size. The java.lang.Thread constructor allows users to specify the stack size for a new thread. The created thread may encounter the TLS problem when the specified size is too small to accommodate the on-stack TLS blocks.

In JDK 8, a system property, jdk.lang.processReaperUseDefaultStackSize was introduced to address the TLS issue for reaper threads only. Setting the property gives a bigger stack size to the reaper threads.

To address the issue for all threads, a general purpose workaround was implemented in Java which adjusts thread stack size for TLS. It can be enabled by the AdjustStackSizeForTLS command-line option:

-XX:+AdjustStackSizeForTLS

When creating a new thread, if AdjustStackSizeForTLS is true, the static TLS area size is added to the user requested stack size. AdjustStackSizeForTLS is disabled by default.

Reference: [0] http://sourceware.org/bugzilla/show_bug.cgi?id=11787

Not Yet Integrated

JEP 359: Records (Preview) (JDK-8222777)

core-libs/java.lang

In JDK 14, the preview feature "Records" (JEP 359) adds a new class java.lang.Record. The java.lang package is implicitly imported on demand, i.e., import java.lang.*. If code in an existing source file imports some other package on demand, e.g. import com.myapp.*;, and that other package declares a type called Record, then code in the existing source file which refers to that type will not compile without change. To make the code compile, import the other package's Record type using a single-type import, e.g., import com.myapp.Record;.

JEP 364: ZGC on macOS (JDK-8229358)

hotspot/gc

The Z Garbage Collector (ZGC) is now available as an experimental feature on macOS. To enable it, use the JVM flags -XX:+UnlockExperimentalVMOptions -XX:+UseZGC.

Text Visibility Issues in macOS Dark Mode (JDK-8228555)

client-libs

A number of bugs have been reported against Dark Mode on macOS which require a fix in the JavaRuntimeSupport framework (JRS); an issue has been filed with Apple:

FB6798883: The JavaRuntimeSupport.framework does not work properly in Dark Mode

See JDK-8231386 and JDK-8228555 for examples of issues caused by this bug.

Delivered

Shenandoah supports concurrent class unloading (JDK-8226241)

hotspot/gc

As of JDK 14, Shenandoah GC supports concurrent class unloading. It improves the prior stop-the-world implementation to be fully concurrent, which minimizes the class unloading work done during Final Mark pause. This also enables class unloading for the regular GC cycles by default, in addition to already enabled class unloading during degenerated and full GC cycles. This relies heavily on runtime facilities introduced in JDK 12, and therefore not available in 11-shenandoah and 8-shenandoah.

JEP 367: Remove the Pack200 Tools and API (JDK-8232022)

tools/jar

The pack200 and unpack200 tools, added in JDK 5.0, have been removed. The class java.util.jar.Pack200 and the interfaces java.util.jar.Pack200.Packer and java.util.jar.Pack200.Unpacker have also been removed. These tools and API were deprecated for removal in Java SE 11 with the express intent to remove them in a future release. In addition, in the jar tool, the n sub-option to jar c has been removed.

Deprecate the Legacy Elliptic Curves for Removal (JDK-8234924)

security-libs/javax.crypto

The following named elliptic curves supported by the SunEC provider have been deprecated:

brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1, secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3

The implementations of these curves are targeted to be removed in a subsequent JDK release. A small number of them may be replaced with a more modern implementation.

JEP 364: ZGC on Windows (JDK-8232364)

hotspot/gc

The Z Garbage Collector (ZGC) is now available as an experimental feature on Windows. To enable it, use the JVM flags -XX:+UnlockExperimentalVMOptions -XX:+UseZGC.

JEP 345: NUMA-Aware Memory Allocation for G1 (JDK-8210473)

hotspot/gc

The G1 garbage collector now tries to allocate and keep objects on the same NUMA node in the young generation across garbage collections. This is similar to Parallel GC NUMA awareness.

G1 attempts to evenly distribute Humongous and Old regions across all available NUMA nodes using a strict interleave. Placement of objects copied from young to old generation is random.

These new NUMA-Aware Memory Allocation heuristics are automatically enabled using the -XX:+UseNUMA command line option.

For more information see JDK-8210473.

JEP 363: Removal of the Concurrent Mark and Sweep Garbage Collector (CMS) (JDK-8229049)

hotspot/gc

The CMS garbage collector has been removed. -XX:UseConcMarkSweepGC and aliases -Xconcgc and -Xnoconcgc are obsoleted as well as all CMS specific options (too many to list).