September 2021 - core-libs-dev

RFR: 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2
by kabutz 12 Sep '21

12 Sep '21

…of MAX_PRIORITY-2 during refactoring Appears in Java 17 for the first time. During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to instead state Thread.MIN_PRIORITY - 2, which results in a negative priority, and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by default now has threads with priority 5, instead of 8. The change was done in git revision # 992b50087d2ec8878dfcbbd1820a00b6b6bdf644 and label 8261036 by Claes Redestad ------------- Commit messages: - Merge branch 'openjdk:master' into thread_priority - Merge remote-tracking branch 'origin/thread_priority' into thread_priority - Merge branch 'openjdk:master' into thread_priority - Merge branch 'openjdk:master' into thread_priority - Merge branch 'openjdk:master' into thread_priority - Redo the change to MAX_PRIORITY - 2 - Removed stray "java" - Thread priority of Cleaner threads was set to MIN_PRIORITY-2 instead of MAX_PRIORITY-2 during refactoring Changes: https://git.openjdk.java.net/jdk/pull/5439/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5439&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273541 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5439.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5439/head:pull/5439 PR: https://git.openjdk.java.net/jdk/pull/5439

6 13

RFR: 8273595: tools/jpackage tests do not work on apt-based Linux Distros like Debian
by Ao Qi 10 Sep '21

10 Sep '21

A similar issue on Ubuntu has been fixed by [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, tools/jpackage tests do not work on Debian Linux or other apt-based Linux, when rpm package is installed. This issue proposes a general fix for apt-based Linux. ------------- Commit messages: - copyright year update and less import - 8273595: tools/jpackage tests do not work on apt-based Linux Distros like Debian Changes: https://git.openjdk.java.net/jdk/pull/5462/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5462&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273595 Stats: 20 lines in 2 files changed: 0 ins; 15 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5462.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5462/head:pull/5462 PR: https://git.openjdk.java.net/jdk/pull/5462

3 5

RFR: 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT
by Jovan Stevanovic 10 Sep '21

10 Sep '21

GraalVM Native Image supports loading classes at runtime if they are known during image build (class predefinition). This is achieved by the JVMTI agent that registers dynamically generated classes in a regular HotSpot run. The Native Image build uses these registered classes to embed them into the produced binary so they can be loaded at runtime. Loading at runtime is achieved by matching the unique hash of generated classes. If the generated bytecode is unstable across runs, the generated native image can not match the hash of the runtime-generated bytecode to the pre-defined classes. The execution failure happens here: https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.…. In XSLT the produced bytecode is unstable for the following reasons: - Methods like ` HashMap#values` and `HashMap#keySet` result in different traversal orders of its elements yielding a different order of methods and fields. - The default `Object#toString` includes the current memory reference of `com.sun.org.apache.xalan.internal.xsltc.compiler.Number` in the generated class. ------------- Commit messages: - 8273278: Improving XSLT support for GraalVM's Native Image. Changes: https://git.openjdk.java.net/jdk/pull/5331/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5331&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273278 Stats: 15 lines in 4 files changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5331/head:pull/5331 PR: https://git.openjdk.java.net/jdk/pull/5331

3 14

RFR: JDK-8273162 AbstractSplittableWithBrineGenerator does not create a random salt
by Jim Laskey 10 Sep '21

10 Sep '21

RandomSupport.AbstractSplittableWithBrineGenerator. makeSplitsSpliterator is intending to create a salt from a random long. The salt should have random letters of size 4 for each consecutive 4 bits and then the last 4 bits as ff, i.e. all bits set. However the loop is never executed, the random bits are not used and the salt is always the same. This condition is false on the first execution: long multiplier = (1L << SALT_SHIFT) - 1; long salt = multiplier << (64 - SALT_SHIFT); while ((salt & multiplier) != 0) { This can be corrected by changing: while ((salt & multiplier) != 0) { to while ((salt & multiplier) == 0) { ------------- Commit messages: - Correct the loop condition Changes: https://git.openjdk.java.net/jdk/pull/5449/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5449&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273162 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5449/head:pull/5449 PR: https://git.openjdk.java.net/jdk/pull/5449

3 3

RFR: JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns
by Mandy Chung 10 Sep '21

10 Sep '21

Improve the specification to document the cases when `Lookup::ensureInitialized` returns as specified JVMS 5.5 and matches the implementation. Please also review CSR: https://bugs.openjdk.java.net/browse/JDK-8273253 ------------- Commit messages: - JDK-8273194: Document the two possible cases when Lookup::ensureInitialized returns Changes: https://git.openjdk.java.net/jdk/pull/5343/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5343&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273194 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5343/head:pull/5343 PR: https://git.openjdk.java.net/jdk/pull/5343

2 5

RFR: 8273369: Computing micros between two instants unexpectedly overflows for some cases
by Naoto Sato 10 Sep '21

10 Sep '21

Please review the fix to the issue. Avoiding overflow by not calling nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in nano unit. ------------- Commit messages: - 8273369: Computing micros between two instants unexpectedly overflows for some cases Changes: https://git.openjdk.java.net/jdk/pull/5396/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5396&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273369 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5396/head:pull/5396 PR: https://git.openjdk.java.net/jdk/pull/5396

5 21

[jdk17] RFR: JDK-8273592: Backout JDK-8271868
by Andy Herrick 10 Sep '21

10 Sep '21

JDK-8271868 was pushed to JDK17 instead of jdk17u. This change is to back it out ------------- Commit messages: - JDK-8273592: Backout JDK-8271868 Changes: https://git.openjdk.java.net/jdk17/pull/307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273592 Stats: 65 lines in 9 files changed: 11 ins; 46 del; 8 mod Patch: https://git.openjdk.java.net/jdk17/pull/307.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/307/head:pull/307 PR: https://git.openjdk.java.net/jdk17/pull/307

3 3

[jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac
by Andy Herrick 10 Sep '21

10 Sep '21

backport from jdk-18 ------------- Commit messages: - JDK-8272639: jpackaged applications using microphone on mac Changes: https://git.openjdk.java.net/jdk17/pull/306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=306&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272639 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/306/head:pull/306 PR: https://git.openjdk.java.net/jdk17/pull/306

5 5

RFR: 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed"
by Naoto Sato 09 Sep '21

09 Sep '21

The gist of the issue is that the test case now always creates the boot classpath with non-ASCII chars appended, because the default encoding is fixed to UTF-8 with the fix to JDK-8260265. On macOS, javaagent tries to load the class with US-ASCII determined by nl_langinfo() (in unix/.../EncodingSupport_md.c). The file system encoding is always UTF-8 on mac, so no need to use the determined encoding by nl_langinfo(). On Linux, the "defaultEncoding" in Setup.java used to be US-ASCII in "C" locale (which matches the result from nl_langinfo()), so no non-ASCII suffix was appended to the `boot` path. But now the "defaultEncoding" is always UTF-8, the setup code appends the non-ASCII suffix, which fails to read in the native code using iconv with US-ASCII. The setup code should use the encoding from "sun.jnu.encoding" instead. Actually, the code there was copied from UnicodeTest.java which was modified with JDK-8260265, so the same fix needs to be applied. Tier5 run succeeds with one unrelated failure. Also, fixed some typos, e.g. "Uft8" -> "Utf8" ------------- Commit messages: - Merge branch 'master' into JDK-8273188 - 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Changes: https://git.openjdk.java.net/jdk/pull/5427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273188 Stats: 36 lines in 8 files changed: 5 ins; 16 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/5427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5427/head:pull/5427 PR: https://git.openjdk.java.net/jdk/pull/5427

3 6

[jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.
by Andy Herrick 09 Sep '21

09 Sep '21

This is a backport from JDK-18 ------------- Commit messages: - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Changes: https://git.openjdk.java.net/jdk17/pull/305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=305&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271868 Stats: 65 lines in 9 files changed: 46 ins; 11 del; 8 mod Patch: https://git.openjdk.java.net/jdk17/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/305/head:pull/305 PR: https://git.openjdk.java.net/jdk17/pull/305

2 2