December 2021 - core-libs-dev

RFR: 8277535: Remove redundant Stream.distinct()/sorted() steps
by Andrey Turbanov 20 Jan '22

20 Jan '22

1. Stream.distinct() is redundant before toSet() collector. Duplicates will be collapsed by Collector. 2. Stream.sorted() is redundant before toMap() collector. Keys will be shuffled by Collector (it's a HashMap in current implementation) ------------- Commit messages: - [PATCH] Remove redundant Stream.distinct()/sorted() steps Changes: https://git.openjdk.java.net/jdk/pull/5714/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277535 Stats: 4 lines in 3 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5714.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5714/head:pull/5714 PR: https://git.openjdk.java.net/jdk/pull/5714

3 3

RFR: 8274811: Remove superfluous use of boxing in java.base
by Andrey Turbanov 19 Jan '22

19 Jan '22

Usages of primitive types should be preferred and makes code easier to read. Similar cleanups: 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset ------------- Commit messages: - [PATCH] Remove superfluous use of boxing in java.base - [PATCH] Remove superfluous use of boxing in java.* modules - [PATCH] Remove superfluous use of boxing in java.* modules Changes: https://git.openjdk.java.net/jdk/pull/5481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274811 Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5481/head:pull/5481 PR: https://git.openjdk.java.net/jdk/pull/5481

7 8

RFR: 8272746: ZipFile can't open big file (NegativeArraySizeException)
by Masanori Yano 18 Jan '22

18 Jan '22

Could you please review the JDK-8272746 bug fixes? Since the array index is of type int, the overflow occurs when the value of end.cenlen is too large because of too many entries. It is necessary to read a part of the CEN from the file to fix the problem fundamentally, but the way will require an extensive fix and degrade performance. In practical terms, the size of the central directory rarely grows that large. So, I fixed it to check the size of the central directory and throw an exception if it is too large. ------------- Commit messages: - 8272746: ZipFile can't open big file (NegativeArraySizeException) Changes: https://git.openjdk.java.net/jdk/pull/6927/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6927&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272746 Stats: 80 lines in 2 files changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6927/head:pull/6927 PR: https://git.openjdk.java.net/jdk/pull/6927

3 16

RFR: 8278831: Use table lookup for the last two bytes in Integer.getChars
by Claes Redestad 17 Jan '22

17 Jan '22

During TemplatedStrings work Jim has noticed that we could probably profit from reusing the lookup tables also for the 1 or 2 leftmost bytes: // We know there are at most two digits left at this point. buf[--charPos] = DigitOnes[-i]; if (i < -9) { buf[--charPos] = DigitTens[-i]; } This avoids some arithmetic, and on average achieves a small speed-up since the lookup tables are likely cached are likely to be in cache. Small improvements on a few affected microbenchmarks, including the new Integers.toStringTiny, can be observed. Baseline: Benchmark (size) Mode Cnt Score Error Units Integers.toStringTiny 500 avgt 50 21.862 ± 0.211 us/op Patch: Benchmark (size) Mode Cnt Score Error Units Integers.toStringTiny 500 avgt 50 20.619 ± 0.330 us/op ------------- Commit messages: - 8278831: Use table lookup for the last two bytes in Integer.getChars Changes: https://git.openjdk.java.net/jdk/pull/6854/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6854&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278831 Stats: 42 lines in 4 files changed: 11 ins; 16 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/6854.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6854/head:pull/6854 PR: https://git.openjdk.java.net/jdk/pull/6854

3 3

RFR: JDK-8276939: Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException
by andrewluotechnologies 13 Jan '22

13 Jan '22

`AbstractLdapNamingEnumeration` `next` throws `NullPointerException` instead of `NoSuchElementException`, however the javadoc for `NamingEnumeration` says that next should throw `NoSuchElementException` when no elements are available (https://docs.oracle.com/en/java/javase/17/docs/api/java.naming/javax/naming…) The bug is basically that `next()` calls `hasMore()` -> `hasMoreImpl()` which calls `cleanup()` when there are no more elements. `cleanup()` sets `homeCtx = null;` which causes NullPointerException to be thrown on this line in `getNextBatch()`: `res = homeCtx.getSearchReply(enumClnt, res);` ------------- Commit messages: - JDK-8276939: Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException Changes: https://git.openjdk.java.net/jdk/pull/6095/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6095&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276939 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6095.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6095/head:pull/6095 PR: https://git.openjdk.java.net/jdk/pull/6095

2 1

RFR: 8277015: Use blessed modifier order in Panama code
by Magnus Ihse Bursie 13 Jan '22

13 Jan '22

I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. In this case, while the script did into the "correct" thing, it turns out that the method signatures in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room for improvement... The files contains method headers which look like this: final @Override @ForceInline long longToElementBits(... @ForceInline static long toIntegralChecked(... @ForceInline @Override final ByteVector dummyVector(... My personal opinion is that these should have been written like this: @Override @ForceInline final long longToElementBits(... @ForceInline static long toIntegralChecked(... @ForceInline @Override final ByteVector dummyVector(... or possibly @Override @ForceInline final long longToElementBits(... @ForceInline static long toIntegralChecked(... @ForceInline @Override final ByteVector dummyVector(... If you want me to make that change as well as part of the fix, let me know. Furthermore, I don't know how much the code in mainline differs from the code in the Panama branches. If the discrepancy is large, you might want to run `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and `bash bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches. ------------- Commit messages: - 8277015: Use blessed modifier order in Panama code Changes: https://git.openjdk.java.net/jdk/pull/6355/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277015 Stats: 21 lines in 13 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/6355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6355/head:pull/6355 PR: https://git.openjdk.java.net/jdk/pull/6355

6 20

RFR: 8278065: Refactor subclassAudits to use ClassValue
by Roman Kennke 12 Jan '22

12 Jan '22

As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey. Testing: - [ ] tier1 - [ ] tier2 - [ ] tier3 ------------- Depends on: https://git.openjdk.java.net/jdk/pull/6375 Commit messages: - 8278065: Refactor subclassAudits to use ClassValue Changes: https://git.openjdk.java.net/jdk/pull/6637/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6637&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278065 Stats: 105 lines in 3 files changed: 2 ins; 87 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/6637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6637/head:pull/6637 PR: https://git.openjdk.java.net/jdk/pull/6637

5 16

RFR: 8278518: String(byte[], int, int, Charset) constructor and String.translateEscapes() misses bounds check elimination
by Сергей Цыпанов 12 Jan '22

12 Jan '22

Originally this was spotted by by Amir Hadadi in https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimin… It looks like in the following code in `String(byte[], int, int, Charset)` while (offset < sl) { int b1 = bytes[offset]; if (b1 >= 0) { dst[dp++] = (byte)b1; offset++; // <--- continue; } if ((b1 == (byte)0xc2 || b1 == (byte)0xc3) && offset + 1 < sl) { int b2 = bytes[offset + 1]; if (!isNotContinuation(b2)) { dst[dp++] = (byte)decode2(b1, b2); offset += 2; continue; } } // anything not a latin1, including the repl // we have to go with the utf16 break; } bounds check elimination is not executed when accessing byte array via `bytes[offset]. The reason, I guess, is that offset variable is modified within the loop (marked with arrow). Possible fix for this could be changing: `while (offset < sl)` ---> `while (offset >= 0 && offset < sl)` However the best is to invest in C2 optimization to handle all such cases. The following benchmark demonstrates good improvement: @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class StringConstructorBenchmark { private byte[] array; private String str; @Setup public void setup() { str = "Quizdeltagerne spiste jordbær med fløde, mens cirkusklovnen. Я";//Latin1 ending with Russian array = str.getBytes(StandardCharsets.UTF_8); } @Benchmark public String newString() { return new String(array, 0, array.length, StandardCharsets.UTF_8); } @Benchmark public String translateEscapes() { return str.translateEscapes(); } } Results: //baseline Benchmark Mode Cnt Score Error Units StringConstructorBenchmark.newString avgt 50 173,092 ± 3,048 ns/op //patched Benchmark Mode Cnt Score Error Units StringConstructorBenchmark.newString avgt 50 126,908 ± 2,355 ns/op The same is observed in String.translateEscapes() for the same String as in the benchmark above: //baseline Benchmark Mode Cnt Score Error Units StringConstructorBenchmark.translateEscapes avgt 100 53,627 ± 0,850 ns/op //patched Benchmark Mode Cnt Score Error Units StringConstructorBenchmark.translateEscapes avgt 100 48,087 ± 1,129 ns/op Also I've looked into this with `LinuxPerfAsmProfiler`, full output for baseline is available here https://gist.github.com/stsypanov/d2524f98477d633fb1d4a2510fedeea6 and for patched code here https://gist.github.com/stsypanov/16c787e4f9fa3dd122522f16331b68b7. Here's the part of baseline assembly responsible for `while` loop: 3.62% ││ │ 0x00007fed70eb4c1c: mov %ebx,%ecx 2.29% ││ │ 0x00007fed70eb4c1e: mov %edx,%r9d 2.22% ││ │ 0x00007fed70eb4c21: mov (%rsp),%r8 ;*iload_2 {reexecute=0 rethrow=0 return_oop=0} ││ │ ; - java.lang.String::<init>@107 (line 537) 2.32% ↘│ │ 0x00007fed70eb4c25: cmp %r13d,%ecx │ │ 0x00007fed70eb4c28: jge 0x00007fed70eb5388 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} │ │ ; - java.lang.String::<init>@110 (line 537) 3.05% │ │ 0x00007fed70eb4c2e: cmp 0x8(%rsp),%ecx │ │ 0x00007fed70eb4c32: jae 0x00007fed70eb5319 2.38% │ │ 0x00007fed70eb4c38: mov %r8,(%rsp) 2.64% │ │ 0x00007fed70eb4c3c: movslq %ecx,%r8 2.46% │ │ 0x00007fed70eb4c3f: mov %rax,%rbx 3.44% │ │ 0x00007fed70eb4c42: sub %r8,%rbx 2.62% │ │ 0x00007fed70eb4c45: add $0x1,%rbx 2.64% │ │ 0x00007fed70eb4c49: and $0xfffffffffffffffe,%rbx 2.30% │ │ 0x00007fed70eb4c4d: mov %ebx,%r8d 3.08% │ │ 0x00007fed70eb4c50: add %ecx,%r8d 2.55% │ │ 0x00007fed70eb4c53: movslq %r8d,%r8 2.45% │ │ 0x00007fed70eb4c56: add $0xfffffffffffffffe,%r8 2.13% │ │ 0x00007fed70eb4c5a: cmp (%rsp),%r8 │ │ 0x00007fed70eb4c5e: jae 0x00007fed70eb5319 3.36% │ │ 0x00007fed70eb4c64: mov %ecx,%edi ;*aload_1 {reexecute=0 rethrow=0 return_oop=0} │ │ ; - java.lang.String::<init>@113 (line 538) 2.86% │ ↗│ 0x00007fed70eb4c66: movsbl 0x10(%r14,%rdi,1),%r8d ;*baload {reexecute=0 rethrow=0 return_oop=0} │ ││ ; - java.lang.String::<init>@115 (line 538) 2.48% │ ││ 0x00007fed70eb4c6c: mov %r9d,%edx 2.26% │ ││ 0x00007fed70eb4c6f: inc %edx ;*iinc {reexecute=0 rethrow=0 return_oop=0} │ ││ ; - java.lang.String::<init>@127 (line 540) 3.28% │ ││ 0x00007fed70eb4c71: mov %edi,%ebx 2.44% │ ││ 0x00007fed70eb4c73: inc %ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} │ ││ ; - java.lang.String::<init>@134 (line 541) 2.35% │ ││ 0x00007fed70eb4c75: test %r8d,%r8d ╰ ││ 0x00007fed70eb4c78: jge 0x00007fed70eb4c04 ;*iflt {reexecute=0 rethrow=0 return_oop=0} ││ ; - java.lang.String::<init>@120 (line 539) and this one is for patched code: 17.28% ││ 0x00007f6b88eb6061: mov %edx,%r10d ;*iload_2 {reexecute=0 rethrow=0 return_oop=0} ││ ; - java.lang.String::<init>@107 (line 537) 0.11% ↘│ 0x00007f6b88eb6064: test %r10d,%r10d │ 0x00007f6b88eb6067: jl 0x00007f6b88eb669c ;*iflt {reexecute=0 rethrow=0 return_oop=0} │ ; - java.lang.String::<init>@108 (line 537) 0.39% │ 0x00007f6b88eb606d: cmp %r13d,%r10d │ 0x00007f6b88eb6070: jge 0x00007f6b88eb66d0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} │ ; - java.lang.String::<init>@114 (line 537) 0.66% │ 0x00007f6b88eb6076: mov %ebx,%r9d 13.70% │ 0x00007f6b88eb6079: cmp 0x8(%rsp),%r10d 0.01% │ 0x00007f6b88eb607e: jae 0x00007f6b88eb6671 0.14% │ 0x00007f6b88eb6084: movsbl 0x10(%r14,%r10,1),%edi ;*baload {reexecute=0 rethrow=0 return_oop=0} │ ; - java.lang.String::<init>@119 (line 538) 0.37% │ 0x00007f6b88eb608a: mov %r9d,%ebx 0.99% │ 0x00007f6b88eb608d: inc %ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} │ ; - java.lang.String::<init>@131 (line 540) 12.88% │ 0x00007f6b88eb608f: movslq %r9d,%rsi ;*bastore {reexecute=0 rethrow=0 return_oop=0} │ ; - java.lang.String::<init>@196 (line 548) 0.17% │ 0x00007f6b88eb6092: mov %r10d,%edx 0.39% │ 0x00007f6b88eb6095: inc %edx ;*iinc {reexecute=0 rethrow=0 return_oop=0} │ ; - java.lang.String::<init>@138 (line 541) 0.96% │ 0x00007f6b88eb6097: test %edi,%edi 0.02% │ 0x00007f6b88eb6099: jl 0x00007f6b88eb60dc ;*iflt {reexecute=0 rethrow=0 return_oop=0} Between instructions mapped to `if_icmpge` and `aload_1` in baseline we have bounds check which is missing from patched code. ------------- Commit messages: - 8278518: String(byte[], int, int, Charset) constructor misses bounds check elimination Changes: https://git.openjdk.java.net/jdk/pull/6812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278518 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6812/head:pull/6812 PR: https://git.openjdk.java.net/jdk/pull/6812

6 14

RFR: 8276694: Pattern trailing unescaped backslash causes internal error
by Masanori Yano 11 Jan '22

11 Jan '22

Could you please review the 8276694 bug fixes? A message specific for this exception should be printed instead of an internal error. This fix adds a new check to output an appropriate exception message when the regular expression ends with an unescaped backslash. This fix also checks the position of the cursor to rule out other syntax errors at the middle position of the regular expression. ------------- Commit messages: - 8276694: Pattern trailing unescaped backslash causes internal error Changes: https://git.openjdk.java.net/jdk/pull/6891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6891&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276694 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6891/head:pull/6891 PR: https://git.openjdk.java.net/jdk/pull/6891

3 4

RFR: 8277013: Allow creation of module graphs without defining modules to the VM
by Ivan Ristović 08 Jan '22

08 Jan '22

Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013 The GraalVM Native Image module support must create the runtime boot-module layer at image build time; module instances created at build time need to reflect module relations at runtime, i.e., their opens, reads, and exports. To achieve this, we had to duplicate and modify a significant portion of the module synthesis methods from the JDK. The GraalVM PR that demonstrates this duplication can be found at: https://github.com/oracle/graal/blob/9bfa3a312d7d0309eb014d52e49afd7136d9e77e/substratevm/src/com.oracle.svm.hosted.jdk11/src/com/oracle/svm/hosted/ModuleLayerFeature.java#L269 The hard-to-maintain code duplication is necessary as synthesizing module graphs in the JDK unconditionally defines modules to the VM which causes an error due to module redefinition. For example, methods `System.defineModule`, `ModuleLayer` factories and constructor, and `Module` constructor unconditionally update the VM state. All these methods eventually reach the `Module` constructor or the `Modules.defineModules` method. We propose that the `Module` constructor and the `Modules.defineModules` conditionally update the VM state (similarly to 'Module.implAddReads`). The JDK would call these methods so they update the VM state and GraalVM Native Image would call them without updating the state. ------------- Commit messages: - Update parameter names; Add constructor overload for backward compatibility - Enhance Module.defineModules to accept switches to update VM state Changes: https://git.openjdk.java.net/jdk/pull/6356/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6356&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277013 Stats: 52 lines in 1 file changed: 36 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/6356.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6356/head:pull/6356 PR: https://git.openjdk.java.net/jdk/pull/6356

3 3