October 2021 - core-libs-dev

RFR: 8275163: Deflater::deflate methods omit javadoc for ReadOnlyBufferException
by Lance Andersen 15 Oct '21

15 Oct '21

Hi all, Please review the fix to address a javadoc issue for the Deflater::deflate methods that were added as part of JDK-6341887 that could throw a ReadOnlyBufferException. The` @throws ` clause for `ReadOnlyBufferException` was inadvertently omitted from the javadoc for these new methods. A CSR, JDK-8275164, has also been created for this issue. Best Lance ------------- Commit messages: - Add missing @throws for ReadOnlyBufferException Changes: https://git.openjdk.java.net/jdk/pull/5931/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5931&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275163 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5931.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5931/head:pull/5931 PR: https://git.openjdk.java.net/jdk/pull/5931

4 6

RFR: 8275145: file.encoding system property has an incorrect value on Windows
by Naoto Sato 15 Oct '21

15 Oct '21

Fixing a regression in which `file.encoding` was initialized by `sprops->encoding` instead of `sprops->sun_jnu_encoding` on non macOS platforms. tier1-3 tests passed on all platforms. ------------- Commit messages: - 8275145: file.encoding system property has an incorrect value on Windows Changes: https://git.openjdk.java.net/jdk/pull/5953/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5953&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275145 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5953/head:pull/5953 PR: https://git.openjdk.java.net/jdk/pull/5953

6 7

RFR: JDK-8275249: Suppress warnings on non-serializable array component types in jdk.jlink
by Joe Darcy 15 Oct '21

15 Oct '21

After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. >From "Java Object Serialization Specification: 2 - Object Output Classes": "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." The jdk.jlink module has one instance of this coding pattern that needs suppression to compile successfully under the future warning. ------------- Commit messages: - JDK-8275249: Suppress warnings on non-serializable array component types in jdk.jlink Changes: https://git.openjdk.java.net/jdk/pull/5936/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5936&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275249 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5936.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5936/head:pull/5936 PR: https://git.openjdk.java.net/jdk/pull/5936

2 2

RFR: 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream
by Joe Darcy 15 Oct '21

15 Oct '21

The java.io.ObjectInputStream and java.io.ObjectOuputStream classes are part of the serialization feature. These classes contain brief descriptions of some of the methods serializable classes can define to interact with the serialization mechanism, readObject, readObjectNoData, and writeObject. These descriptions are not entirely consistent with one another and at least one is arguably misleading. This PR makes the brief discussion the same in both classes and addresses the misleading point: the throws clauses of the methods will not effect whether or not the methods are found by serialization, but throwing unchecked exceptions not declared in the standard signatures is ill-advised. (The current implementation looks up the methods by name using core reflection; the method modifiers are checked to match but the throws information is not.) Please also review the corresponding CSR : https://bugs.openjdk.java.net/browse/JDK-8275014 ------------- Commit messages: - 8275013: Improve discussion of serialization method declarations in java.io.Object{Input, Output}Stream Changes: https://git.openjdk.java.net/jdk/pull/5883/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5883&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275013 Stats: 18 lines in 2 files changed: 13 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5883.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5883/head:pull/5883 PR: https://git.openjdk.java.net/jdk/pull/5883

3 5

Optimization (?) of HashSet(Collection)
by Сергей Цыпанов 15 Oct '21

15 Oct '21

Hello, in the code of HashSet(Collection) we have an optimization opportunity: public HashSet(Collection<? extends E> c) { map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16)); addAll(c); } instead of using addAll() inherited from j.u.Collection we can use c.forEach(this::add): public HashSet(Collection<? extends E> c) { map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16)); c.forEach(this::add); } This allows to rid Iterator and use counting loops for e.g. ArrayList instead of hasNext()/next(). To me the most common use cases of HashSet(Collection) are those: - ArrayList/Arrays.asList() is passed to convert List->Set or/and excluded duplicates - HashSet is passed to have a copy of original Set We are also likely to benefit from this change in case the argument collection is synchronized as it's going to be locked only once. I've used the benchmark [1] to analyze the impact and it demonstrates measurable improvement [2]. What puzzles we a bit is the result for j.u.ArrayList. At warm-up time it demonstrates better results than at measurement time: length = 10 # Run progress: 4,44% complete, ETA 00:21:41 # Fork: 3 of 5 # Warmup Iteration 1: 134,699 ns/op # Warmup Iteration 2: 115,391 ns/op # Warmup Iteration 3: 130,110 ns/op # Warmup Iteration 4: 114,465 ns/op <---- # Warmup Iteration 5: 114,849 ns/op # Warmup Iteration 6: 115,073 ns/op # Warmup Iteration 7: 113,988 ns/op # Warmup Iteration 8: 115,301 ns/op # Warmup Iteration 9: 115,452 ns/op # Warmup Iteration 10: 124,493 ns/op <---- Iteration 1: 123,776 ns/op Iteration 2: 123,719 ns/op Iteration 3: 123,725 ns/op Iteration 4: 126,892 ns/op Iteration 5: 125,493 ns/op Iteration 6: 124,661 ns/op Iteration 7: 123,783 ns/op Iteration 8: 123,975 ns/op Iteration 9: 124,047 ns/op Iteration 10: 123,899 ns/op length = 100 # Run progress: 11,11% complete, ETA 00:20:10 # Fork: 1 of 5 # Warmup Iteration 1: 1236,695 ns/op # Warmup Iteration 2: 1069,909 ns/op # Warmup Iteration 3: 1243,852 ns/op # Warmup Iteration 4: 1059,038 ns/op <---- # Warmup Iteration 5: 1057,670 ns/op # Warmup Iteration 6: 1057,117 ns/op # Warmup Iteration 7: 1056,932 ns/op # Warmup Iteration 8: 1054,909 ns/op # Warmup Iteration 9: 1058,106 ns/op # Warmup Iteration 10: 1145,699 ns/op <---- Iteration 1: 1139,155 ns/op Iteration 2: 1141,662 ns/op Iteration 3: 1139,061 ns/op Iteration 4: 1139,306 ns/op Iteration 5: 1138,475 ns/op Iteration 6: 1140,491 ns/op Iteration 7: 1144,017 ns/op Iteration 8: 1139,411 ns/op Iteration 9: 1142,729 ns/op Iteration 10: 1144,042 ns/op Here I use 1 s warm-up iteration on 2s measurement iteration. It looks like at iteration 4 the code is top-optimized, and later at the end of warm-up a kind of deoptimization happens. There's still visible improvement however. The benchmark is run with 5 forks, and this deoptimization is visible for length = {10, 100}. So my two question are: - What is the reason of the deoptimization and can we do something about it? - Whether suggested changes is worth implementations? Regards, Sergey Tsypanov 1. @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class HashSetBenchmark { @Benchmark public HashSet<Integer> fromArrayList(Data data) { return new HashSet<>(data.arrayList); } @Benchmark public HashSet<Integer> fromHashSet(Data data) { return new HashSet<>(data.hashSet); } @Benchmark public HashSet<Integer> fromArraysAsList(Data data) { return new HashSet<>(data.arraysAsList); } @State(Scope.Thread) public static class Data { private ArrayList<Integer> arrayList; private HashSet<Integer> hashSet; private List<Integer> arraysAsList; @Param({"10", "100", "1000"}) private int length; @Setup public void setup() throws IOException { var array = new Integer[length]; for (int i = 0; i < length; i++) { array[i] = i; } arraysAsList = Arrays.asList(array); arrayList = new ArrayList<>(arraysAsList); hashSet = new HashSet<>(arraysAsList); } } } 2. baseline Benchmark (length) Mode Cnt Score Error Units HashSetBenchmark.fromArrayList 10 avgt 50 127,838 ± 1,822 ns/op HashSetBenchmark.fromArrayList 100 avgt 50 1209,543 ± 8,435 ns/op HashSetBenchmark.fromArrayList 1000 avgt 50 11915,334 ± 155,908 ns/op HashSetBenchmark.fromArraysAsList 10 avgt 50 130,049 ± 1,661 ns/op HashSetBenchmark.fromArraysAsList 100 avgt 50 1138,407 ± 19,998 ns/op HashSetBenchmark.fromArraysAsList 1000 avgt 50 11345,099 ± 83,086 ns/op HashSetBenchmark.fromHashSet 10 avgt 50 184,559 ± 1,387 ns/op HashSetBenchmark.fromHashSet 100 avgt 50 2001,577 ± 42,321 ns/op HashSetBenchmark.fromHashSet 1000 avgt 50 17535,017 ± 199,892 ns/op patched Benchmark (length) Mode Cnt Score Error Units HashSetBenchmark.fromArrayList 10 avgt 50 125,075 ± 0,907 ns/op HashSetBenchmark.fromArrayList 100 avgt 50 1127,378 ± 19,368 ns/op HashSetBenchmark.fromArrayList 1000 avgt 50 11455,172 ± 61,543 ns/op HashSetBenchmark.fromArraysAsList 10 avgt 50 117,634 ± 3,641 ns/op HashSetBenchmark.fromArraysAsList 100 avgt 50 1034,538 ± 11,958 ns/op HashSetBenchmark.fromArraysAsList 1000 avgt 50 10786,914 ± 137,330 ns/op HashSetBenchmark.fromHashSet 10 avgt 50 173,727 ± 2,177 ns/op HashSetBenchmark.fromHashSet 100 avgt 50 1748,858 ± 12,535 ns/op HashSetBenchmark.fromHashSet 1000 avgt 50 16474,208 ± 97,578 ns/op

2 1

RFR: 8272163: Add -version option to keytool and jarsigner
by Hai-May Chao 14 Oct '21

14 Oct '21

It'd be useful to have a -version option for keytool and jarsigner. Many other JDK tools already have a -version option. This is to add -version option to keytool and jarsigner like jar command does. ------------- Commit messages: - 8272163: Add -version option to keytool and jarsigner Changes: https://git.openjdk.java.net/jdk/pull/5954/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5954&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272163 Stats: 117 lines in 6 files changed: 116 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5954/head:pull/5954 PR: https://git.openjdk.java.net/jdk/pull/5954

1 0

RFR: 8275262: Backout JDK-8269559
by Nick Gasson 14 Oct '21

14 Oct '21

This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE" which caused some unknown failures in Oracle's CI. ------------- Commit messages: - 8275262: Backout JDK-8269559 Changes: https://git.openjdk.java.net/jdk/pull/5941/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5941&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275262 Stats: 517 lines in 11 files changed: 1 ins; 421 del; 95 mod Patch: https://git.openjdk.java.net/jdk/pull/5941.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5941/head:pull/5941 PR: https://git.openjdk.java.net/jdk/pull/5941

5 11

RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE
by TatWai Chong 14 Oct '21

14 Oct '21

This patch implements string_compare intrinsic in SVE. It supports all LL, LU, UL and UU comparisons. As we haven't found an existing benchmark to measure performance impact, we created a benchmark derived from the test [1] for this evaluation. This benchmark is attached to this patch. Besides, remove the unused temporary register `vtmp3` from the existing match rules for StrCmp. The result below shows all varients can be benefited largely. Command: make exploded-test TEST="micro:StringCompareToDifferentLength" Benchmark (size) Mode Cnt Score Speedup Units compareToLL 24 avgt 10 1.0x ms/op compareToLL 36 avgt 10 1.0x ms/op compareToLL 72 avgt 10 1.0x ms/op compareToLL 128 avgt 10 1.4x ms/op compareToLL 256 avgt 10 1.8x ms/op compareToLL 512 avgt 10 2.7x ms/op compareToLU 24 avgt 10 1.6x ms/op compareToLU 36 avgt 10 1.8x ms/op compareToLU 72 avgt 10 2.3x ms/op compareToLU 128 avgt 10 3.8x ms/op compareToLU 256 avgt 10 4.7x ms/op compareToLU 512 avgt 10 6.3x ms/op compareToUL 24 avgt 10 1.6x ms/op compareToUL 36 avgt 10 1.7x ms/op compareToUL 72 avgt 10 2.2x ms/op compareToUL 128 avgt 10 3.3x ms/op compareToUL 256 avgt 10 4.4x ms/op compareToUL 512 avgt 10 6.1x ms/op compareToUU 24 avgt 10 1.0x ms/op compareToUU 36 avgt 10 1.0x ms/op compareToUU 72 avgt 10 1.4x ms/op compareToUU 128 avgt 10 2.2x ms/op compareToUU 256 avgt 10 2.6x ms/op compareToUU 512 avgt 10 3.7x ms/op [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intr… ------------- Commit messages: - 8269559: AArch64: Implement string_compare intrinsic in SVE Changes: https://git.openjdk.java.net/jdk/pull/5129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269559 Stats: 550 lines in 12 files changed: 447 ins; 12 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129

5 12

RFR: JDK-8275187: Suppress warnings on non-serializable array component types in java.sql.rowset
by Joe Darcy 13 Oct '21

13 Oct '21

After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. >From "Java Object Serialization Specification: 2 - Object Output Classes": "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." The java.sql.rowset module has several instances of this coding pattern that need suppression to compile successfully under the future warning. ------------- Commit messages: - JDK-8275187: Suppress warnings on non-serializable array component types in java.sql.rowset Changes: https://git.openjdk.java.net/jdk/pull/5925/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5925&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275187 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5925/head:pull/5925 PR: https://git.openjdk.java.net/jdk/pull/5925

2 2

RFR: 8273682: Upgrade Jline to 3.20.0
by Jan Lahoda 13 Oct '21

13 Oct '21

I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed. Thanks! ------------- Commit messages: - Removing trailing whitespace. - Fixing tests. - Fixing Windows build. - Upgrading JLine to 3.20.0 Changes: https://git.openjdk.java.net/jdk/pull/5655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273682 Stats: 2667 lines in 47 files changed: 1830 ins; 473 del; 364 mod Patch: https://git.openjdk.java.net/jdk/pull/5655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5655/head:pull/5655 PR: https://git.openjdk.java.net/jdk/pull/5655

2 3