June 2021 - core-libs-dev

RFR: 8264896: Remove redundant '& 0xFF' from int-to-byte cast
by Сергей Цыпанов 03 Jun '21

03 Jun '21

When we do byte b1 = (byte) (value & 0xFF); we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below: public class Main { public static void main(String[] args) throws Exception { IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> { byte b1 = (byte) (value & 0xFF); byte b2 = (byte) value; if (b1 != b2) { throw new RuntimeException("" + value); } }); } Also tier1 and tier2 are both OK. ------------- Commit messages: - Merge branch 'master' into bitwise - Remove redundant '& 0xFF' from int-to-byte cast Changes: https://git.openjdk.java.net/jdk/pull/2826/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2826&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264896 Stats: 50 lines in 14 files changed: 0 ins; 0 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/2826.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2826/head:pull/2826 PR: https://git.openjdk.java.net/jdk/pull/2826

5 4

RFR: 8268131: 2 java/foreign tests timed out
by Maurizio Cimadamore 03 Jun '21

03 Jun '21

This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. ------------- Commit messages: - * Increase timeout for TestUpcall/Downcall Changes: https://git.openjdk.java.net/jdk/pull/4321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268131 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4321/head:pull/4321 PR: https://git.openjdk.java.net/jdk/pull/4321

3 6

RFR: 8268077: java.util.List missing from Collections Framework Overview
by Raffaello Giulietti 03 Jun '21

03 Jun '21

Trivial changes to this non-normative document. ------------- Commit messages: - 8268077: java.util.List missing from Collections Framework Overview Changes: https://git.openjdk.java.net/jdk/pull/4289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4289&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268077 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4289/head:pull/4289 PR: https://git.openjdk.java.net/jdk/pull/4289

2 2

RFR: 8266317: Vector API enhancements
by Paul Sandoz 03 Jun '21

03 Jun '21

This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414) in preparation for when targeted. Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons. Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array. The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR. ------------- Commit messages: - Minor clarifications to the specification. - 8266317: Vector API enhancements Changes: https://git.openjdk.java.net/jdk/pull/3803/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266317 Stats: 10002 lines in 121 files changed: 9070 ins; 190 del; 742 mod Patch: https://git.openjdk.java.net/jdk/pull/3803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3803/head:pull/3803 PR: https://git.openjdk.java.net/jdk/pull/3803

3 10

Some questions about String interning for primitives
by dfranken.jdk＠gmail.com 03 Jun '21

03 Jun '21

Dear readers, Apologies in advance if these questions have been asked and discussed before or if they are on the wrong mailing list, maybe they are more suited for project Valhalla, I'm not sure. I was wondering if it would be possible / feasible to intern primitive values and byte arrays and use these interned values instead of creating a new object for each conversion. Currently, the following code prints 'false' as s1 and s2 are references to different objects: String s1 = Integer.toString(1); s1 = s1.intern(); // Makes no difference whether intern is called String s2 = Integer.toString(1); System.out.println(s1 == s2); I know that there is an integer cache for boxing / unboxing commonly used integers (for numbers ranging from -128 to 127), how about a String cache for commonly converted primitives? We could use the same ranges initially. I.e. when I use Integer.toString(1) I don't really care if I get a newly allocated String, I only care that I get back a String which equals "1" and it's okay if that is a reference to an interned value. Likewise with the mirrored variants such as String.valueOf(..). I was also wondering how byte conversions could work with such a cache. Currently, the only way for me to go from bytes to a String is with new String(bytes, charset) which guarantees creation of a new String object each time. Well, what if the bytes often contain the same value? Would it be useful to be able to do: String s1 = String.valueOf(bytes, UTF_8); String s2 = String.valueOf(bytes, UTF_8); // <-- returns the same refrence as s1 Kind regards, Dave Franken

2 1

RFR: JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6
by Jonathan Gibbons 03 Jun '21

03 Jun '21

Please review a small test fix, to include hamcrest.jar, as required by the latest version of JUnit in jtreg 6. ------------- Commit messages: - JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 Changes: https://git.openjdk.java.net/jdk/pull/4328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268150 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4328/head:pull/4328 PR: https://git.openjdk.java.net/jdk/pull/4328

3 3

RFR: JDK-8266254: Update to use jtreg 6
by Jonathan Gibbons 03 Jun '21

03 Jun '21

Please review the change to update to using jtreg 6. The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. ------------- Commit messages: - JDK-8266254: Update to use jtreg 6 Changes: https://git.openjdk.java.net/jdk/pull/4315/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266254 Stats: 17 lines in 11 files changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/4315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4315/head:pull/4315 PR: https://git.openjdk.java.net/jdk/pull/4315

9 11

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v11]
by Yi Yang 03 Jun '21

03 Jun '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 with a new target base due to a merge or a rebase. The pull request now contains eight commits: - x86_32 fails - build failed - cmp clobbers its left argument on x86_32 - better check1-4 - AssertionError when expected exception was not thrown - remove InlineNIOCheckIndex flag - remove java_nio_Buffer in javaClasses.hpp - consolidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/3615/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=10 Stats: 338 lines in 11 files changed: 242 ins; 78 del; 18 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

2 1

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6]
by Yi Yang 03 Jun '21

03 Jun '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: better check1-4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/1a96be7e..954abc6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04-05 Stats: 32 lines in 1 file changed: 31 ins; 0 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

4 10

RFR: 8267969: Add vectorized implementation for VectorMask.eq()
by Xiaohong Gong 03 Jun '21

03 Jun '21

Currently `"VectorMask.eq()" `is not vectorized: public VectorMask<E> eq(VectorMask<E> m) { // FIXME: Generate good code here. return bOp(m, (i, a, b) -> a == b); } This can be implemented by calling `"xor(m.not())"` directly. The performance improved about 1.4x ~ 1.9x for the following benchmark with different basic types: @Benchmark public Object eq() { boolean[] ma = fm.apply(size); boolean[] mb = fmb.apply(size); boolean[] mt = fmt.apply(size); VectorMask<Byte> m = VectorMask.fromArray(SPECIES, mt, 0); for (int ic = 0; ic < INVOC_COUNT; ic++) { for (int i = 0; i < ma.length; i += SPECIES.length()) { var av = SPECIES.loadMask(ma, i); var bv = SPECIES.loadMask(mb, i); // accumulate results, so JIT can't eliminate relevant computations m = m.and(av.eq(bv)); } } return m; } ------------- Commit messages: - 8267969: Add vectorized implementation for VectorMask.eq() Changes: https://git.openjdk.java.net/jdk/pull/4272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4272&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267969 Stats: 254 lines in 32 files changed: 248 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4272/head:pull/4272 PR: https://git.openjdk.java.net/jdk/pull/4272

3 6