The following sections summarize changes made in Java SE 8u391 Enterprise Performance Pack. Bug fixes and any other changes are listed below in date order, most current update first. Note that bug fixes in the previous BPR are also included in the current update release.
This BPR contains all of the fixes included in the previous JDK 8 Enterprise Performance Pack BPR.
October 17, 2023
The full version string for this update release is 8u391-perf-b13 (where "b" means "build"). The version number is 8u391-perf.
For more information, refer to Timezone Data Versions in the JRE Software.
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u391 are specified in the following table:
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
8 | 8u391-perf-b13 |
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u391) be used after the next critical patch update scheduled for January 16, 2024.
Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u391) on 2024-02-16. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
A virtual machine crash was observed in JDK 11.0.19 and 17.0.7 when executing the GregorianCalender.computeTime()
method (JDK-8307683). It was found that although the root cause of the crash is an old issue, a recent fix for a rare issue in the C2 compiler (JDK-8297951) made the crash much more likely. To mitigate this, the fix has been reverted in JDK 11.0.20 and 17.0.8 and will be reapplied once JDK-8307683 is resolved.
# | BugId | Component | Subcomponent | Summary |
---|---|---|---|---|
1 | JDK-8274243 | hotspot | compiler | Implement fast-path for ASCII-compatible CharsetEncoders on aarch64 |
2 | JDK-8299544 | hotspot | compiler | Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs |
3 | JDK-8153837 | hotspot | compiler | AArch64: Handle special cases for MaxINode & MinINode |
4 | JDK-8272586 | hotspot | compiler | emit abstract machine code in hs-err logs |
5 | JDK-8308192 | hotspot | compiler | Error in parsing replay file when staticfield is an array of single dimension |
6 | JDK-8309266 | hotspot | compiler | C2: assert(final_con == (jlong)final_int) failed: final value should be integer |
7 | JDK-8300584 | hotspot | compiler | Accelerate AVX-512 CRC32C for small buffers |
8 | JDK-8274986 | hotspot | compiler | max code printed in hs-err logs should be configurable |
9 | JDK-8310126 | hotspot | compiler | C1: Missing receiver null check in Reference::get intrinsic |
10 | JDK-8284760 | hotspot | compiler | Correct type/array element offset in LibraryCallKit::get_state_from_digest_object() |
11 | JDK-8299158 | hotspot | compiler | Improve MD5 intrinsic on AArch64 |
12 | JDK-8303154 | hotspot | compiler | Investigate and improve instruction cache flushing during compilation |
13 | JDK-8252990 | hotspot | compiler | Intrinsify Unsafe.storeStoreFence |
14 | JDK-8305088 | hotspot | compiler | SIGSEGV in Method::is_method_handle_intrinsic |
15 | JDK-8296545 | hotspot | compiler | C2 Blackholes should allow load optimizations |
16 | JDK-8292713 | hotspot | compiler | Unsafe.allocateInstance should be intrinsified without UseUnalignedAccesses |
17 | JDK-8302736 | hotspot | compiler | Major performance regression in Math.log on aarch64 |
18 | JDK-8307572 | hotspot | compiler | AArch64: Vector registers are clobbered by some macroassemblers |
19 | JDK-8280396 | hotspot | gc | G1: Full gc mark stack draining should prefer to make work available to other threads |
20 | JDK-8308643 | hotspot | gc | Incorrect value of 'used' jvmstat counter |
21 | JDK-8284532 | hotspot | jfr | Memory leak in BitSet::BitMapFragmentTable in JFR leak profiler |
22 | JDK-8283520 | hotspot | jfr | JFR: Memory leak in dcmd_arena |
23 | JDK-8307526 | hotspot | jfr | [JFR] Better handling of tampered JFR repository |
24 | JDK-8309862 | hotspot | jfr | Unsafe list operations in JfrStringPool |
25 | JDK-8307331 | hotspot | jvmti | Correctly update line maps when class redefine rewrites bytecodes |
26 | JDK-8306428 | hotspot | runtime | RunThese30M.java crashed with assert(early->flag() == current->flag() || early->flag() == mtNone) |
27 | JDK-8297887 | hotspot | runtime | Update Siphash |
28 | JDK-8305425 | hotspot | runtime | Thread.isAlive0 doesn't need to call into the VM |
29 | JDK-8269466 | hotspot | runtime | Factor out the common code for initializing and starting internal VM JavaThreads |
30 | JDK-8287854 | hotspot | runtime | Dangling reference in ClassVerifier::verify_class |
31 | JDK-8303215 | hotspot | runtime | Make thread stacks not use huge pages |
32 | JDK-8290067 | hotspot | runtime | Show stack dimensions in UL logging when attaching threads |
33 | JDK-8283849 | hotspot | svc | AsyncGetCallTrace may crash JVM on guarantee |
34 | JDK-8301170 | hotspot | svc | perfMemory_windows.cpp add free_security_attr to early returns |
35 | JDK-8295657 | hotspot | svc-agent | SA: Allow larger object alignments |