August 2021 - core-libs-dev

RFR: 8270057: Use Objects.checkFromToIndex for j.u.c.CopyOnWriteArrayList
by Yi Yang 14 Sep '21

14 Sep '21

After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. As Mandy suggested, I create this PR for changes involving JUC changes. ------------- Commit messages: - replace Changes: https://git.openjdk.java.net/jdk/pull/4723/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4723&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270057 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4723/head:pull/4723 PR: https://git.openjdk.java.net/jdk/pull/4723

3 2

Re: Proposal: JDK-8231640 - (prop) Canonical property storage
by Robert Scholte 09 Sep '21

09 Sep '21

I've dropped this topic on the Maven Dev mailinglist as well[1]. The responses are mixed, so I'd prefer to refer to the mailinglist instead of summarizing the responses here. This will prevent that those opinions are considered my opinions. Thanks, Robert [1] https://lists.apache.org/thread.html/r687bca66bb548d3a13ea665fb7202daf97105…

6 14

RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading
by Vladimir Ivanov 09 Sep '21

09 Sep '21

`MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any dependencies on new class loaders compared to the original `MethodHandle`. 2nd level is backed by a `SoftReference` and is used as a backup when the result of `MethodHandle.asType()` conversion can't populate the higher level cache. The fix is based on [the work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCache… made by Peter Levart @plevart back in 2015. Testing: tier1 - tier6 ------------- Commit messages: - Remove the assert - Introduce 2nd level MethodHandle.asType cache - keepsAlive logic Changes: https://git.openjdk.java.net/jdk/pull/5246/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5246&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8078641 Stats: 108 lines in 2 files changed: 87 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5246/head:pull/5246 PR: https://git.openjdk.java.net/jdk/pull/5246

5 20

RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform
by Masanori Yano 08 Sep '21

08 Sep '21

Hi all, Could you please review the 8269373 bug fixes? These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. ------------- Commit messages: - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Changes: https://git.openjdk.java.net/jdk/pull/4594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269373 Stats: 14 lines in 6 files changed: 5 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594

2 14

RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation
by Vladimir Ivanov 08 Sep '21

08 Sep '21

Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. Also, removed `Unsafe::shouldBeInitialized()` in `DMH::shouldBeInitialized(MemberName)` to save on calling into the VM. `Unsafe::ensureClassInitialized()` already has a fast-path check which checks whether the class is fully initialized or not. Testing: tier1 - tier6 ------------- Commit messages: - Remove WeakReference-based logic Changes: https://git.openjdk.java.net/jdk/pull/5258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5258&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273000 Stats: 35 lines in 1 file changed: 0 ins; 32 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5258/head:pull/5258 PR: https://git.openjdk.java.net/jdk/pull/5258

4 15

Possible ClassCastException in java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)
by Andrey Turbanov 04 Sep '21

04 Sep '21

Hello. I found suspicious code in the method "java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)" https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java… static CharPredicate union(CharPredicate... predicates) { CharPredicate cp = ch -> { for (CharPredicate p : predicates) { if (!p.is(ch)) return false; } return true; }; for (CharPredicate p : predicates) { if (! (p instanceof BmpCharPredicate)) return cp; } return (BmpCharPredicate)cp; } Variable `cp` has type CharPredicate initially. And then it's casted to BmpCharPredicate. This cast always fails with ClassCastException when reached. Can reproduced in small sample class: public static void main(String[] args) { CharPredicate result = BmpCharPredicate.union(); System.out.println(result); } interface CharPredicate { boolean is(int ch); } interface BmpCharPredicate extends CharPredicate { static CharPredicate union(CharPredicate... predicates) { CharPredicate cp = ch -> true; for (CharPredicate p : predicates) { if (! (p instanceof BmpCharPredicate)) return cp; } return (BmpCharPredicate)cp; } } Exception in thread "main" java.lang.ClassCastException: class org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 cannot be cast to class org.RegexpBug$BmpCharPredicate (org.RegexpBug$BmpCharPredicate$$Lambda$14/0x0000000800c028f0 and org.RegexpBug$BmpCharPredicate are in unnamed module of loader 'app') at org.RegexpBug$BmpCharPredicate.union(RegexpBug.java:20) at org.RegexpBug.main(RegexpBug.java:5) As I can see this method is never used. Perhaps it should be removed? Andrey Turbanov

3 2

RFR: 8214761: Bug in parallel Kahan summation implementation
by Ian Graves 03 Sep '21

03 Sep '21

8214761: Bug in parallel Kahan summation implementation ------------- Commit messages: - 8214761: Bug in parallel Kahan summation implementation Changes: https://git.openjdk.java.net/jdk/pull/4674/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4674&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8214761 Stats: 18 lines in 3 files changed: 11 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4674.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4674/head:pull/4674 PR: https://git.openjdk.java.net/jdk/pull/4674

4 11

RFR: 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible
by Сергей Цыпанов 02 Sep '21

02 Sep '21

Just a very tiny clean-up. There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access: public T[] getEnumConstants() { T[] values = getEnumConstantsShared(); return (values != null) ? values.clone() : null; } private transient volatile T[] enumConstants; T[] getEnumConstantsShared() { T[] constants = enumConstants; if (constants == null) { /* ... */ } return constants; } Calling values() method is slightly faster: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class EnumBenchmark { @Benchmark public Enum[] values() { return Enum.values(); } @Benchmark public Enum[] getEnumConstants() { return Enum.class.getEnumConstants(); } private enum Enum { A, B } } Benchmark Mode Cnt Score Error Units EnumBenchmark.getEnumConstants avgt 15 6,265 ± 0,051 ns/op EnumBenchmark.getEnumConstants:·gc.alloc.rate avgt 15 2434,075 ± 19,568 MB/sec EnumBenchmark.getEnumConstants:·gc.alloc.rate.norm avgt 15 24,002 ± 0,001 B/op EnumBenchmark.getEnumConstants:·gc.churn.G1_Eden_Space avgt 15 2433,709 ± 70,216 MB/sec EnumBenchmark.getEnumConstants:·gc.churn.G1_Eden_Space.norm avgt 15 23,998 ± 0,659 B/op EnumBenchmark.getEnumConstants:·gc.churn.G1_Survivor_Space avgt 15 0,009 ± 0,003 MB/sec EnumBenchmark.getEnumConstants:·gc.churn.G1_Survivor_Space.norm avgt 15 ≈ 10⁻⁴ B/op EnumBenchmark.getEnumConstants:·gc.count avgt 15 210,000 counts EnumBenchmark.getEnumConstants:·gc.time avgt 15 119,000 ms EnumBenchmark.values avgt 15 4,164 ± 0,134 ns/op EnumBenchmark.values:·gc.alloc.rate avgt 15 3665,341 ± 120,721 MB/sec EnumBenchmark.values:·gc.alloc.rate.norm avgt 15 24,002 ± 0,001 B/op EnumBenchmark.values:·gc.churn.G1_Eden_Space avgt 15 3660,512 ± 137,250 MB/sec EnumBenchmark.values:·gc.churn.G1_Eden_Space.norm avgt 15 23,972 ± 0,529 B/op EnumBenchmark.values:·gc.churn.G1_Survivor_Space avgt 15 0,017 ± 0,003 MB/sec EnumBenchmark.values:·gc.churn.G1_Survivor_Space.norm avgt 15 ≈ 10⁻⁴ B/op EnumBenchmark.values:·gc.count avgt 15 262,000 counts EnumBenchmark.values:·gc.time avgt 15 155,000 ms ------------- Commit messages: - 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Changes: https://git.openjdk.java.net/jdk/pull/5303/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5303&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273140 Stats: 13 lines in 4 files changed: 0 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5303/head:pull/5303 PR: https://git.openjdk.java.net/jdk/pull/5303

4 9

RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family
by Raffaello Giulietti 01 Sep '21

01 Sep '21

Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()` methods do `j.l.[Strict]Math`. Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this PR also corrects small typos in it and exercises tests that were already present but which were never invoked. Let me know if this is acceptable for a test or if there's a need of a separate issue in the JBS. ------------- Commit messages: - 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family Changes: https://git.openjdk.java.net/jdk/pull/5285/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5285&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271602 Stats: 871 lines in 3 files changed: 850 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5285.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5285/head:pull/5285 PR: https://git.openjdk.java.net/jdk/pull/5285

2 5

Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187
by Daniel D.Daugherty 01 Sep '21

01 Sep '21

Trivial fixes to reduce the noise in the JDK18 CI: JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187 JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to work on the issues introduced by JDK-8260265 UTF-8 by Default. ------------- Commit messages: - 8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 - 8273197: ProblemList 2 jtools tests due to JDK-8273187 Changes: https://git.openjdk.java.net/jdk/pull/5321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273197 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5321/head:pull/5321 PR: https://git.openjdk.java.net/jdk/pull/5321

2 3