March 2021 - core-libs-dev

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

RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant
by Richard Fussenegger 17 Jun '21

17 Jun '21

6594730: UUID.getVersion() is only meaningful for Leach-Salz variant ------------- Commit messages: - 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant Changes: https://git.openjdk.java.net/jdk/pull/1467/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1467&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6594730 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1467/head:pull/1467 PR: https://git.openjdk.java.net/jdk/pull/1467

4 12

RFR: 8263561: Re-examine uses of LinkedList
by Сергей Цыпанов 02 Jun '21

02 Jun '21

The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. jdk:tier1 and jdk:tier2 are both ok ------------- Commit messages: - Remove remaining usages of LinkedList in java.base Changes: https://git.openjdk.java.net/jdk/pull/2744/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263561 Stats: 40 lines in 9 files changed: 0 ins; 2 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744

7 27

RFR: 8203359: Container level resources events
by Jaroslav Bachorik 21 May '21

21 May '21

With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events. Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with. * CPU related metrics * Memory related metrics * I/O related metrics For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently). ------------- Commit messages: - Formatting spaces - 8203359: Container level resources events Changes: https://git.openjdk.java.net/jdk/pull/3126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203359 Stats: 389 lines in 8 files changed: 386 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126 PR: https://git.openjdk.java.net/jdk/pull/3126

3 50

RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates
by Martin Buchholz 20 May '21

20 May '21

8246677: LinkedTransferQueue and SynchronousQueue synchronization updates ------------- Commit messages: - JDK-8246677 Changes: https://git.openjdk.java.net/jdk/pull/1645/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1645&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246677 Stats: 538 lines in 3 files changed: 143 ins; 294 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/1645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1645/head:pull/1645 PR: https://git.openjdk.java.net/jdk/pull/1645

4 5

RFR: 8261880: Change nested classes in java.base to static nested classes where possible
by Сергей Цыпанов 20 May '21

20 May '21

Non-static classes hold a link to their parent classes, which in many cases can be avoided. ------------- Commit messages: - 8261880: Change nested classes in java.base to static nested classes where possible Changes: https://git.openjdk.java.net/jdk/pull/2589/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261880 Stats: 20 lines in 16 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589 PR: https://git.openjdk.java.net/jdk/pull/2589

7 14

RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
by PROgrm_JARvis 19 May '21

19 May '21

Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. ------------- Commit messages: - 8258588: MD5 MessageDigest in java.util.UUID should be cached Changes: https://git.openjdk.java.net/jdk/pull/1821/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258588 Stats: 33 lines in 1 file changed: 26 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1821/head:pull/1821 PR: https://git.openjdk.java.net/jdk/pull/1821

7 28