January 2021 - core-libs-dev

RFR: 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk
by Adam Farley 18 Jan '21

18 Jan '21

Ensure make files look on the include path or in PHASE_MAKEDIRS for customizations. Change also adds a tidy-up that improves readability. ------------- Commit messages: - 8259942: Enable customizations in CompileJavaModules.gmk and Main.gmk Changes: https://git.openjdk.java.net/jdk/pull/2134/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2134&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259942 Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2134/head:pull/2134 PR: https://git.openjdk.java.net/jdk/pull/2134

1 0

JDK-8242959 residual cleanup: Move encoding checks into ZipCoder
by Eirik Bjørsnøs 16 Jan '21

16 Jan '21

Hi, The following is purely a code cleanup/refactoring proposal for ZipFile internals: ZipFile.Source.initCEN currently checks that each entry name is encoded using bytes valid in the entry's encoding: if (zc.isUTF8() || (flag & USE_UTF8) != 0) { checkUTF8(cen, pos + CENHDR, nlen); } else { checkEncoding(zc, cen, pos + CENHDR, nlen); } I find this unnecessarily complicated for a couple of reasons: 1: The if repeats flag checking logic which already exists in zipCoderForPos 2: checkUTF and checkEncoding are encoding-specific methods and as such would have a better home in ZipCoder As a cleanup, I propose that we move checkEncoding into ZipCoder and make checkUTF an override of checkEncoding in UTF8ZipCoder. Here's a patch which implements the proposal. Sponsors are welcome :-) diff --git a/src/java.base/share/classes/java/util/zip/ZipCoder.java b/src/java.base/share/classes/java/util/zip/ZipCoder.java index 13012aab0f6..cb1ab256891 100644 --- a/src/java.base/share/classes/java/util/zip/ZipCoder.java +++ b/src/java.base/share/classes/java/util/zip/ZipCoder.java @@ -54,6 +54,14 @@ class ZipCoder { return new ZipCoder(charset); } + void checkEncoding(byte[] a, int pos, int nlen) throws ZipException { + try { + toString(a, pos, nlen); + } catch(Exception e) { + throw new ZipException("invalid CEN header (bad entry name)"); + } + } + String toString(byte[] ba, int off, int length) { try { return decoder().decode(ByteBuffer.wrap(ba, off, length)).toString(); @@ -203,6 +211,25 @@ class ZipCoder { return true; } + @Override + void checkEncoding(byte[] a, int pos, int len) throws ZipException { + try { + int end = pos + len; + while (pos < end) { + // ASCII fast-path: When checking that a range of bytes is + // valid UTF-8, we can avoid some allocation by skipping + // past bytes in the 0-127 range + if (a[pos] < 0) { + ZipCoder.toStringUTF8(a, pos, end - pos); + break; + } + pos++; + } + } catch(Exception e) { + throw new ZipException("invalid CEN header (bad entry name)"); + } + } + @Override String toString(byte[] ba, int off, int length) { return JLA.newStringUTF8NoRepl(ba, off, length); diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java index 4c53855abfe..07edc06999b 100644 --- a/src/java.base/share/classes/java/util/zip/ZipFile.java +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java @@ -1309,31 +1309,6 @@ public class ZipFile implements ZipConstants, Closeable { } } - private static final void checkUTF8(byte[] a, int pos, int len) throws ZipException { - try { - int end = pos + len; - while (pos < end) { - // ASCII fast-path: When checking that a range of bytes is - // valid UTF-8, we can avoid some allocation by skipping - // past bytes in the 0-127 range - if (a[pos] < 0) { - ZipCoder.toStringUTF8(a, pos, end - pos); - break; - } - pos++; - } - } catch(Exception e) { - zerror("invalid CEN header (bad entry name)"); - } - } - - private final void checkEncoding(ZipCoder zc, byte[] a, int pos, int nlen) throws ZipException { - try { - zc.toString(a, pos, nlen); - } catch(Exception e) { - zerror("invalid CEN header (bad entry name)"); - } - } private static class End { int centot; // 4 bytes @@ -1520,13 +1495,10 @@ public class ZipFile implements ZipConstants, Closeable { zerror("invalid CEN header (bad compression method: " + method + ")"); if (entryPos + nlen > limit) zerror("invalid CEN header (bad header size)"); - if (zc.isUTF8() || (flag & USE_UTF8) != 0) { - checkUTF8(cen, pos + CENHDR, nlen); - } else { - checkEncoding(zc, cen, pos + CENHDR, nlen); - } + ZipCoder zcp = zipCoderForPos(pos); + zcp.checkEncoding(cen, pos + CENHDR, nlen); // Record the CEN offset and the name hash in our hash cell. - hash = zipCoderForPos(pos).normalizedHash(cen, entryPos, nlen); + hash = zcp.normalizedHash(cen, entryPos, nlen); hsh = (hash & 0x7fffffff) % tablelen; next = table[hsh]; table[hsh] = idx;

2 2

RFR: JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
by Andy Herrick 16 Jan '21

16 Jan '21

JDK-8258755: jpackage: Invalid 32-bit exe when building app-image ------------- Commit messages: - JDK-8258755: jpackage: Invalid 32-bit exe when building app-image - JDK-8258755: jpackage: Invalid 32-bit exe when building app-image - JDK-8258755: jpackage: Invalid 32-bit exe when building app-image Changes: https://git.openjdk.java.net/jdk/pull/2030/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2030&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258755 Stats: 14 lines in 3 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2030.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2030/head:pull/2030 PR: https://git.openjdk.java.net/jdk/pull/2030

4 13

RFR: JDK-8259062: Remove MacAppStoreBundler
by Andy Herrick 16 Jan '21

16 Jan '21

JDK-8259062: Remove MacAppStoreBundler ------------- Commit messages: - JDK-8259062: Remove MacAppStoreBundler - JDK-8259062: Remove MacAppStoreBundler Changes: https://git.openjdk.java.net/jdk/pull/1962/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1962&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259062 Stats: 265 lines in 2 files changed: 0 ins; 265 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1962.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1962/head:pull/1962 PR: https://git.openjdk.java.net/jdk/pull/1962

4 4

RFR: JDK-8259238: Clean up Log.java and remove usage of non-final static variables.
by Andy Herrick 16 Jan '21

16 Jan '21

JDK-8259238: Clean up Log.java and remove usage of non-final static variables. ------------- Commit messages: - JDK-8259238: Clean up Log.java and remove usage of non-final static variables. Changes: https://git.openjdk.java.net/jdk/pull/1977/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1977&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259238 Stats: 79 lines in 3 files changed: 12 ins; 49 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1977.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1977/head:pull/1977 PR: https://git.openjdk.java.net/jdk/pull/1977

4 4

Integrated: 8259048: (tz) Upgrade time-zone data to tzdata2020f
by Kiran Sidhartha Ravikumar 15 Jan '21

15 Jan '21

On Mon, 4 Jan 2021 18:11:05 GMT, Kiran Sidhartha Ravikumar <kravikumar(a)openjdk.org> wrote: > Hi Guys, > > Updating the summary as tzdata2020f is available and includes tzdata2020e changes also. > > Please review the integration of tzdata2020f to JDK. > > Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000064.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8259048 > > tzdata2020e - Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed. > tzdata2020f - No changes to the data since 2020e. > > Regression Tests pass along with JCK. > > Please let me know if the changes are good to push. > > Thanks, > Kiran This pull request has now been integrated. Changeset: fe84ecd5 Author: Kiran Sidhartha Ravikumar <kravikumar(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/fe84ecd5 Stats: 729 lines in 10 files changed: 578 ins; 19 del; 132 mod 8259048: (tz) Upgrade time-zone data to tzdata2020f Reviewed-by: naoto, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1937

1 0

RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll
by Сергей Цыпанов 15 Jan '21

15 Jan '21

Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here. Currently `Collections.addAll()` is implemented and documented as: /** * ... * The behavior of this convenience method is identical to that of * {@code c.addAll(Arrays.asList(elements))}, but this method is likely * to run significantly faster under most implementations. */ @SafeVarargs public static <T> boolean addAll(Collection<? super T> c, T... elements) { boolean result = false; for (T element : elements) result |= c.add(element); return result; } But it practice the notation `this method is likely to run significantly faster under most implementations` is completely wrong. When I take this [benchmark](https://github.com/stsypanov/benchmarks/blob/master/benchmark-ru… and run it on JDK 14 I get the following results: (collection) (size) Score Error Units addAll ArrayList 10 37.9 ± 1.9 ns/op addAll ArrayList 100 83.8 ± 3.4 ns/op addAll ArrayList 1000 678.2 ± 23.0 ns/op collectionsAddAll ArrayList 10 50.9 ± 1.1 ns/op collectionsAddAll ArrayList 100 751.4 ± 47.4 ns/op collectionsAddAll ArrayList 1000 8839.8 ± 710.7 ns/op addAll HashSet 10 128.4 ± 5.9 ns/op addAll HashSet 100 1864.2 ± 102.4 ns/op addAll HashSet 1000 16615.5 ± 1202.6 ns/op collectionsAddAll HashSet 10 172.8 ± 6.0 ns/op collectionsAddAll HashSet 100 2355.8 ± 195.4 ns/op collectionsAddAll HashSet 1000 20364.7 ± 1164.0 ns/op addAll ArrayDeque 10 54.0 ± 0.4 ns/op addAll ArrayDeque 100 319.7 ± 2.5 ns/op addAll ArrayDeque 1000 3176.9 ± 22.2 ns/op collectionsAddAll ArrayDeque 10 66.5 ± 1.4 ns/op collectionsAddAll ArrayDeque 100 808.1 ± 55.9 ns/op collectionsAddAll ArrayDeque 1000 5639.6 ± 240.9 ns/op addAll CopyOnWriteArrayList 10 18.0 ± 0.7 ns/op addAll CopyOnWriteArrayList 100 39.4 ± 1.7 ns/op addAll CopyOnWriteArrayList 1000 371.1 ± 17.0 ns/op collectionsAddAll CopyOnWriteArrayList 10 251.9 ± 18.4 ns/op collectionsAddAll CopyOnWriteArrayList 100 3405.9 ± 304.8 ns/op collectionsAddAll CopyOnWriteArrayList 1000 247496.8 ± 23502.3 ns/op addAll ConcurrentLinkedDeque 10 81.4 ± 2.8 ns/op addAll ConcurrentLinkedDeque 100 609.1 ± 26.4 ns/op addAll ConcurrentLinkedDeque 1000 4494.5 ± 219.3 ns/op collectionsAddAll ConcurrentLinkedDeque 10 189.8 ± 2.5 ns/op collectionsAddAll ConcurrentLinkedDeque 100 1660.0 ± 62.0 ns/op collectionsAddAll ConcurrentLinkedDeque 1000 17649.2 ± 300.9 ns/op addAll:·gc.alloc.rate.norm ArrayList 10 160.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm ArrayList 100 880.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm ArrayList 1000 8080.3 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ArrayList 10 80.0 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ArrayList 100 1400.2 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ArrayList 1000 15025.6 ± 0.1 B/op addAll:·gc.alloc.rate.norm HashSet 10 464.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm HashSet 100 5328.5 ± 0.0 B/op addAll:·gc.alloc.rate.norm HashSet 1000 48516.7 ± 0.1 B/op collectionsAddAll:·gc.alloc.rate.norm HashSet 10 464.0 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm HashSet 100 5328.5 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm HashSet 1000 48516.6 ± 0.1 B/op addAll:·gc.alloc.rate.norm ArrayDeque 10 112.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm ArrayDeque 100 560.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm ArrayDeque 1000 4160.5 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ArrayDeque 10 112.0 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ArrayDeque 100 1048.1 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ArrayDeque 1000 14929.4 ± 0.0 B/op addAll:·gc.alloc.rate.norm CopyOnWriteArrayList 10 88.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm CopyOnWriteArrayList 100 448.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm CopyOnWriteArrayList 1000 4048.1 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm CopyOnWriteArrayList 10 456.0 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm CopyOnWriteArrayList 100 22057.2 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm CopyOnWriteArrayList 1000 2020150.3 ± 7.3 B/op addAll:·gc.alloc.rate.norm ConcurrentLinkedDeque 10 312.0 ± 0.0 B/op addAll:·gc.alloc.rate.norm ConcurrentLinkedDeque 100 2472.1 ± 0.0 B/op addAll:·gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24073.7 ± 0.1 B/op collectionsAddAll:·gc.alloc.rate.norm ConcurrentLinkedDeque 10 288.0 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ConcurrentLinkedDeque 100 2448.3 ± 0.0 B/op collectionsAddAll:·gc.alloc.rate.norm ConcurrentLinkedDeque 1000 24051.4 ± 0.3 B/op There's never a case when `Collections.addAll` is fater - on the contrary `c.addAll(Arrays.asList())` always wins. Pay attention especially to dramatic difference for array-based collection. So I propose to reimplement the method by simply delegating to `Arrays.asList` because the spec declares identical behaviour and to remove perfomance notation from JavaDoc. ------------- Commit messages: - Collections:addAll: instead of one-by-one add elements in bulk Changes: https://git.openjdk.java.net/jdk/pull/1764/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1764&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193031 Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1764.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764 PR: https://git.openjdk.java.net/jdk/pull/1764

8 35

Re: RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f [v2]
by Kiran Sidhartha Ravikumar 15 Jan '21

15 Jan '21

> Hi Guys, > > Please review the integration of tzdata2020e to JDK. > > Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000063.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8258878 > > Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed. > > Regression Tests pass along with JCK. > > Please let me know if the changes are good to push. > > Thanks, > Kiran Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - 8258878: (tz) Upgrade time-zone data to tzdata2020e - Merge remote-tracking branch 'origin/master' into JDK-8258878 - 8258878: (tz) Upgrade time-zone data to tzdata2020e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1937/files - new: https://git.openjdk.java.net/jdk/pull/1937/files/a89ac891..4e18e930 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1937&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1937&range=00-01 Stats: 46333 lines in 1566 files changed: 19748 ins; 13335 del; 13250 mod Patch: https://git.openjdk.java.net/jdk/pull/1937.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1937/head:pull/1937 PR: https://git.openjdk.java.net/jdk/pull/1937

2 1

Monitoring wrapped ThreadPoolExecutor returned from Executors
by Tommy Ludwig 15 Jan '21

15 Jan '21

Hello, In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default. I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing? >From the JavaDocs, the intention of the wrapping is to prevent changing the ThreadPool configuration. Our use case does not call for changing the thread pool configuration - we want to observe the ExecutorService (e.g. thread pool state) via getter methods for monitoring purposes. Thanks, Tommy [1] https://github.com/micrometer-metrics/micrometer/blob/25f120833f8b73e4bd7cf…

5 6

Re: RFR: 8258878: (tz) Upgrade time-zone data to tzdata2020e
by Naoto Sato 15 Jan '21

15 Jan '21

On Mon, 4 Jan 2021 18:11:05 GMT, Kiran Sidhartha Ravikumar <kravikumar(a)openjdk.org> wrote: > Hi Guys, > > Please review the integration of tzdata2020e to JDK. > > Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-December/000063.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8258878 > > Most of the changes are about correcting past timestamps and Australia/Currie timezone is removed. > > Regression Tests pass along with JCK. > > Please let me know if the changes are good to push. > > Thanks, > Kiran Looks good. IIUC, 2020f is already out, and the 2020e-2020f diff does not seem to include any data change. Would you change this PR to incorporate 2020f? ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1937

2 1