September 2021 - core-libs-dev

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: 8272903: Missing license header in ArenaAllocator.java
by Maurizio Cimadamore 09 Sep '21

09 Sep '21

This small patch adds missing copyright header to a segment allocator implementation class. ------------- Commit messages: - Add missing copyright header Changes: https://git.openjdk.java.net/jdk/pull/5447/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5447&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272903 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5447.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5447/head:pull/5447 PR: https://git.openjdk.java.net/jdk/pull/5447

3 3

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

Patch for JDK-8273541
by Kartik Ohri 09 Sep '21

09 Sep '21

Hi all! I would like to work on a fix for JDK-8273541 <https://bugs.openjdk.java.net/browse/JDK-8273541>. I think the regression was introduced by the change here <https://github.com/openjdk/jdk/pull/2380/files#diff-d62f4055445b40f5d9862e0…>. It seems that this was accidentally changed from Thread.MAX_PRIORITY to Thread.MIN_PRIORITY. As Thread.MIN_PRIORITY - 2 is negative and because of the check here <https://github.com/openjdk/jdk/pull/2380/files#diff-9f140a5980d51de2a5f392a…>, the thread priority is not set. Changing this back to Thread.MAX_PRIORITY should fix the problem. I tried the patch <https://github.com/amCap1712/jdk/commit/b894bda67f9f4f8f48ba97679247a8218f6…> locally and it seems to fix the issue for me. If it is fine, I would like to submit this fix. Regards, Kartik

3 3

RFR: 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test
by Aleksey Shipilev 09 Sep '21

09 Sep '21

This test runs a lot of configurations, and spends a lot of time serially. This is especially pronounced when run in prospective tier4 runs (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can parallelize the test configurations for this test to make it hurt less. Also, timeouts need to be increased for `TestUpcall` test configs, because some of them are very slow in fastdebug mode. Sample run: $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=java/foreign/TestMatrix.java | ts -s 00:00:00 Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' 00:00:03 Test selection 'java/foreign/TestMatrix.java', will run: 00:00:03 * jtreg:test/jdk/java/foreign/TestMatrix.java 00:00:03 00:00:03 Running test 'jtreg:test/jdk/java/foreign/TestMatrix.java' 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFTT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FFFT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTTF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTTF 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFT 00:00:31 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTF 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFFF 00:00:32 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFF 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TFTT 00:00:35 Passed: java/foreign/TestMatrix.java#UpcallHighArity-TTFF 00:00:38 Passed: java/foreign/TestMatrix.java#UpcallHighArity-FTFT 00:01:50 Passed: java/foreign/TestMatrix.java#Downcall-FF 00:02:27 Passed: java/foreign/TestMatrix.java#Downcall-TF 00:03:03 Passed: java/foreign/TestMatrix.java#Downcall-FT 00:03:47 Passed: java/foreign/TestMatrix.java#Downcall-TT 00:04:17 Passed: java/foreign/TestMatrix.java#Upcall-FTFF 00:04:23 Passed: java/foreign/TestMatrix.java#Upcall-TFFF 00:05:46 Passed: java/foreign/TestMatrix.java#Upcall-TTFF 00:06:03 Passed: java/foreign/TestMatrix.java#Upcall-TFFT 00:06:44 Passed: java/foreign/TestMatrix.java#Upcall-FTFT 00:08:24 Passed: java/foreign/TestMatrix.java#Upcall-TFTF 00:08:39 Passed: java/foreign/TestMatrix.java#Upcall-TTFT 00:09:16 Passed: java/foreign/TestMatrix.java#Upcall-FTTF 00:09:19 Passed: java/foreign/TestMatrix.java#Upcall-TFTT 00:10:01 Passed: java/foreign/TestMatrix.java#Upcall-FTTT 00:10:37 Passed: java/foreign/TestMatrix.java#Upcall-TTTF 00:12:16 Passed: java/foreign/TestMatrix.java#Upcall-TTTT 00:12:17 Test results: passed: 32 00:12:21 00:12:21 ============================== 00:12:21 Test summary 00:12:21 ============================== 00:12:21 TEST TOTAL PASS FAIL ERROR 00:12:21 jtreg:test/jdk/java/foreign/TestMatrix.java 32 32 0 0 00:12:21 ============================== real 12m20.538s user 131m54.043s sys 0m59.944s If we don't parallelize, then those 130 minutes are spent serially. ------------- Commit messages: - Timeouts and cleanups - Parallelize Changes: https://git.openjdk.java.net/jdk/pull/5358/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5358&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273315 Stats: 238 lines in 1 file changed: 195 ins; 14 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/5358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5358/head:pull/5358 PR: https://git.openjdk.java.net/jdk/pull/5358

4 21

RFR: 8273487: Zero: Handle "zero" variant in runtime tests
by Aleksey Shipilev 09 Sep '21

09 Sep '21

JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like: $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java STDERR: java.lang.Error: TESTBUG: unsupported vm variant at jdk.test.lib.Platform.variant(Platform.java:368) at jdk.test.lib.Platform.jvmLibDir(Platform.java:357) at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585) at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) Additional testing: - [ ] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/5413/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5413&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273487 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5413.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5413/head:pull/5413 PR: https://git.openjdk.java.net/jdk/pull/5413

3 7

RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests
by Roger Riggs 08 Sep '21

08 Sep '21

The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync. This cleanup converts to use TestNG DataProviders and other improvements. ------------- Commit messages: - 8273242: Refactored ExecCommand to use TestNG DataProvider for cases Changes: https://git.openjdk.java.net/jdk/pull/5335/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5335&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273242 Stats: 270 lines in 1 file changed: 137 ins; 97 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/5335.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5335/head:pull/5335 PR: https://git.openjdk.java.net/jdk/pull/5335

3 7

RFR: 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods
by Brian Burkhalter 08 Sep '21

08 Sep '21

This request proposes to modify `java.io.FilterInputStream` to override `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and `transferTo(OutputStream)` in order to leverage any performance advantage that the wrapped stream might have over the `java.io.InputStream` implementations of these methods. ------------- Commit messages: - 8255878: FilterInputStream is missing implementations of Java 9 InputStream methods Changes: https://git.openjdk.java.net/jdk/pull/5367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255878 Stats: 41 lines in 1 file changed: 40 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5367/head:pull/5367 PR: https://git.openjdk.java.net/jdk/pull/5367

3 9

RFR: 8273450: Fix the copyright header of SVML files
by Sandhya Viswanathan 08 Sep '21

08 Sep '21

Fix the copyright header of SVML files to match others. This was brought up on jdk-dev mailing list: https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html ------------- Commit messages: - 8273450: Fix the copyright header of SVML file Changes: https://git.openjdk.java.net/jdk/pull/5399/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5399&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273450 Stats: 288 lines in 72 files changed: 144 ins; 0 del; 144 mod Patch: https://git.openjdk.java.net/jdk/pull/5399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5399/head:pull/5399 PR: https://git.openjdk.java.net/jdk/pull/5399

3 8

RFR: 8273329: Remove redundant null check from String.getBytes(String charsetName)
by Сергей Цыпанов 08 Sep '21

08 Sep '21

Current implementation looks like this: public byte[] getBytes(String charsetName) throws UnsupportedEncodingException { if (charsetName == null) throw new NullPointerException(); return encode(lookupCharset(charsetName), coder(), value); } Null check seems to be redundant here because the same check of `charsetName` is done within `String.lookupCharset(String)`: private static Charset lookupCharset(String csn) throws UnsupportedEncodingException { Objects.requireNonNull(csn); try { return Charset.forName(csn); } catch (UnsupportedCharsetException | IllegalCharsetNameException x) { throw new UnsupportedEncodingException(csn); } } ------------- Commit messages: - 8273329: Remove redundant null check from String.getBytes(String charsetName) Changes: https://git.openjdk.java.net/jdk/pull/5361/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5361&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273329 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5361.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5361/head:pull/5361 PR: https://git.openjdk.java.net/jdk/pull/5361

5 9