A new Class Hierarchy Analysis implementation is introduced in the HotSpot JVM. It features enhanced handling of abstract and default methods which improves inlining decisions made by the JIT-compilers. The new implementation supersedes the original one and is turned on by default.

To help diagnose possible issues related to the new implementation, the original implementation can be turned on by specifying the -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA command-line flags.

The original implementation may be removed in a future release.

This enhancement causes phantom references to be automatically cleared by the garbage collector just as soft and weak references are.

An object becomes phantom reachable after it has been finalized. This change may cause phantom reachable objects to be garbage collected earlier. Previously, the referent was kept alive until the associated PhantomReference objects were collected or cleared by the application. This behavioral change should only impact existing code that depends on a PhantomReference being enqueued rather than when the referent is freed from the heap.

The java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and the get() method will return null in Enterprise Performance Pack and later releases.

Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid a memory leak because its referent is no longer referenced. In other words, the get method is not expected to be called in common cases once the enqueue method has been called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, a NullPointerException may be thrown. Such code will need to be updated.

The java.lang.ref.Reference::clone method always throws a CloneNotSupportedException. Therefore, Reference objects cannot be meaningfully cloned. To copy a Reference object, call the constructor to create a new Reference object with the same referent and reference queue instead.

In Java SE Subscription Enterprise Performance Pack, constant pool patching of classes created by calling the unsupported sun.misc.Unsafe.defineAnonymousClass method is not enabled and could cause your application to crash. The cpPatches argument to defineAnonymousClass should be null.

In Java SE Subscription Enterprise Performance Pack, the methods monitorEnter, monitorExit, and tryMonitorEnter have been removed from the unsupported sun.misc.Unsafe class. These methods are not used within the JDK itself and are very rarely used outside of the JDK.

The Java SE 8 Enterprise Performance Pack follows the versioning format defined by JEP 322, and reports the actual VM version of 17.x, when, for example, java -version is invoked. However, for compatibility purposes, the sun.misc.Version methods jvmMajorVersion() and jvmMinorVersion() instead report the same VM version as Java SE 8 i.e. 25.x. This ensures that application code checking for a Java 8 runtime by looking for a major version greater than, or equal to, 25, will work correctly even though the actual VM version is 17.

Some linux kernel versions (including, but not limited to 3.13.0-121-generic and 4.4.0-81-generic) are known to contain an incorrect fix for a linux kernel stack overflow issue (See CVE-2017-1000364). The incorrect fix can trigger crashes in the Java Virtual Machine. Upgrading the kernel to a version that includes the corrected fix addresses the problem.

This change enforces the unqualified name format checks for NameAndType strings as outlined in the JVM specification sections 4.4.6 and 4.2.2, meaning that some illegal names and descriptors that users may be utilizing in their classfiles will now be caught with a Class Format Error. This includes format checking for all strings under non-referenced NameAndType's. Users will see a change if they (A) are using Java classfile version 6 or below and have an illegal NameAndType descriptor with no Methodref or Fieldref reference to it; or (B) are using any Java classfile version and have an illegal NameAndType name with no Methodref or Fieldref reference to it.

In both (A) and (B) the users will now receive a ClassFormatError for those illegal strings, which is an enforcement of unqualified name formats as delineated in JVMS 4.2.2.

When dumping the heap in binary format, HPROF format 1.0.2 is always used now. Previously, format 1.0.1 was used for heaps smaller than 2GB. HPROF format 1.0.2 is also used by jhsdb jmap for the serviceability agent.

When running with compressed references on x86_64, one of the CPU registers holds the heap base pointer to be used for references encoding/decoding. This register is not available for register allocation.

Simple implementations before this release made this register unavailable (and thus unused) even if compressed references were disabled. In this release, the implementation was revised to put this unused register back into the available registers pool. Configurations with large heaps and/or -XX:-UseCompressedOops benefit from this improvement.

In the previous release, a NotifyFramePop request was only cleared when the JVMTI_EVENT_FRAME_POP was enabled. Now it is always cleared when the corresponding frame is popped, regardless of whether the JVMTI_EVENT_FRAME_POP is enabled or not.

For improved performance, JVM/TI ObjectFree events are no longer posted within GC pauses. The events are still posted as requested, and will be posted before ObjectFree events are enabled or disabled with SetNotificationMode. SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.

The default value for BiasedLockingStartupDelay has been changed to 0. The flag BiasedLockingStartupDelay previously had the default value 4000 which delayed the use of biased locking with 4 s (4000 ms). The reason for this delay was performance but recent performance runs show no difference between the 4000 ms delay and no delay. Since having the delay will cause other parts of the VM to do extra work, having the default set to 0 makes more sense.

The JNI function DetachCurrentThread has been added to the list of JNI functions that can safely be called with an exception pending. The HotSpot Virtual Machine has always supported this as it reports that the exception occurred in a similar manner to the default handling of uncaught exceptions at the Java level. Other implementations are not obligated to do anything with the pending exception.

The -XX:-JNIDetachReleasesMonitors flag requested that the VM run in a pre-JDK 6 compatibility mode with regard to not releasing monitors when a JNI attached thread detaches. This option is obsolete in JDK 9, and is ignored, as the VM always conforms to the JNI Specification and releases monitors. Use of this option will result in a warning being issued in JDK 9 and it may be removed completely in a future release.

When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as JVMTI_HEAP_ROOT_MONITOR or JVMTI_HEAP_REFERENCE_MONITOR) and in heap dumps (reported as HPROF_GC_ROOT_MONITOR_USED). As of this release, a weak reference is used. These are not observable to JVM TI or heap dumps. Consequently, JVMTI_HEAP_ROOT_MONITOR, JVMTI_HEAP_REFERENCE_MONITOR and HPROF_GC_ROOT_MONITOR_USED are longer reported.

The FlatProfiler, deprecated in JDK 9, has been made obsolete by removing the implementation code. The FlatProfiler was enabled by setting the -Xprof VM argument. The -Xprof flag remains recognized in this release; however, setting it will print out a warning message.

The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: sigset, signal and sigaction. Only sigaction is a cross-platform, supported, API for multi-threaded processes. Both signal and sigset are considered obsolete on those platforms that still define them. Consequently, the use of signal and sigset with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release.