August 2021 - core-libs-dev

RFR: 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable
by Сергей Цыпанов 13 Aug '21

13 Aug '21

The code in `Integer.decode()` and `Long.decode()` might allocate two instances of Integer/Long for the negative values less than -127: Integer result; result = Integer.valueOf(nm.substring(index), radix); result = negative ? Integer.valueOf(-result.intValue()) : result; To avoid this we can declare 'result' as `int` and use `Integer.parseInt()` method. Same applicable for `Long` and some other classes. ------------- Commit messages: - Merge branch 'master' into 8267844 - 8267844: Replace Integer/Long.valueOf() with Integer/Long.parse*() where applicable Changes: https://git.openjdk.java.net/jdk/pull/5068/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5068&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267844 Stats: 12 lines in 4 files changed: 0 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5068.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5068/head:pull/5068 PR: https://git.openjdk.java.net/jdk/pull/5068

3 10

RFR: 8271732: Regression in StringBuilder.charAt bounds checking
by Claes Redestad 12 Aug '21

12 Aug '21

In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to avoid potentially getting two bounds checks in the UTF-16 case. Problem is this optimization cause a regression since `StringUTF16.charAt(..)` checks `index` against the length of the `value` array and not `count`. A correct fix that still maintain the possible performance advantage reported by #4738 is to reinstate the `checkIndex(value, count)` and call `StringUTF16.getChar` instead of `charAt`. ------------- Commit messages: - 8271732: Regression in StringBuilder.charAt bounds checking Changes: https://git.openjdk.java.net/jdk/pull/5086/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5086&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271732 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5086/head:pull/5086 PR: https://git.openjdk.java.net/jdk/pull/5086

3 8

RFR: 8272120: Avoid looking for standard encodings in "java." modules
by Sergey Bylokhov 12 Aug '21

12 Aug '21

This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once. In many places standard charsets are looked up via their names, for example: absolutePath.getBytes("UTF-8"); This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets: absolutePath.getBytes(StandardCharsets.UTF_8); The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant. tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS. ------------- Commit messages: - Initial fix of JDK-8272120 Changes: https://git.openjdk.java.net/jdk/pull/5063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272120 Stats: 127 lines in 15 files changed: 24 ins; 53 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/5063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5063/head:pull/5063 PR: https://git.openjdk.java.net/jdk/pull/5063

5 10

RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment
by Alexey Semenyuk 11 Aug '21

11 Aug '21

Added jtreg test to verify jpackage launcher adds app dir to `java.library.path` system property. Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. Moved test/jdk/tools/jpackage/apps/image/Hello.java to test/jdk/tools/jpackage/apps/Hello.java. ------------- Commit messages: - dummy commit - Whitespace clean up - 8271170: Add unit test for what jpackage app launcher puts in the environment Changes: https://git.openjdk.java.net/jdk/pull/5056/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5056&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271170 Stats: 342 lines in 7 files changed: 212 ins; 116 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/5056.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5056/head:pull/5056 PR: https://git.openjdk.java.net/jdk/pull/5056

3 7

RFR: 8272328: java.library.path is not set properly by Windows jpackage app launcher
by Alexey Semenyuk 11 Aug '21

11 Aug '21

Restart window app launcher to make changes made to `PATH` env variable visible to JLI code in https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_window… ------------- Commit messages: - 8272328: java.library.path is not set properly by Windows jpackage app launcher Changes: https://git.openjdk.java.net/jdk/pull/5090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5090&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272328 Stats: 75 lines in 4 files changed: 63 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5090/head:pull/5090 PR: https://git.openjdk.java.net/jdk/pull/5090

3 3

RFR: 8271862: C2 intrinsic for Reference.refersTo() is often not used
by Per Liden 11 Aug '21

11 Aug '21

While fixing JDK-8270626 it was discovered that the C2 intrinsic for `Reference.refersTo()` is not used as often as one would think. Instead C2 often prefers using the native implementation, which is much slower which defeats the purpose of having an intrinsic in the first place. The problem arise from having `refersTo0()` be virtual, native and @IntrinsicCandidate. This can be worked around by introducing an virtual method layer and so that `refersTo0()` can be made `final`. That's what this patch does, by adding a virtual `refersToImpl()` which in turn calls the now final `refersTo0()`. It should be noted that `Object.clone()` and `Object.hashCode()` are also virtual, native and @IntrinsicCandidate and these methods get special treatment by C2 to get the intrinsic generated more optimally. We might want to do a similar optimization for `Reference.refersTo0()`. In that case, it is suggested that such an improvement could come later and be handled as a separate enhancement, and @kimbarrett has already filed JDK-8272140 to track that. Testing: I found this hard to test without instrumenting Hotspot to tell me that the intrinsic was called instead of the native method. So, for that reason testing was ad-hoc, using an instrumented Hotspot in combination with the test (`vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java`) that initially uncovered the problem. See JDK-8270626 for additional information. ------------- Commit messages: - 8271862: C2 intrinsic for Reference.refersTo() is often not used Changes: https://git.openjdk.java.net/jdk/pull/5052/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5052&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271862 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5052.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5052/head:pull/5052 PR: https://git.openjdk.java.net/jdk/pull/5052

4 9

RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix)
by Thomas Stuefe 11 Aug '21

11 Aug '21

We should not leak the handle to the jimage file (lib/modules) to childs. JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as well. Note that this only poses a problem when a child process is spawned off not via `Runtime.exec` but via another route since the spawnhelper closes all file descriptors. --- test: manually verified that lib/modules now has the FD_CLOEXEC flag set. ------------- Commit messages: - open image file with O_CLOEXEC Changes: https://git.openjdk.java.net/jdk/pull/4991/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4991&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271858 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4991/head:pull/4991 PR: https://git.openjdk.java.net/jdk/pull/4991

2 7

RFR: 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic
by Raffaello Giulietti 10 Aug '21

10 Aug '21

Hello, please review this tiny change in the implementation of j.l.Math.floorMod(int, int). While the results are unaffected, all of floorDiv(int, int) floorDiv(long, long) floorMod(long, long) use x ^ y in the tests to correct the result if needed. Not only is the proposed change more consistent with the other methods, but it might benefit later stages in the cpu to proceed with the evaluation of x ^ y in parallel with the previous x % y and, depending of the outcome, even further down. Greetings Raffaello ------------- Commit messages: - 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic Changes: https://git.openjdk.java.net/jdk/pull/4962/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4962&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271601 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4962.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4962/head:pull/4962 PR: https://git.openjdk.java.net/jdk/pull/4962

2 2

RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
by Andrey Turbanov 10 Aug '21

10 Aug '21

I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type. This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`. ------------- Commit messages: - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying Changes: https://git.openjdk.java.net/jdk/pull/4487/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4487&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269130 Stats: 70 lines in 8 files changed: 0 ins; 54 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/4487.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4487/head:pull/4487 PR: https://git.openjdk.java.net/jdk/pull/4487

6 12

RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups
by Matthias Baesken 10 Aug '21

10 Aug '21

Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding if (!cg_infos[PIDS_IDX]._data_complete) { log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); // keep the other controller info, pids is optional } ------------- Commit messages: - JDK-8266490 Changes: https://git.openjdk.java.net/jdk/pull/4518/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266490 Stats: 203 lines in 16 files changed: 159 ins; 2 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518 PR: https://git.openjdk.java.net/jdk/pull/4518

3 33