December 2021 - core-libs-dev

RFR: 8173970: jar tool should have a way to extract to a directory
by Jaikiran Pai 13 Nov '25

13 Nov '25

Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). The commit also includes a jtreg testcase which verifies the usage of this new option. ------------- Commit messages: - 8173970: jar tool should have a way to extract to a directory Changes: https://git.openjdk.java.net/jdk/pull/2752/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173970 Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752

13 61

Re: RFR: 8266013: Unexpected replacement character handling on stateful CharsetEncoder [v2]
by Ichiroh Takiguchi 27 May '25

27 May '25

> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data. > Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset. > EBCDIC Mix charset encoder is stateful encoder. > Shift code should be added by switching character set. > On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F" > SI is not in right place. > > Also ISO2022 related charsets use escape sequence to switch character set. > But same kind of issue is there. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: 8266013: Unexpected replacement character handling on stateful CharsetEncoder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3719/files - new: https://git.openjdk.java.net/jdk/pull/3719/files/d6a0a41b..33107e67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3719&range=00-01 Stats: 59 lines in 2 files changed: 40 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3719/head:pull/3719 PR: https://git.openjdk.java.net/jdk/pull/3719

3 3

Method references in annotations
by Julian Ruppel 04 Apr '24

04 Apr '24

Hi, being aware that there has been a discussion quite some time ago ( http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003768.html) I wanted to come up again with this topic as this feature would be beneficial especially for framework developers who wants to appoint behaviour to annotations. The following snippet shows what I want to vote for. @MyAnnotation(method = MyClass::myMethod)private String myVariable; This would be far more type-safe compared to using string literals to find the method via reflection. - Julian

2 2

RFR: 8200559: Java agents doing instrumentation need a means to define auxilary classes
by Rafael Winterhalter 30 Jan '24

30 Jan '24

To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`. ------------- Commit messages: - 8200559: Java agents doing instrumentation need a means to define auxiliary classes Changes: https://git.openjdk.java.net/jdk/pull/3546/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3546&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8200559 Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3546.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3546/head:pull/3546 PR: https://git.openjdk.java.net/jdk/pull/3546

16 50

RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
by iaroslavski 02 Jan '24

02 Jan '24

Sorting: - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) - fix tryMergeRuns() to better handle case when the last run is a single element - minor javadoc and comment changes Testing: - add new data inputs in tests for sorting - add min/max/infinity values to float/double testing - add tests for radix sort ------------- Commit messages: - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Changes: https://git.openjdk.java.net/jdk/pull/3938/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266431 Stats: 889 lines in 3 files changed: 718 ins; 46 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938

17 100

RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
by Scott Gibbons 08 Dec '23

08 Dec '23

Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. Benchmark Name | Base Score | Optimized Score | Gain -- | -- | -- | -- testBase64Decode size 1 | 15.36 | 15.32 | 1.00 testBase64Decode size 3 | 17.00 | 16.72 | 1.02 testBase64Decode size 7 | 20.60 | 18.82 | 1.09 testBase64Decode size 32 | 34.21 | 26.77 | 1.28 testBase64Decode size 64 | 54.43 | 38.35 | 1.42 testBase64Decode size 80 | 66.40 | 48.34 | 1.37 testBase64Decode size 96 | 73.16 | 52.90 | 1.38 testBase64Decode size 112 | 84.93 | 51.82 | 1.64 testBase64Decode size 512 | 288.81 | 32.04 | 9.01 testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 ------------- Commit messages: - Merge remote-tracking branch 'origin/base64_length_restrict' into base64_decode - Condition decode intrinsic within generator instead of outside to allow non-AVX acceleration - Adding MIME to signature. - Adding MIME to signature. - Adding MIME to signature. - Initialize vector before loop - Initialize vector before loop - Wrong register lengths. - Wrong register lengths. - writing in wrong order - ... and 418 more: https://git.openjdk.java.net/jdk/compare/48dc72b7...e527557a Changes: https://git.openjdk.java.net/jdk/pull/4368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268276 Stats: 743 lines in 10 files changed: 736 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368

8 30

RFR: 8263135: unique_ptr should not be used for types that are not pointers
by Yasumasa Suenaga 25 Aug '23

25 Aug '23

I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale): c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' から '_Ty' に変換できません。 with [ _Other=nullptr ] and [ _Ty=unsigned long ] c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ネイティブの nullptr はブールに変換するか、または reinterpret_cast を使用して整数型に変換することのみが可能です c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: コンパイル対象の関数テンプレートインスタンス化 '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' のリファレンスを確認してください with [ _Ty=unsigned long, _Ty2=unsigned long, _Other=nullptr ] c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: クラステンプレートメンバー関数 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' のコンパイル中 d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: コンパイル対象の関数テンプレートインスタンス化 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' のリファレンスを確認してください d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: コンパイル対象のクラステンプレートインスタンス化 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' のリファレンスを確認してください `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type. I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`). ------------- Commit messages: - 8263135: unique_ptr should not be used for types that are not pointers Changes: https://git.openjdk.java.net/jdk/pull/2858/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2858&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263135 Stats: 77 lines in 4 files changed: 14 ins; 36 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/2858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2858/head:pull/2858 PR: https://git.openjdk.java.net/jdk/pull/2858

5 8

Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
by Fei Yang 02 Aug '23

02 Aug '23

> Contributed-by: ard.biesheuvel(a)linaro.org, dongbo4(a)huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/… > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. > > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/d32c8ad7..b43f9197 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=09-10 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207

4 5

RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo
by Markus KARG 31 Oct '22

31 Oct '22

This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. I encourage everybody to discuss this draft: * Are there valid arguments for *not* doing this change? * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? * How to go on from here: What is missing to get this ready for an actual review? ------------- Commit messages: - Draft: Correctly positioning channel in case of exception - Draft: Corrected try-catch block - Draft: Moving I/O ops into the for statement block - Draft: Replaced custom bounds check by Objects.checkFromIndexSize() - Draft: Replaced casting by pattern matching for instanceof - Draft: Replacing var by actual type - Draft: Hiding ChannelOutputStream from the API - Draft: Removing final everywhere but kept only for constants - Draft: Using Thread-Local Buffer Cache - Draft: Increased DEFAULT_BUFFER_SIZE - ... and 1 more: https://git.openjdk.java.net/jdk/compare/66274320...ed49098a Changes: https://git.openjdk.java.net/jdk/pull/4263/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265891 Stats: 286 lines in 4 files changed: 205 ins; 76 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263 PR: https://git.openjdk.java.net/jdk/pull/4263

10 79

RFR: 8279283 - (ch) BufferedInputStream should override transferTo
by Markus KARG 01 Oct '22

01 Oct '22

Implementation of JDK-8279283 ------------- Commit messages: - BufferedInputStream::transferTo Changes: https://git.openjdk.java.net/jdk/pull/6935/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6935&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279283 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6935.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6935/head:pull/6935 PR: https://git.openjdk.java.net/jdk/pull/6935

11 89