January 2023 - 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

RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings
by Xin Liu 29 May '25

29 May '25

If AbstractStringBuilder only grow, the inflated value which is encoded in UTF16 can't be compressed. toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress. java.io.BufferedRead::readLine() is a case that StringBuilder grows only. ------------- Commit messages: - Add a microbenchmark. - 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings Changes: https://git.openjdk.java.net/jdk/pull/7671/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282429 Stats: 44 lines in 5 files changed: 37 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671

4 22

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

RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats
by Smita Kamath 09 Aug '24

09 Aug '24

8289552: Make intrinsic conversions between bit representations of half precision values and floats ------------- Commit messages: - Intrinsic conversions between halffloat and floats Changes: https://git.openjdk.org/jdk/pull/9781/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289552 Stats: 220 lines in 13 files changed: 212 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781

11 81

RFR: 8291966: SwitchBootstrap.typeSwitch could be faster
by Jan Lahoda 22 Jun '24

22 Jun '24

The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like: switch (obj) { case String s when s.isEmpty() -> {} case String s -> {} case CharSequence cs -> {} ... } this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case. The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this: obj == null ? -1 : switch (restartIndex) { case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ; case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ; case 2 -> obj instanceof CharSequence ? 2 : ... ; ... default -> <labels-count>; } This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results PatternsOptimizationTest.testLegacyIndyLongSwitch thrpt 25 1515989.562 ± 32047.918 ops/s PatternsOptimizationTest.testHandleIndyLongSwitch thrpt 25 2630707.585 ± 37202.210 ops/s PatternsOptimizationTest.testLegacyIndyShortSwitch thrpt 25 6789310.900 ± 61921.636 ops/s PatternsOptimizationTest.testHandleIndyShortSwitch thrpt 25 10771729.464 ± 69607.467 ops/s The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases. ------------- Commit messages: - 8291966: SwitchBootstrap.typeSwitch could be faster Changes: https://git.openjdk.org/jdk/pull/9779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291966 Stats: 74 lines in 1 file changed: 50 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9779.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9779/head:pull/9779 PR: https://git.openjdk.org/jdk/pull/9779

12 27

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: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE
by Brian Burkhalter 15 Dec '23

15 Dec '23

`java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. ------------- Commit messages: - 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE Changes: https://git.openjdk.org/jdk/pull/11403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297632 Stats: 23 lines in 1 file changed: 22 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403 PR: https://git.openjdk.org/jdk/pull/11403

6 31

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