- core-libs-dev - openjdk.org

RFR: 8372136: VectorAPI: Refactor subword gather load API java implementation
by Xiaohong Gong 12 Feb '26

12 Feb '26

The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution. The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles. Key changes: 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter. 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation. The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where: - "non masked" means the gather operation is not the masked gather API. - "masked" means the gather operation is the masked gather API. - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`. - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`. - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`. - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases. ---------------------------------------------------------------------------- | UseAVX=3 | UseAVX=2 | |-----------------------------|-----------------------------| | non masked | masked | non masked | masked | |--------------|--------------|--------------|--------------| 1 gather cases | 0.99 ~ 1.06x | 0.94 ~ 1.11x | 0.94 ~ 1.00x | 0.99 ~ 1.11x | ---------------|--------------|--------------|--------------|--------------| 2 gather cases | 0.94 ~ 1.01x | 0.88 ~ 0.97x | 0.8 ~ 1.13x | 0.82 ~ 0.93x | ---------------|--------------|--------------|--------------|--------------| 4 gather cases | 0.92 ~ 0.95x | 0.84 ~ 0.88x | 0.98 ~ 1.06x | 0.81 ~ 0.92x | ---------------|--------------|--------------|--------------|--------------| Un-intrinsified| N/A | N/A | 1.48 ~ 1.65x | 1.1 ~ 1.53x | ---------------|--------------|--------------|--------------|--------------| There are performance regressions especially for APIs that need splitting and merging operations. And the regressions are more significant for the masked cases. This is caused by the additional vector/mask slice and merging operations in Java code, which I think is un-avoidable. Note-1: Compared with before, this patch **disables** the gather API intrinsification for **64-bit species** when **`MaxVectorSize=8`**, because it would generate a 16-bit vector, which is smaller than the supported minimum vector size of 32-bit. This limitation can be addressed by adjusting the IR pattern in the future. However, this requires significant refactoring of the X86 backend implementation, which is challenging for me. I'd like to leave this as a separate work. And it would be much more helpful if I can get any help from the X86 experts. Note-2: This patch only includes the refactoring of the Java API code and the HotSpot x86 backend implementation. A follow-up patch will add the support for the AArch64 SVE backend. [1] https://github.com/openjdk/jdk/pull/26236 [2] https://github.com/openjdk/jdk/pull/24104 ------------- Commit messages: - 8372136: VectorAPI: Refactor subword gather load API java implementation Changes: https://git.openjdk.org/jdk/pull/28520/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28520&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372136 Stats: 558 lines in 13 files changed: 383 ins; 78 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/28520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28520/head:pull/28520 PR: https://git.openjdk.org/jdk/pull/28520

2 7

RFR: 8371656: HashMap.putAll() optimizations
by jengebr 11 Feb '26

11 Feb '26

# HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks ## Summary This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used. ## Problem Context ### Megamorphic Call Site Overhead in Map Iteration `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types: 1. `m.entrySet()` becomes megamorphic across different map implementations 2. `entrySet().iterator()` creates different iterator types 3. `entry.getKey()` and `entry.getValue()` calls vary by map type 4. Individual `putVal()` calls for each entry When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization. ## Optimized Methods ### HashMap - **`putMapEntries(Map<? extends K, ? extends V> m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying - **`putMapEntries(HashMap<? extends K, ? extends V> src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing. Avoids polymorphic issues and eliminates redundant calls to HashMap.hash(). ## Implementation Details ### HashMap-to-HashMap Fast Path Directly iterates over `src.table` to eliminate entrySet() allocation and polymorphic iterator calls, using the internal Node structure for maximum efficiency. ### UnmodifiableMap Unwrapping Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this direct access. ## Performance Impact | Source Type | Size | Poisoned | Baseline | Optimized | Improvement | |-------------|------|----------|----------|-----------|-------------| | HashMap | 0 | true | 9.429 ns/op | 8.875 ns/op | **6% faster** | | HashMap | 5 | true | 181.645 ns/op | 80.012 ns/op | **56% faster** | | HashMap | 25 | true | 796.415 ns/op | 283.643 ns/op | **64% faster** | | TreeMap | 0 | true | 9.356 ns/op | 9.155 ns/op | **-** | | TreeMap | 5 | true | 169.233 ns/op | 169.566 ns/op | **-** | | TreeMap | 25 | true | 792.667 ns/op | 791.195 ns/op | **-** | | ConcurrentHashMap | 0 | true | 9.275 ns/op | 9.156 ns/op | **-** | | ConcurrentHashMap | 5 | true | 229.291 ns/op | 227.382 ns/op | **-** | | ConcurrentHashMap | 25 | true | 1071.336 ns/op | 1105.111 ns/op | **-** | | UnmodifiableMap(HashMap) | 0 | true | 13.563 ns/op | 9.253 ns/op | **32% faster** | | UnmodifiableMap(HashMap) | 5 | true | 318.184 ns/op | 76.264 ns/op | **76% faster** | | UnmodifiableMap(HashMap) | 25 | true | 1510.489 ns/op | 284.001 ns/op | **81% faster** | | UnmodifiableMap(TreeMap) | 5 | true | 323.412 ns/op | 186.990 ns/op | **42% faster** | | UnmodifiableMap(TreeMap) | 25 | true | 1529.959 ns/op | 809.125 ns/op | **47% faster** | This shows substantial improvements (32-81%) for optimized paths while maintaining no significant regression for non-optimized paths. ### Call Site Poisoning Impact | Source Type | Size | Unpoisoned | Poisoned | Degradation | |-------------|------|------------|----------|-------------| | HashMap | 0 | 4.949 ns/op | 9.429 ns/op | 91% slower | | HashMap | 5 | 86.796 ns/op | 181.645 ns/op | 109% slower | | HashMap | 25 | 322.196 ns/op | 796.415 ns/op | 147% slower | | TreeMap | 0 | 5.043 ns/op | 9.356 ns/op | 86% slower | | TreeMap | 5 | 102.329 ns/op | 169.233 ns/op | 65% slower | | TreeMap | 25 | 433.668 ns/op | 792.667 ns/op | 83% slower | | ConcurrentHashMap | 0 | 5.054 ns/op | 9.275 ns/op | 84% slower | | ConcurrentHashMap | 5 | 135.616 ns/op | 229.291 ns/op | 69% slower | | ConcurrentHashMap | 25 | 591.134 ns/op | 1071.336 ns/op | 81% slower | | UnmodifiableMap(HashMap) | 0 | 5.319 ns/op | 13.563 ns/op | 155% slower | | UnmodifiableMap(HashMap) | 5 | 146.471 ns/op | 318.184 ns/op | 117% slower | | UnmodifiableMap(HashMap) | 25 | 393.053 ns/op | 1510.489 ns/op | 284% slower | | UnmodifiableMap(TreeMap) | 0 | 5.331 ns/op | 13.539 ns/op | 154% slower | | UnmodifiableMap(TreeMap) | 5 | 78.215 ns/op | 323.412 ns/op | 314% slower | | UnmodifiableMap(TreeMap) | 25 | 332.189 ns/op | 1529.959 ns/op | 361% slower | ## FAQ **Q: Why use exact class check instead of instanceof for HashMap?** A: This prevents the fast path from becoming megamorphic if HashMap subclasses are common, ensuring the optimization remains effective. Also, subclasses might override behavior in ways that make direct table access incorrect. **Q: Is it safe to make UnmodifiableMap package-private?** A: Yes. The class remains non-public and is only accessible within java.util. The change enables internal optimizations without exposing implementation details to external code. **Q: Are these optimizations safe?** A: Yes. HashMap-to-HashMap copying maintains identical behavior, and UnmodifiableMap unwrapping accesses the exact same data through a more direct path. **Q: What about other Map types?** A: Profiling data shows these are the biggest opportunities. Others exist but are lower-priority. **Q: How do these optimizations interact with existing code?** A: These are internal implementation optimizations that maintain full API compatibility. No external code changes are required. ## Testing Comprehensive unit tests added to MOAT.java covering: - HashMap.putAll() with various source map types - UnmodifiableMap handling in putAll operations - Correctness verification for all optimization paths Tier-1 tests passed. ------------- Commit messages: - Bug fix & unit test - fixing whitespace - Optimizing HashMap.putAll() and .<init> for HashMap and C$UM Changes: https://git.openjdk.org/jdk/pull/28243/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371656 Stats: 235 lines in 4 files changed: 230 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28243.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28243/head:pull/28243 PR: https://git.openjdk.org/jdk/pull/28243

4 12

RFR: 8377461: Add ZipFile test for incorrect number of entries reported in ENDTOT
by Eirik Bjørsnøs 11 Feb '26

11 Feb '26

Please review this PR introducing a test to verify that `ZipFile::size` reports the actual number of CEN entries in a ZIP file, despite an incorrect number being reported in the END header. Background: The `ZipFile` implementation treats `ENDTOT` as an indication, but falls back to counting CEN entries if this number is too low. After parsing the CEN, there is also code to adjust the total down to the actual count of CEN entries. The behavior of always reporting the actual number of CEN entries has no current test coverage in the JDK. It seems good to have tests excercising these code paths and protecting against regressions in this area. Verification: Verified that the new test catches introduced regressions in handling over- and underreported numbers in ENDTOT and that no existing test catches such regressions. Test-only change, `noreg-self`. ------------- Commit messages: - Also verify number of ZipFile::entries and count of ZipFile::stream. - Add test to verify ZipFile:size with incorrect ENDTOT fields Changes: https://git.openjdk.org/jdk/pull/29635/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29635&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377461 Stats: 116 lines in 1 file changed: 116 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29635.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29635/head:pull/29635 PR: https://git.openjdk.org/jdk/pull/29635

2 6

RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas.
by Stuart Monteith 11 Feb '26

11 Feb '26

MemorySegments allocated from shared Arena from java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | After: | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 | 16.52 | | 16 | 70.15 | 47.76 | 52.37 | 47.26 | 70.91 | 14.53 | | 24 | 77.38 | 78.14 | 81.67 | 71.98 | 87.20 | 21.70 | | 32 | 87.54 | 98.01 | 84.73 | 86.79 | 109.25 | 22.65 | | 48 | 121.54| 128.14 | 120.51 | 104.35 | 175.08 | 26.85 | ------------- Commit messages: - 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas Changes: https://git.openjdk.org/jdk/pull/28575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371260 Stats: 628 lines in 33 files changed: 402 ins; 38 del; 188 mod Patch: https://git.openjdk.org/jdk/pull/28575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28575/head:pull/28575 PR: https://git.openjdk.org/jdk/pull/28575

5 17

RFR: 8377656: JUnit test java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for BeforeAll/AfterAll
by Jaikiran Pai 11 Feb '26

11 Feb '26

Can I please get a review of this test-only fix which addresses a test issue in `test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java`? As noted in https://bugs.openjdk.org/browse/JDK-8377656, the test uses `private` methods for `@BeforeAll`/`@AfterAll` which is discouraged by JUnit. With the recent upgrade of jtreg https://bugs.openjdk.org/browse/JDK-8376355 such warnings now intentionally cause test failures. This wasn't caught during the integration of JDK-8376355 because the CI run for JDK-8376355 was done prior to the recent changes of these `java/util/zip` tests from testng to junit in https://bugs.openjdk.org/browse/JDK-8377116. I've first reproduced this failure locally and then reran the tests under `java/util/zip` with this change and they all pass now. tier1 testing is currently in progress and I'll integrate this once that completes. ------------- Commit messages: - 8377656: JUnit test java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for BeforeAll/AfterAll Changes: https://git.openjdk.org/jdk/pull/29670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29670&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377656 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29670/head:pull/29670 PR: https://git.openjdk.org/jdk/pull/29670

3 4

RFR: 8375285: Port fdlibm asinh to Java
by Anton Artemov 11 Feb '26

11 Feb '26

Hi, please consider the following changes: This is a port of FDLIBM asinh method. Original C vs transliteration port: $ diff -w fdlib_asinh.c Asinh.translit.java 1c1,3 < /* asinh(x) --- > /** > * Return the Inverse Hyperbolic Sine of x > * 2a5 > * 10a14,17 > private static final class Asinh { > private static final double one = 1.0; > private static final double ln2 = 6.93147180559945286227e-01; > private static final double huge = 1.0e300; 12,29c19 < #include "fdlibm.h" < < #ifdef __STDC__ < static const double < #else < static double < #endif < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ < huge= 1.00000000000000000000e+300; < < #ifdef __STDC__ < double asinh(double x) < #else < double asinh(x) < double x; < #endif < { --- > static double compute(double x) { 39c29 < w = __ieee754_log(fabs(x))+ln2; --- > w = log(Math.abs(x))+ln2; 41,42c31,32 < t = fabs(x); < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); --- > t = Math.abs(x); > w = log(2.0*t+one/(sqrt(x*x+one)+t)); 45c35 < w =log1p(fabs(x)+t/(one+sqrt(one+t))); --- > w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); 47a38 > } Transliteration port vs more idiomatic port: $ diff -w Asinh.translit.java Asinh.fdlibm.java 6,9c6,12 < * Based on < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] < * we have < * asinh(x) := x if 1+x*x=1, --- > * > * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF > * and sinh(asinh(x)) = x, -INF < x < INF. > * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. > * 1. Replace x by |x| as the function is odd. > * 2. > * asinh(x) := x, if 1+x^2 = 1, 12a16,22 > * > * > * > * Special cases: > * only asinh(0)=0 is exact for finite x. > * asinh(NaN) is NaN > * asinh(INF) is INF 14,15c24 < private static final class Asinh { < private static final double one = 1.0; --- > static final class Asinh { 24c33,35 < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ --- > if(ix >= 0x7ff00000) { > return x + x; /* x is inf or NaN */ > } 26c37,39 < if(huge+x>one) return x; /* return x inexact except 0 */ --- > if(huge + x > 1.0) { > return x; /* return x inexact except 0 */ > } 29c42 < w = log(Math.abs(x))+ln2; --- > w = Log.compute(Math.abs(x)) + ln2; 32c45 < w = log(2.0*t+one/(sqrt(x*x+one)+t)); --- > w = Log.compute(2.0 * t + 1.0 / (Sqrt.compute(x * x + 1.0) + t)); 35c48 < w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); --- > w = Log1p.compute(Math.abs(x) + t / (1.0 + Sqrt.compute(1.0 + t))); 37c50 < if(hx>0) return w; else return -w; --- > return hx > 0 ? w : -w; ------------- Commit messages: - 8375285: Addressed the reviewer's comments. - 8375285: Port of fdlibm asinh function Changes: https://git.openjdk.org/jdk/pull/29273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375285 Stats: 584 lines in 7 files changed: 580 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273 PR: https://git.openjdk.org/jdk/pull/29273

4 39

RFR: 8377514: jpackage: support passing multiple exceptions to the top-level error handler
by Alexey Semenyuk 11 Feb '26

11 Feb '26

Make the top-level error reporter handle suppressed exceptions. The bundling code may use the suppressed exceptions mechanism to report multiple error conditions. Rework reporting of multiple signing identity errors using the new mechanism, simplified `MacFromOptions.createMacPkgPackage()`. Additionally: - Simplified AppImageSigningConfigBuilder and SigningIdentityBuilder ------------- Commit messages: - Improve multiple expired certificate errors reporting in MacFromOptions#createMacPkgPackage(). Streamline SigningIdentityBuilder; Tighten up MacSignTest. - cli/Main: support reporting suppressed exceptions. This allows to report all error messages in the cases when they use suppressed exceptions to communicate multiple errors Changes: https://git.openjdk.org/jdk/pull/29643/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29643&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377514 Stats: 711 lines in 11 files changed: 444 ins; 80 del; 187 mod Patch: https://git.openjdk.org/jdk/pull/29643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29643/head:pull/29643 PR: https://git.openjdk.org/jdk/pull/29643

2 4

RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta)
by Naoto Sato 11 Feb '26

11 Feb '26

Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions. Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN. Here is the diff of the generated `conf/tzmappings` for reference: @@ -13,7 +13,7 @@ Arabian Standard Time:ZZ:Etc/GMT-4: Arabian Standard Time:001:Asia/Dubai: Arabic Standard Time:001:Asia/Baghdad: -Argentina Standard Time:001:America/Buenos_Aires: +Argentina Standard Time:001:America/Argentina/Buenos_Aires: Astrakhan Standard Time:001:Europe/Astrakhan: Atlantic Standard Time:BM:Atlantic/Bermuda: Atlantic Standard Time:GL:America/Thule: @@ -58,7 +58,7 @@ Central European Standard Time:MK:Europe/Skopje: Central European Standard Time:001:Europe/Warsaw: Central Pacific Standard Time:AQ:Antarctica/Casey: -Central Pacific Standard Time:FM:Pacific/Ponape: +Central Pacific Standard Time:FM:Pacific/Pohnpei: Central Pacific Standard Time:NC:Pacific/Noumea: Central Pacific Standard Time:VU:Pacific/Efate: Central Pacific Standard Time:ZZ:Etc/GMT-11: @@ -75,7 +75,7 @@ Dateline Standard Time:001:Etc/GMT+12: E. Africa Standard Time:AQ:Antarctica/Syowa: E. Africa Standard Time:DJ:Africa/Djibouti: -E. Africa Standard Time:ER:Africa/Asmera: +E. Africa Standard Time:ER:Africa/Asmara: E. Africa Standard Time:ET:Africa/Addis_Ababa: E. Africa Standard Time:KM:Indian/Comoro: E. Africa Standard Time:MG:Indian/Antananarivo: @@ -101,10 +101,10 @@ FLE Standard Time:FI:Europe/Helsinki: FLE Standard Time:LT:Europe/Vilnius: FLE Standard Time:LV:Europe/Riga: -FLE Standard Time:001:Europe/Kiev: +FLE Standard Time:001:Europe/Kyiv: Fiji Standard Time:001:Pacific/Fiji: GMT Standard Time:ES:Atlantic/Canary: -GMT Standard Time:FO:Atlantic/Faeroe: +GMT Standard Time:FO:Atlantic/Faroe: GMT Standard Time:GG:Europe/Guernsey: GMT Standard Time:IE:Europe/Dublin: GMT Standard Time:IM:Europe/Isle_of_Man: @@ -115,7 +115,7 @@ GTB Standard Time:GR:Europe/Athens: GTB Standard Time:001:Europe/Bucharest: Georgian Standard Time:001:Asia/Tbilisi: -Greenland Standard Time:001:America/Godthab: +Greenland Standard Time:001:America/Nuuk: Greenwich Standard Time:BF:Africa/Ouagadougou: Greenwich Standard Time:CI:Africa/Abidjan: Greenwich Standard Time:GH:Africa/Accra: @@ -136,7 +136,7 @@ Hawaiian Standard Time:PF:Pacific/Tahiti: Hawaiian Standard Time:ZZ:Etc/GMT+10: Hawaiian Standard Time:001:Pacific/Honolulu: -India Standard Time:001:Asia/Calcutta: +India Standard Time:001:Asia/Kolkata: Iran Standard Time:001:Asia/Tehran: Israel Standard Time:001:Asia/Jerusalem: Jordan Standard Time:001:Asia/Amman: @@ -161,10 +161,10 @@ Mountain Standard Time:001:America/Denver: Mountain Standard Time (Mexico):001:America/Mazatlan: Myanmar Standard Time:CC:Indian/Cocos: -Myanmar Standard Time:001:Asia/Rangoon: +Myanmar Standard Time:001:Asia/Yangon: N. Central Asia Standard Time:001:Asia/Novosibirsk: Namibia Standard Time:001:Africa/Windhoek: -Nepal Standard Time:001:Asia/Katmandu: +Nepal Standard Time:001:Asia/Kathmandu: New Zealand Standard Time:AQ:Antarctica/McMurdo: New Zealand Standard Time:001:Pacific/Auckland: Newfoundland Standard Time:001:America/St_Johns: @@ -196,7 +196,7 @@ SA Eastern Standard Time:ZZ:Etc/GMT+3: SA Eastern Standard Time:001:America/Cayenne: SA Pacific Standard Time:BR:America/Rio_Branco: -SA Pacific Standard Time:CA:America/Coral_Harbour: +SA Pacific Standard Time:CA:America/Atikokan: SA Pacific Standard Time:EC:America/Guayaquil: SA Pacific Standard Time:JM:America/Jamaica: SA Pacific Standard Time:KY:America/Cayman: @@ -236,7 +236,7 @@ SE Asia Standard Time:ID:Asia/Jakarta: SE Asia Standard Time:KH:Asia/Phnom_Penh: SE Asia Standard Time:LA:Asia/Vientiane: -SE Asia Standard Time:VN:Asia/Saigon: +SE Asia Standard Time:VN:Asia/Ho_Chi_Minh: SE Asia Standard Time:ZZ:Etc/GMT-7: SE Asia Standard Time:001:Asia/Bangkok: Saint Pierre Standard Time:001:America/Miquelon: @@ -279,7 +279,7 @@ Transbaikal Standard Time:001:Asia/Chita: Turkey Standard Time:001:Europe/Istanbul: Turks And Caicos Standard Time:001:America/Grand_Turk: -US Eastern Standard Time:001:America/Indianapolis: +US Eastern Standard Time:001:America/Indiana/Indianapolis: US Mountain Standard Time:CA:America/Creston: US Mountain Standard Time:MX:America/Hermosillo: US Mountain Standard Time:ZZ:Etc/GMT+7: @@ -292,7 +292,7 @@ UTC+12:UM:Pacific/Wake: UTC+12:WF:Pacific/Wallis: UTC+12:001:Etc/GMT-12: -UTC+13:KI:Pacific/Enderbury: +UTC+13:KI:Pacific/Kanton: UTC+13:TK:Pacific/Fakaofo: UTC+13:001:Etc/GMT-13: UTC-02:BR:America/Noronha: @@ -352,7 +352,7 @@ West Asia Standard Time:001:Asia/Tashkent: West Bank Standard Time:001:Asia/Hebron: West Pacific Standard Time:AQ:Antarctica/DumontDUrville: -West Pacific Standard Time:FM:Pacific/Truk: +West Pacific Standard Time:FM:Pacific/Chuuk: West Pacific Standard Time:GU:Pacific/Guam: West Pacific Standard Time:MP:Pacific/Saipan: West Pacific Standard Time:ZZ:Etc/GMT-10: ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29591/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29591&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377013 Stats: 28 lines in 3 files changed: 23 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29591/head:pull/29591 PR: https://git.openjdk.org/jdk/pull/29591

2 7

RFR: 8219203: Use StringBuilder instead of StringBuffer in com.sun.jndi.dns.ResourceRecord
by Jaikiran Pai 11 Feb '26

11 Feb '26

Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203. Given the nature of the change, no new tests have been introduced. ------------- Commit messages: - 8219203: Use Unsynchronized StringBuilder in com.sun.jndi.dns.ResourceRecord.java Changes: https://git.openjdk.org/jdk/pull/29652/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29652&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8219203 Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29652/head:pull/29652 PR: https://git.openjdk.org/jdk/pull/29652

6 7

RFR: 8376355: Update to use jtreg 8.2.1
by Christian Stein 11 Feb '26

11 Feb '26

Please review the change to update to using jtreg 8.2.1. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. ------------- Commit messages: - 8376355: Update to use jtreg 8.2.1 - 8376355: Update to use jtreg 8.2 Changes: https://git.openjdk.org/jdk/pull/29452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376355 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29452/head:pull/29452 PR: https://git.openjdk.org/jdk/pull/29452

4 4