The following sections summarize changes made in all Enterprise Performance Pack BPR releases. The BPR releases are listed below in date order, most current BPR first. Note that bug fixes in previous BPRs are also included in the current BPR.
|JDK-8292260||hotspot||compiler||C2 Compilation Errors Unpredictably Crashes|
The Java SE Subscription Enterprise Performance Pack (EPP) is a commercial feature release of the Java SE platform. It contains new features and enhancements in many functional areas. It is currently available only through My Oracle Support. It is available as part of an Oracle Java SE Subscription and Oracle Cloud Infrastructure (OCI) Subscription. The Release Notes below describe the features, important changes, enhancements, and other information about the Enterprise Performance Pack.
Enterprise Performance Pack runtime brings improved performance, new features, and enhancements from the Java Virtual Machine from JDK 17 to JDK 8. It reduces the memory footprint for Java SE 8 workloads. It is ideal if you want or need to use Java SE 8 and you are running those workloads at scale. If you need to develop applications, Oracle recommends that you use the full JDK.
Enterprise Performance Pack is for server-side, headless systems (systems that operate without a graphical user interface or peripheral devices like a keyboard or a mouse) running 64-bit Linux on Intel or ARM.
Links to other sources of information about the Enterprise Performance Pack are also provided below:
The full version string for this update release is 1.8.0_345-perf-97-b06 (where "b" means "build"). The version number is 8u345.
IANA Data 2022a
The Enterprise Performance Pack contains IANA time zone data version 2022a. For more information, refer to Timezone Data Versions in the JRE Software.
This section describes Enterprise Performance Pack features and important information. In some cases, the descriptions provide links to additional detailed information about an issue or a change.
New Garbage Collector
Enterprise Performance Pack supports the latest garbage collector, ZGC.
The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector (JEP 333). At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times.
Applications moving from Parallel GC, CMS GC, or G1 GC to ZGC might observe higher CPU utilization and might require an increase in Java heap space. The tuning options for ZGC in the presence of observing allocation stalls are: increasing the max Java heap size (-Xmx), or setting -XX:SoftMaxHeapSize to a value less than -Xmx, or increasing the number of concurrent GC threads and disabling dynamic GC threads (-XX:ConcGCThreads=n -XX:-UseDynamicGCThreads), or some combination of those three.
See Enterprise Performance Pack documentation for more information about JVM options and Enterprise Performance Pack configuration.
Enterprise Performance Pack supports a common logging system for all components of the JVM. This provides line-at-a-time, human readable log messages enabled at the command line through the
-Xlog flag. See Printing JVM Information in the Enterprise Performance Pack User's Guide for more details.
Relevant Changes for Unified Logging: ➜ Use Unified Logging for GC logging (JDK-8145092) ➜ print_tracing_info Uses Unified Logging (JDK-8184286) ➜ Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents (JDK-8256718)
This is a space-efficient internal representation of strings, which reduces memory footprint and garbage collection activity. See Compact Strings in the Java Virtual Machine Guide of JDK 17 for more details.
Relevant Changes for Compact Strings: ➜ JEP 254: Compact Strings (JDK-8054307)
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 section describes Enterprise Performance Pack enhancements. In some cases, the descriptions provide links to additional detailed information about an issue or a change.
Enterprise Performance Pack's Garbage First (G1) collector should not require additional tuning or re-tuning; it's the default garbage collector. Moving from CMS GC to G1 should follow the guidance suggested in the Enterprise Performance Pack User's Guide. Only G1 supports String Deduplication. This feature continuously checks for duplicate String objects during garbage collection thus reducing overall heap size.
Since Enterprise Performance Pack has the Compact Strings feature which reduces the amount of Java heap space occupied by Java Strings, improved performance with Parallel GC may be realized by re-tuning Java heap sizes.
Relevant Changes for Garbage Collectors: ➜ Parallel GC Enables Adaptive Parallel Reference Processing by Default (JDK-8204686) ➜ G1 Enables Adaptive Parallel Reference Processing by Default (JDK-8205043) ➜ JEP 345: NUMA-Aware Memory Allocation for G1 (JDK-8210473) ➜ Parallel GC Improvements (JDK-8224666) ➜ Improvements in Serial GC Young pause time report (JDK-8215221) ➜ JEP 307: Parallel Full GC for G1 (JDK-8172890) ➜ Concurrently Uncommit Memory in G1 (JDK-8236926) ➜ Improved Ergonomics for G1 Heap Region Size (JDK-8241670) ➜ Improve Ergonomics for Sparse PRT Entry Size (JDK-8223162) ➜ New PerfCounters for STW Phases on Concurrent GC Are Available (JDK-8153333) ➜ G1 May Uncommit Memory During Marking Cycle (JDK-6490394) ➜ Garbage Collectors Adaptively Scale the Number of Threads by Default (JDK-8198510) ➜ JEP 363: Remove the Concurrent Mark and Sweep (CMS) Garbage Collector (JDK-8229049) ➜ Various GC combinations have now been removed (JDK-8044022) ➜ JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination (JDK-8233301) ➜ UseAutoGCSelectPolicy has been deprecated (JDK-8166461)
Enterprise Performance Pack includes several runtime options from JDK 17. However, some options from JDK 8 are not available in Enterprise Performance Pack. For example, Enterprise Performance Pack uses Unified JVM Logging, which replaces options that print details about the JVM with -Xlog:gc options. See the Enterprise Performance Pack documentation for more information about the changes made to the JVM options.
A number of runtime options have been added or removed from the Enterprise Performance Pack. See the Changes to JVM Runtime Options section of the Enterprise Performance Pack User's Guide.
Relevant Changes for Runtime Options: ➜ Flags Controlling C1 Inlining Have New Names (JDK-8235673) ➜ Improved CompileCommand Flag (JDK-8256508) ➜ Improve the Behavior of MaxRAM Settings and UseCompressedOops (JDK-8222252) ➜ VM Options AdaptiveSizePausePolicy and ParallelGCRetainPLAB are obsolete (JDK-8073861) ➜ Added -XX:+AdjustStackSizeForTLS Flag (JDK-8225035) ➜ Obsolete -XX:UseAdaptiveGCBoundary (JDK-8228991) ➜ Removal of Obsolete -X Options (JDK-8179018) ➜ Obsolete Support for Commercial Features (JDK-8202331) ➜ Obsoleted -XX:+/-MonitorInUseLists (JDK-8211384) ➜ Deprecated Java Options -Xverify:none and -noverify (JDK-8214719) ➜ Command-Line Flag -XX:+ExtensiveErrorReports (JDK-8211845)
Class Data Sharing
This feature helps reduce the startup time and memory footprint between multiple Java Virtual Machines. See the Class Data Sharing section of the Java Virtual Machine Guide of JDK 17 for more information.
Relevant Changes for Class Data Sharing: ➜ CDS Behavior Change With Non-existent Files During Archive Creation (JDK-8227370)
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.
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.
java.lang.ref.Reference::clone method always throws a
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
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
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.
The following notes describe additional changes and information about this release. In some cases, the following descriptions provide links to additional detailed information about an issue or a change.
See Running Tools and Using Libraries on Enterprise Performance Pack for more information.
Application Class Data Sharing (AppCDS)
Application Class Data Sharing (AppCDS) extends class data sharing (CDS) to enable application classes to be placed in a shared archive. See the Application Class Data Sharing section of the
java command page.
Relevant Changes for AppCDS: ➜ JEP 310: Application Class-Data Sharing (JEP 310)
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.
-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_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,
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:
sigaction is a cross-platform, supported, API for multi-threaded processes. Both
sigset are considered obsolete on those platforms that still define them. Consequently, the use of
sigset with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release.