April 2021 - core-libs-dev

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: 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: 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

RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods
by Aleksey Shipilev 04 Aug '21

04 Aug '21

Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). Interpreter-only "Hello World": Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) OpenLiberty startup: Before: 2.296, 2.281, 2.291 (seconds) After: 2.254, 2.267, 2.272 (seconds) Additional tests: - [x] Linux `tier1` default (passes) - [x] Linux `tier1` `-XX:-CompactStrings` ------------- Commit messages: - Merge branch 'master' into JDK-8260710-string-inline - Merge branch 'master' into JDK-8260710-string-inline - Initial prototype Changes: https://git.openjdk.java.net/jdk/pull/2334/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2334&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260710 Stats: 173 lines in 5 files changed: 5 ins; 48 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/2334.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2334/head:pull/2334 PR: https://git.openjdk.java.net/jdk/pull/2334

5 5

RFR: 8266054: VectorAPI rotate operation optimization
by Jatin Bhateja 28 Jul '21

28 Jul '21

Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- vec1 = lanewise(VectorOperators.LSHL, n) vec2 = lanewise(VectorOperators.LSHR, n) res = lanewise(VectorOperations.OR, vec1 , vec2) This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. Please find below the performance data for included JMH benchmark. Machine: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascaselake Server) `` Benchmark | (TESTSIZE) | Baseline (ops/min) | Withopt (ops/min) | Gain % -- | -- | -- | -- | -- RotateBenchmark.testRotateLeftI | 64 | 6813.033 | 6936.507 | 1.81 RotateBenchmark.testRotateLeftI | 64 | 11549.524 | 12109.845 | 4.85 RotateBenchmark.testRotateLeftI | 64 | 17780.166 | 18180.083 | 2.25 RotateBenchmark.testRotateLeftI | 128 | 3355.631 | 3426.436 | 2.11 RotateBenchmark.testRotateLeftI | 128 | 5925.534 | 6096.71 | 2.89 RotateBenchmark.testRotateLeftI | 128 | 8847.645 | 8964.224 | 1.32 RotateBenchmark.testRotateLeftI | 256 | 1704.192 | 1779.964 | 4.45 RotateBenchmark.testRotateLeftI | 256 | 2919.158 | 3000.392 | 2.78 RotateBenchmark.testRotateLeftI | 256 | 4386.134 | 4514.211 | 2.92 RotateBenchmark.testRotateLeftL | 64 | 3419.193 | 3500.522 | 2.38 RotateBenchmark.testRotateLeftL | 64 | 5982.87 | 6056.589 | 1.23 RotateBenchmark.testRotateLeftL | 64 | 8829.172 | 8949.157 | 1.36 RotateBenchmark.testRotateLeftL | 128 | 1684.745 | 1784.49 | 5.92 RotateBenchmark.testRotateLeftL | 128 | 2942.226 | 2947.684 | 0.19 RotateBenchmark.testRotateLeftL | 128 | 4385.488 | 4554.113 | 3.85 RotateBenchmark.testRotateLeftL | 256 | 834.195 | 856.939 | 2.73 RotateBenchmark.testRotateLeftL | 256 | 1463.802 | 1551.051 | 5.96 RotateBenchmark.testRotateLeftL | 256 | 2187.005 | 2268.596 | 3.73 RotateBenchmark.testRotateRightI | 64 | 6676.132 | 7077.587 | 6.01 RotateBenchmark.testRotateRightI | 64 | 11452.825 | 11855.45 | 3.52 RotateBenchmark.testRotateRightI | 64 | 17507.286 | 18164.757 | 3.76 RotateBenchmark.testRotateRightI | 128 | 3412.394 | 3519.829 | 3.15 RotateBenchmark.testRotateRightI | 128 | 5905.677 | 5875.698 | -0.51 RotateBenchmark.testRotateRightI | 128 | 8745.95 | 8890.757 | 1.66 RotateBenchmark.testRotateRightI | 256 | 1681.176 | 1708.54 | 1.63 RotateBenchmark.testRotateRightI | 256 | 3004.008 | 3005.606 | 0.05 RotateBenchmark.testRotateRightI | 256 | 4466.633 | 4548.232 | 1.83 RotateBenchmark.testRotateRightL | 64 | 3361.499 | 3461.121 | 2.96 RotateBenchmark.testRotateRightL | 64 | 5873.37 | 6072.209 | 3.39 RotateBenchmark.testRotateRightL | 64 | 8820.284 | 9016.172 | 2.22 RotateBenchmark.testRotateRightL | 128 | 1715.556 | 1720.67 | 0.30 RotateBenchmark.testRotateRightL | 128 | 2957.337 | 3149.193 | 6.49 RotateBenchmark.testRotateRightL | 128 | 4440.468 | 4473.221 | 0.74 RotateBenchmark.testRotateRightL | 256 | 851.391 | 875.371 | 2.82 RotateBenchmark.testRotateRightL | 256 | 1452.422 | 1522.942 | 4.86 RotateBenchmark.testRotateRightL | 256 | 2208.454 | 2263.349 | 2.49 `` ------------- Commit messages: - 8266054: Changing gen-src.sh file permissions - 8266054: VectorAPI rotate operation optimization Changes: https://git.openjdk.java.net/jdk/pull/3720/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266054 Stats: 1282 lines in 45 files changed: 1201 ins; 58 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/3720.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720 PR: https://git.openjdk.java.net/jdk/pull/3720

4 34

RFR: 8265474: Dubious 'null' assignment in CompactByteArray.expand
by Andrey Turbanov 26 Jul '21

26 Jul '21

I propose to remove 'null' assignment of field CompactByteArray.values in `expand` method. In the next statement this field is overridden with another value - `tempArray`. This code was there from initial load of OpenJDK sources. I believe it was just leftovers from development phase of this class. There is no practical reason to assign `null` to non-volatile field and then overwrite it with another value. Also I've removed unused method `getArray`. I hope it's ok to cleanup such unused stuff in the same PR. ------------- Commit messages: - 8265474: Dubious 'null' assignment in CompactByteArray.expand - [PATCH] Remove dubious 'null' assignment to CompactByteArray.values Changes: https://git.openjdk.java.net/jdk/pull/1880/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1880&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265474 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1880/head:pull/1880 PR: https://git.openjdk.java.net/jdk/pull/1880

3 4

RFR: 8247373: ArraysSupport.newLength doc, test, and exception message
by Stuart Marks 23 Jul '21

23 Jul '21

This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code: 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs! 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length. Separately, I'll work on retrofitting various call sites around the JDK to use this method. ------------- Commit messages: - 8247373: ArraysSupport.newLength doc, test, and exception message Changes: https://git.openjdk.java.net/jdk/pull/1617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247373 Stats: 171 lines in 4 files changed: 137 ins; 3 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1617/head:pull/1617 PR: https://git.openjdk.java.net/jdk/pull/1617

7 31

RFR: 8260621: Avoid memory leak in ImageBufferCache
by Bo Zhang 28 Jun '21

28 Jun '21

Previously, `ImageBufferCache` contains a ThreadLocal field which holds strong reference to `ImageBufferCache$BufferReference.class`. When loaded from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` in memory forever and never being GCed. The fix replace the old `ImageBufferCache$BufferReference` class with `WeakReference<ByteBuffer>`, which is verified by provided test. ------------- Commit messages: - 8260621: Avoid memory leak in ImageBufferCache Changes: https://git.openjdk.java.net/jdk/pull/2307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260621 Stats: 123 lines in 2 files changed: 75 ins; 23 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/2307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2307/head:pull/2307 PR: https://git.openjdk.java.net/jdk/pull/2307

4 6

RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes
by Ian Graves 17 Jun '21

17 Jun '21

Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored. ------------- Commit messages: - Note about comments mode and character class whitespace Changes: https://git.openjdk.java.net/jdk/pull/3577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3577&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8199594 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3577/head:pull/3577 PR: https://git.openjdk.java.net/jdk/pull/3577

4 7

RFR: 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput
by Richard Fussenegger 17 Jun '21

17 Jun '21

Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request. ------------- Commit messages: - 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput Changes: https://git.openjdk.java.net/jdk/pull/1465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-5023614 Stats: 115 lines in 2 files changed: 91 ins; 14 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1465/head:pull/1465 PR: https://git.openjdk.java.net/jdk/pull/1465

3 11