August 2021 - core-libs-dev

RFR: 8269559: AArch64: Implement string_compare intrinsic in SVE
by TatWai Chong 14 Oct '21

14 Oct '21

This patch implements string_compare intrinsic in SVE. It supports all LL, LU, UL and UU comparisons. As we haven't found an existing benchmark to measure performance impact, we created a benchmark derived from the test [1] for this evaluation. This benchmark is attached to this patch. Besides, remove the unused temporary register `vtmp3` from the existing match rules for StrCmp. The result below shows all varients can be benefited largely. Command: make exploded-test TEST="micro:StringCompareToDifferentLength" Benchmark (size) Mode Cnt Score Speedup Units compareToLL 24 avgt 10 1.0x ms/op compareToLL 36 avgt 10 1.0x ms/op compareToLL 72 avgt 10 1.0x ms/op compareToLL 128 avgt 10 1.4x ms/op compareToLL 256 avgt 10 1.8x ms/op compareToLL 512 avgt 10 2.7x ms/op compareToLU 24 avgt 10 1.6x ms/op compareToLU 36 avgt 10 1.8x ms/op compareToLU 72 avgt 10 2.3x ms/op compareToLU 128 avgt 10 3.8x ms/op compareToLU 256 avgt 10 4.7x ms/op compareToLU 512 avgt 10 6.3x ms/op compareToUL 24 avgt 10 1.6x ms/op compareToUL 36 avgt 10 1.7x ms/op compareToUL 72 avgt 10 2.2x ms/op compareToUL 128 avgt 10 3.3x ms/op compareToUL 256 avgt 10 4.4x ms/op compareToUL 512 avgt 10 6.1x ms/op compareToUU 24 avgt 10 1.0x ms/op compareToUU 36 avgt 10 1.0x ms/op compareToUU 72 avgt 10 1.4x ms/op compareToUU 128 avgt 10 2.2x ms/op compareToUU 256 avgt 10 2.6x ms/op compareToUU 512 avgt 10 3.7x ms/op [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/intr… ------------- Commit messages: - 8269559: AArch64: Implement string_compare intrinsic in SVE Changes: https://git.openjdk.java.net/jdk/pull/5129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269559 Stats: 550 lines in 12 files changed: 447 ins; 12 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/5129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5129/head:pull/5129 PR: https://git.openjdk.java.net/jdk/pull/5129

5 12

RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries
by Maurizio Cimadamore 12 Oct '21

12 Oct '21

This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. ------------- Commit messages: - Improve javadoc - Initial push Changes: https://git.openjdk.java.net/jdk/pull/4316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268129 Stats: 1278 lines in 44 files changed: 569 ins; 617 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316

6 23

RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable
by Сергей Цыпанов 12 Oct '21

12 Oct '21

In some JDK classes there's still the following hashCode() implementation: long objNum; public int hashCode() { return (int) objNum; } This outdated expression should be replaced with Long.hashCode(long) as it - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. See https://stackoverflow.com/a/4045083 This is related to https://github.com/openjdk/jdk/pull/4309 ------------- Commit messages: - 8268764: Use Long.hashCode() instead of int-cast where applicable Changes: https://git.openjdk.java.net/jdk/pull/4491/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268764 Stats: 15 lines in 9 files changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491 PR: https://git.openjdk.java.net/jdk/pull/4491

5 12

RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
by Wang Huang 09 Oct '21

09 Oct '21

Dear all, Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo. * We add a JMH test case * Here is the result of this test case Benchmark |(size)| Mode| Cnt|Score | Error |Units ---------------------------------|------|-----|----|------|--------|----- StringCompare.compareLL | 64 | avgt| 5 |7.992 | ± 0.005|us/op StringCompare.compareLL | 72 | avgt| 5 |15.029| ± 0.006|us/op StringCompare.compareLL | 80 | avgt| 5 |14.655| ± 0.011|us/op StringCompare.compareLL | 91 | avgt| 5 |16.363| ± 0.12 |us/op StringCompare.compareLL | 101 | avgt| 5 |16.966| ± 0.007|us/op StringCompare.compareLL | 121 | avgt| 5 |19.276| ± 0.006|us/op StringCompare.compareLL | 181 | avgt| 5 |19.002| ± 0.417|us/op StringCompare.compareLL | 256 | avgt| 5 |24.707| ± 0.041|us/op StringCompare.compareLLWithLdp| 64 | avgt| 5 |8.001 | ± 0.121|us/op StringCompare.compareLLWithLdp| 72 | avgt| 5 |11.573| ± 0.003|us/op StringCompare.compareLLWithLdp| 80 | avgt| 5 |6.861 | ± 0.004|us/op StringCompare.compareLLWithLdp| 91 | avgt| 5 |12.774| ± 0.201|us/op StringCompare.compareLLWithLdp| 101 | avgt| 5 |8.691 | ± 0.004|us/op StringCompare.compareLLWithLdp| 121 | avgt| 5 |11.091| ± 1.342|us/op StringCompare.compareLLWithLdp| 181 | avgt| 5 |14.64 | ± 0.581|us/op StringCompare.compareLLWithLdp| 256 | avgt| 5 |25.879| ± 1.775|us/op StringCompare.compareUU | 64 | avgt| 5 |13.476| ± 0.01 |us/op StringCompare.compareUU | 72 | avgt| 5 |15.078| ± 0.006|us/op StringCompare.compareUU | 80 | avgt| 5 |23.512| ± 0.011|us/op StringCompare.compareUU | 91 | avgt| 5 |24.284| ± 0.008|us/op StringCompare.compareUU | 101 | avgt| 5 |20.707| ± 0.017|us/op StringCompare.compareUU | 121 | avgt| 5 |29.302| ± 0.011|us/op StringCompare.compareUU | 181 | avgt| 5 |39.31 | ± 0.016|us/op StringCompare.compareUU | 256 | avgt| 5 |54.592| ± 0.392|us/op StringCompare.compareUUWithLdp| 64 | avgt| 5 |16.389| ± 0.008|us/op StringCompare.compareUUWithLdp| 72 | avgt| 5 |10.71 | ± 0.158|us/op StringCompare.compareUUWithLdp| 80 | avgt| 5 |11.488| ± 0.024|us/op StringCompare.compareUUWithLdp| 91 | avgt| 5 |13.412| ± 0.006|us/op StringCompare.compareUUWithLdp| 101 | avgt| 5 |16.245| ± 0.434|us/op StringCompare.compareUUWithLdp| 121 | avgt| 5 |16.597| ± 0.016|us/op StringCompare.compareUUWithLdp| 181 | avgt| 5 |27.373| ± 0.017|us/op StringCompare.compareUUWithLdp| 256 | avgt| 5 |41.74 | ± 3.5 |us/op >From this table, we can see that in most cases, our patch is better than old one. Thank you for your review. Any suggestions are welcome. ------------- Commit messages: - 8268231: Aarch64: Use ldp in intrinsics for String.compareTo Changes: https://git.openjdk.java.net/jdk/pull/4722/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4722&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268231 Stats: 259 lines in 3 files changed: 255 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4722/head:pull/4722 PR: https://git.openjdk.java.net/jdk/pull/4722

6 40

RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields
by Lin Zang 30 Sep '21

30 Sep '21

4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields ------------- Commit messages: - remove trailing spaces - 4890732: support optional GZIP fields in GZIPOutputStream Changes: https://git.openjdk.java.net/jdk/pull/3072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4890732 Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072 PR: https://git.openjdk.java.net/jdk/pull/3072

5 46

RFR: 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing
by wxiang 27 Sep '21

27 Sep '21

Using jarIndex for Hibench, there is an unexpected behavior with the exception "Exception in thread "main" org.apache.hadoop.fs.UnsupportedFileSystemException: No FileSystem for scheme "hdfs"". After investigating it, it is related to the usage of ServiceLoader with JarIndex. The below stack shows the issue with JDK11: getResource:1016, URLClassPath$JarLoader (jdk.internal.loader) getResource:937, URLClassPath$JarLoader (jdk.internal.loader) findResource:912, URLClassPath$JarLoader (jdk.internal.loader) next:341, URLClassPath$1 (jdk.internal.loader) hasMoreElements:351, URLClassPath$1 (jdk.internal.loader) hasNext:355, BuiltinClassLoader$1 (jdk.internal.loader) hasMoreElements:363, BuiltinClassLoader$1 (jdk.internal.loader) next:3032, CompoundEnumeration (java.lang) hasMoreElements:3041, CompoundEnumeration (java.lang) nextProviderClass:1203, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNextService:1221, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNext:1265, ServiceLoader$LazyClassPathLookupIterator (java.util) hasNext:1300, ServiceLoader$2 (java.util) hasNext:1385, ServiceLoader$3 (java.util) The below API tries to get all the resources with the same name. public Enumeration<URL> findResources(final String name, final boolean check) ``` After using JarIndex, URLClassPath.findResources only returns 1 URL. It is the same as the description in JDK-6957241. The issue still exists in JDK18. Root cause: public Enumeration<URL> findResources(final String name, final boolean check) { return new Enumeration<>() { private int index = 0; private URL url = null; private boolean next() { if (url != null) { return true; } else { Loader loader; while ((loader = getLoader(index++)) != null) { url = loader.findResource(name, check); if (url != null) { return true; } } return false; } } ... }; } With the JarIndex, there is only one loader which is corresponding to the jar with the index due to the implementation in JarLoader.getResource(final String name, boolean check, Set<String> visited). Loaders corresponding to other jar packages will not appear in this while. So it only returns 1 instance. To solve the issue, I change the implementation "private boolean next()". If the loader has index, traverse the index and get all the resource from the loader. ------------- Commit messages: - solve Whitespace error - 6957241: ClassLoader.getResources() returns only 1 instance when using jar indexing Changes: https://git.openjdk.java.net/jdk/pull/5316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6957241 Stats: 769 lines in 8 files changed: 763 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5316/head:pull/5316 PR: https://git.openjdk.java.net/jdk/pull/5316

6 13

RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0
by Roger Riggs 24 Sep '21

24 Sep '21

On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property and the version number provided by `sw_vers -productVersion`. When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 though the current version numbering is 11.nnn. The workaround is to derive the os.version number from the ProductBuildVersion. When the toolchain is updated to XCode 12.nnn it can be removed. The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. ------------- Commit messages: - 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 Changes: https://git.openjdk.java.net/jdk/pull/2530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253702 Stats: 30 lines in 1 file changed: 21 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2530/head:pull/2530 PR: https://git.openjdk.java.net/jdk/pull/2530

5 20

RFR: 8272600: (test) Use native "sleep" in Basic.java
by Roger Riggs 22 Sep '21

22 Sep '21

The intermittent test in java/lang/ProcessBuilder/Basic.java has identified unexpected messages from a child Java VM as the cause of the test failure. Attempts to control the output of the child VM have failed, the VM is unrepentant . There is no functionality in the child except to wait long enough for the test to finish and the child is destroyed. The fix is to switch from using a Java child to using a native child; a new executable `sleepmillis`. ------------- Commit messages: - 8272600: (test) Use native "sleep" in Basic.java Changes: https://git.openjdk.java.net/jdk/pull/5239/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272600 Stats: 116 lines in 2 files changed: 70 ins; 34 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239

5 35

RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1
by Aleksey Shipilev 20 Sep '21

20 Sep '21

See the bug report for more details. I would appreciate if people with their corporate testing systems would run this through their systems to avoid surprises. (ping @RealCLanger, @iignatev). ------------- Commit messages: - Drop stream tests exclusivity Changes: https://git.openjdk.java.net/jdk/pull/5189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247980 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5189/head:pull/5189 PR: https://git.openjdk.java.net/jdk/pull/5189

7 15

RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
by Jim Laskey 14 Sep '21

14 Sep '21

This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random… old PR: https://github.com/openjdk/jdk/pull/1273 ------------- Commit messages: - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862; Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7 Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248862 Stats: 13319 lines in 25 files changed: 11110 ins; 2132 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292

14 110