April 2021 - core-libs-dev

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v3]
by Yi Yang 29 Apr '21

29 Apr '21

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove InlineNIOCheckIndex flag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/7f30dc48..db8b6ef4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01-02 Stats: 23 lines in 3 files changed: 11 ins; 11 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615

1 0

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v2]
by Yi Yang 29 Apr '21

29 Apr '21

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove java_nio_Buffer in javaClasses.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/a6affc54..7f30dc48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=00-01 Stats: 27 lines in 2 files changed: 0 ins; 27 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615

4 5

RFR: 8266173: -Wmaybe-uninitialized happens in jni_util.c
by Yasumasa Suenaga 29 Apr '21

29 Apr '21

We can see compiler warnings in jni_util.c as following on GCC 11. `buf` should be initialized. ------------- Commit messages: - 8266173: -Wmaybe-uninitialized happens in jni_util.c Changes: https://git.openjdk.java.net/jdk/pull/3742/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3742&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266173 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3742.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3742/head:pull/3742 PR: https://git.openjdk.java.net/jdk/pull/3742

2 2

RFR: JDK-8265773: incorrect jdeps message "jdk8internals" to describe a removed JDK internal API
by Mandy Chung 28 Apr '21

28 Apr '21

jdeps should print "JDK removed internal APIs" to give an informative description when a JDK internal API that is being referenced has been removed. JDK-8213909 incorrectly changed it to print `jdk8internals`. An example output is: classes -> jdk8internals p.Main -> sun.misc.Service JDK removed internal API p.Main -> sun.misc.SoftCache JDK removed internal API ------------- Commit messages: - JDK-8265773: jdeps message jdk8internals indicating a non-existent JDK API is incorrect Changes: https://git.openjdk.java.net/jdk/pull/3741/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3741&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265773 Stats: 75 lines in 3 files changed: 74 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3741.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3741/head:pull/3741 PR: https://git.openjdk.java.net/jdk/pull/3741

2 2

RFR: 8183374: Refactor java/lang/Runtime shell tests to java
by Fernando Guallini 28 Apr '21

28 Apr '21

Refactor the following shell tests to java: test/jdk/java/lang/RuntimeTests/shutdown/ShutdownHooks.sh test/jdk/java/lang/Runtime/exec/SetCwd.java In addition, the test SetCwd was running itself in separate java subprocesses in order to exercise Runtime.exec. It was creating a folder structure with multiple test class copies to distinguish between main and child processes to prevent an infinite recursion. That logic is simplified now, tests follow the testng annotations flow whereas the subprocesses entry point is a nested class main ------------- Commit messages: - Merge branch 'master' of github.com:openjdk/jdk into 8183374 - refactor ShutdownHooks and SetCwd Changes: https://git.openjdk.java.net/jdk/pull/3572/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3572&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8183374 Stats: 232 lines in 4 files changed: 67 ins; 121 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/3572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3572/head:pull/3572 PR: https://git.openjdk.java.net/jdk/pull/3572

2 3

Re: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64.
by gregcawthorne 28 Apr '21

28 Apr '21

On Wed, 28 Apr 2021 09:25:01 GMT, Andrew Haley <aph(a)openjdk.org> wrote: > Re monotonicity: all is not necessarily lost. There's a theorem due to Ferguson and Brightman which says that > > ``` > if > abs(f(m+) - f(m)) > eps < ----------------------- > abs(f(m+)) + abs(f(m))' > > for all m, the approximation is monotone. > > m is the machine number, m+ its successor > eps the maximum relative error of the approximation f(m) > ``` > > See > http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf, particularly the Appendix, which contains a table of expressions for the five basic transcendental functions. We can definitely be checked for single precision! I am uncertain how much water that would hold. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510

1 0

RFR: 8264806: Remove the experimental JIT compiler
by Vladimir Kozlov 27 Apr '21

27 Apr '21

As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: - `jdk.internal.vm.compiler` — the Graal compiler - `jdk.internal.vm.compiler.management` — Graal's `MBean` - `test/hotspot/jtreg/compiler/graalunit` — Graal's unit tests Remove Graal related code in makefiles. Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: src/jdk.internal.vm.compiler/share/classes/module-info.java src/jdk.internal.vm.compiler.management/share/classes/module-info.java @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. Tested hs-tier1-4 ------------- Depends on: https://git.openjdk.java.net/jdk/pull/3398 Commit messages: - 8264806: Remove the experimental JIT compiler Changes: https://git.openjdk.java.net/jdk/pull/3421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264806 Stats: 441620 lines in 2886 files changed: 0 ins; 441604 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421

4 25

ReversibleCollection proposal
by Henri Tremblay 27 Apr '21

27 Apr '21

Hi, Not sure if this will end up in the right mailing list thread but let's see. I just read quickly the proposal and it made me think about another common issue. I wonder if we could tackle it as well. I will call it the "find the first element when there is only one" problem. It happens on unordered collections like a HashSet. It forces to do Set<String> s = new HashSet<>(); if (s.size() == 1) { return s.iterator().next(); // or return s.stream().findFirst().get(); } Which is a lot of ugliness and object instantiation just to get the first element. I would be nice to have a public T findFirst() directly on Iterable<T>. With a default implementation returning iterator().next(). Things like ArrayList will want to override will return elementData[0]. It would return null when the list is empty. Or NoSuchElementException. It needs to be polished of course but will that be acceptable? Thanks, Henri

1 0

jpackage regression on Windows
by Sverre Moe 27 Apr '21

27 Apr '21

There was a regression introduced in JDK 15 of jpackage tool on Windows. The file permission of the built EXE has changed. The file is now ReadOnly. Both EXE and MSI was ReadWrite, now EXE is Read-Only while MSI is still Read-Write The EXE can no longer be signed because it cannot be modified. I just filed a bug report on this internal review ID : 9070046 /Sverre

1 1

RFR: 8264805: Remove the experimental Ahead-of-Time Compiler
by Vladimir Kozlov 27 Apr '21

27 Apr '21

As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: - `jdk.aot` module — the `jaotc` tool - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution - related HotSpot code guarded by `#if INCLUDE_AOT` Additionally, remove tests as well as code in makefiles related to AoT compilation. Tested hs-tier1-4 ------------- Commit messages: - 8264805: Remove the experimental Ahead-of-Time Compiler Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264805 Stats: 26903 lines in 375 files changed: 4 ins; 26703 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398

12 33