February 2021 - core-libs-dev

RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets
by Michael McMahon 12 Feb '21

12 Feb '21

Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. Thanks, Michael ------------- Commit messages: - update - update - update - update - update after Alan's first review - Merge branch 'master' into 8252971-socket-attributes - test update - initial fix for review Changes: https://git.openjdk.java.net/jdk/pull/2424/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252971 Stats: 241 lines in 8 files changed: 226 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424

3 26

Withdrawn: 8231436: Fix the applicability of a no-@Target annotation type
by Liam Miller-Cushon 11 Feb '21

11 Feb '21

On Thu, 28 Jan 2021 22:33:53 GMT, Liam Miller-Cushon <cushon(a)openjdk.org> wrote: > Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2303

1 0

RFR: 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java
by Daniel D.Daugherty 11 Feb '21

11 Feb '21

A trivial fix to ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java in order to reduce noise in the JDK17 CI. ------------- Commit messages: - 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java Changes: https://git.openjdk.java.net/jdk/pull/2531/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2531&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261604 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2531/head:pull/2531 PR: https://git.openjdk.java.net/jdk/pull/2531

2 3

RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks
by Aleksey Shipilev 11 Feb '21

11 Feb '21

After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." int initJvmlLauncherData(JvmlLauncherData* ptr) const { // Store path to JLI library just behind JvmlLauncherData header. char* curPtr = reinterpret_cast<char*>(ptr + 1); do { const size_t count = sizeof(char) * (jliLibPath.size() + 1 /* trailing zero */); if (ptr) { std::memcpy(curPtr, jliLibPath.c_str(), count); ptr->jliLibPath = curPtr; } curPtr += count; } while (false); // <---- here There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. Additional testing: - [x] Linux x86_64 (Ubuntu) tools/jpackage ------------- Commit messages: - Replace with {} Changes: https://git.openjdk.java.net/jdk/pull/2454/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261300 Stats: 22 lines in 1 file changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/2454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2454/head:pull/2454 PR: https://git.openjdk.java.net/jdk/pull/2454

4 10

RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets
by Claes Redestad 11 Feb '21

11 Feb '21

This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. Testing: tier1-3, manual runs of sun.nio.cs tests ------------- Commit messages: - Minor cleanup - Reduce decoder creation overheads for sun.nio.cs.ext Charsets Changes: https://git.openjdk.java.net/jdk/pull/2480/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2480&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261418 Stats: 761 lines in 15 files changed: 258 ins; 411 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/2480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2480/head:pull/2480 PR: https://git.openjdk.java.net/jdk/pull/2480

2 12

Integrated: 8261449: Micro-optimize JVM_LatestUserDefinedLoader
by Aleksey Shipilev 11 Feb '21

11 Feb '21

On Tue, 9 Feb 2021 15:40:03 GMT, Aleksey Shipilev <shade(a)openjdk.org> wrote: > `JVM_LatestUserDefinedLoader` is called normally from `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it takes a measurable time to walk the stack. There is JDK-8173368 that wants to replace it with `StackWalker`, but we can tune up the `JVM_LatestUserDefinedLoader` itself without changing the semantics of it (thus providing the backportability, including the releases that do not have `StackWalker`) and improving performance (thus providing a more aggressive baseline for `StackWalker` rewrite). > > The key is to recognize that out of two checks: 1) checking for two special subclasses; 2) checking for user classloader -- the first one usually passes, and second one fails much more frequently. First check also requires traversing the superclasses upwards looking for match. Reversing the order of the checks, plus inlining the helper method improves performance without changing the semantics. > > Out of curiosity, my previous patch dropped the first check completely, replacing it by asserts, and we definitely run into situation where that check is needed on some tests. > > On my machine, `VM.latestUserDefinedLoader` invocation time drops from 115 to 100 ns/op. Single-threaded SPECjvm2008:serial improves about 3% with this patch. > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug, `tier1`, `tier2`, `tier3` > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485` > `$ git checkout pull/2485` This pull request has now been integrated. Changeset: 49cf13d2 Author: Aleksey Shipilev <shade(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/49cf13d2 Stats: 20 lines in 3 files changed: 4 ins; 13 del; 3 mod 8261449: Micro-optimize JVM_LatestUserDefinedLoader Reviewed-by: dholmes, stuefe, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2485

1 0

Re: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader [v2]
by Aleksey Shipilev 11 Feb '21

11 Feb '21

> `JVM_LatestUserDefinedLoader` is called normally from `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it takes a measurable time to walk the stack. There is JDK-8173368 that wants to replace it with `StackWalker`, but we can tune up the `JVM_LatestUserDefinedLoader` itself without changing the semantics of it (thus providing the backportability, including the releases that do not have `StackWalker`) and improving performance (thus providing a more aggressive baseline for `StackWalker` rewrite). > > The key is to recognize that out of two checks: 1) checking for two special subclasses; 2) checking for user classloader -- the first one usually passes, and second one fails much more frequently. First check also requires traversing the superclasses upwards looking for match. Reversing the order of the checks, plus inlining the helper method improves performance without changing the semantics. > > Out of curiosity, my previous patch dropped the first check completely, replacing it by asserts, and we definitely run into situation where that check is needed on some tests. > > On my machine, `VM.latestUserDefinedLoader` invocation time drops from 115 to 100 ns/op. Single-threaded SPECjvm2008:serial improves about 3% with this patch. > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug, `tier1`, `tier2`, `tier3` > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485` > `$ git checkout pull/2485` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Added a comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2485/files - new: https://git.openjdk.java.net/jdk/pull/2485/files/fc333037..72e830a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2485&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2485&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485 PR: https://git.openjdk.java.net/jdk/pull/2485

3 4

RFR: 8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially
by Lin Zang 11 Feb '21

11 Feb '21

8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially ------------- Commit messages: - 8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially Changes: https://git.openjdk.java.net/jdk/pull/2519/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2519&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261482 Stats: 50 lines in 4 files changed: 7 ins; 22 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2519/head:pull/2519 PR: https://git.openjdk.java.net/jdk/pull/2519

1 1

RFR: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo
by Aleksey Shipilev 10 Feb '21

10 Feb '21

SonarCloud instance reports as new warning after JDK-8254702: This branch can not be reached because the condition duplicates a previous condition in the same sequence of "if/else if" statements. char* getJvmLauncherLibPath(void) { ... if (PACKAGE_TYPE_RPM == pkg->type) { pkgQueryCmd = "rpm -ql '%s' 2>/dev/null"; } else if (PACKAGE_TYPE_RPM == pkg->type) { <--- here pkgQueryCmd = "dpkg -L '%s' 2>/dev/null"; Seems like an obvious typo. Additional tests: - [x] Linux x86_64 (Ubuntu) `tools/jpackage` ------------- Commit messages: - Typo fix Changes: https://git.openjdk.java.net/jdk/pull/2452/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2452&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261298 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2452.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2452/head:pull/2452 PR: https://git.openjdk.java.net/jdk/pull/2452

4 6

RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings
by Aleksey Shipilev 10 Feb '21

10 Feb '21

$ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/HugeCapacity.java TEST_VM_OPTS=-XX:-CompactStrings STDERR: java.lang.OutOfMemoryError: Required length exceeds implementation limit at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:259) at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:229) at java.base/java.lang.AbstractStringBuilder.ensureCapacity(AbstractStringBuilder.java:213) at java.base/java.lang.StringBuilder.ensureCapacity(StringBuilder.java:87) at HugeCapacity.testLatin1(HugeCapacity.java:49) at HugeCapacity.main(HugeCapacity.java:37) I went back and forth in fixing this test, and I think the best we can do is sense the current setting on `CompactStrings` and choose the test configuration based on that. The alternative is to use `WhiteBox` within the test (tried, it is quite a bit ugly). Note that this test deliberately does not run `-XX:-CompactStrings` even when `vm.opt.final.CompactStrings` returns true (= "available"), because that might mean `TEST_VM_OPTS=-XX:+CompactStrings` is in effect, and we have the VM option conflict. Additional testing: - [x] Linux x86_64, affected test (default), passes - [x] Linux x86_64, affected test (`-XX:-CompactStrings`), passes - [x] Linux x86_64, affected test (`-XX:+CompactStrings`), passes ------------- Commit messages: - 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings Changes: https://git.openjdk.java.net/jdk/pull/2355/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260934 Stats: 26 lines in 2 files changed: 20 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2355/head:pull/2355 PR: https://git.openjdk.java.net/jdk/pull/2355

2 8