June 2021 - core-libs-dev

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: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform
by Masanori Yano 08 Sep '21

08 Sep '21

Hi all, Could you please review the 8269373 bug fixes? These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder. ------------- Commit messages: - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Changes: https://git.openjdk.java.net/jdk/pull/4594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269373 Stats: 14 lines in 6 files changed: 5 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594 PR: https://git.openjdk.java.net/jdk/pull/4594

2 14

RFR: JDK-8267936: PreserveAllAnnotations option isn't tested
by Jaroslav Tulach 24 Aug '21

24 Aug '21

There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. ------------- Commit messages: - Test long time existing behavior of -XX:+PreserveAllAnnotations Changes: https://git.openjdk.java.net/jdk/pull/4280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4280&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267936 Stats: 172 lines in 1 file changed: 172 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4280/head:pull/4280 PR: https://git.openjdk.java.net/jdk/pull/4280

9 37

RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups
by Matthias Baesken 10 Aug '21

10 Aug '21

Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding if (!cg_infos[PIDS_IDX]._data_complete) { log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); // keep the other controller info, pids is optional } ------------- Commit messages: - JDK-8266490 Changes: https://git.openjdk.java.net/jdk/pull/4518/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266490 Stats: 203 lines in 16 files changed: 159 ins; 2 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518 PR: https://git.openjdk.java.net/jdk/pull/4518

3 33

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: 8263561: Re-examine uses of LinkedList
by Сергей Цыпанов 02 Aug '21

02 Aug '21

After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. ------------- Commit messages: - Merge branch 'master' into 8263561 - Merge branch 'master' into purge-linked-list - 8263561: Use sized constructor where reasonable - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - 8263561: Re-examine uses of LinkedList Changes: https://git.openjdk.java.net/jdk/pull/4304/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263561 Stats: 48 lines in 9 files changed: 0 ins; 2 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/4304.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304 PR: https://git.openjdk.java.net/jdk/pull/4304

2 7

RFR: 8268113: Re-use Long.hashCode() where possible
by Сергей Цыпанов 02 Aug '21

02 Aug '21

There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ------------- Commit messages: - 8268113: Re-use Long.hashCode() where possible Changes: https://git.openjdk.java.net/jdk/pull/4309/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268113 Stats: 10 lines in 7 files changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309

5 20

RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available
by Сергей Цыпанов 02 Aug '21

02 Aug '21

Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues. However the code like private String getSimpleName0() { if (isArray()) { return getComponentType().getSimpleName() + "[]"; } //... } can be improved via replacement of `+` with `String.concat()` call. I've used this benchmark to measure impact: @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ClassMethodsBenchmark { private final Class<? extends Object[]> arrayClass = Object[].class; private Method descriptorString; @Setup public void setUp() throws NoSuchMethodException { //fore some reason compiler doesn't allow me to call Class.descriptorString() directly descriptorString = Class.class.getDeclaredMethod("descriptorString"); } @Benchmark public Object descriptorString() throws Exception { return descriptorString.invoke(arrayClass); } @Benchmark public Object typeName() { return arrayClass.getTypeName(); } } and got those results Mode Cnt Score Error Units descriptorString avgt 60 91.480 ± 1.839 ns/op descriptorString:·gc.alloc.rate.norm avgt 60 404.008 ± 4.033 B/op descriptorString:·gc.churn.G1_Eden_Space avgt 60 2791.866 ± 181.589 MB/sec descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 401.702 ± 26.047 B/op descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻³ B/op descriptorString:·gc.count avgt 60 205.000 counts descriptorString:·gc.time avgt 60 216.000 ms patched Mode Cnt Score Error Units descriptorString avgt 60 65.016 ± 3.446 ns/op descriptorString:·gc.alloc.rate avgt 60 2844.240 ± 115.719 MB/sec descriptorString:·gc.alloc.rate.norm avgt 60 288.006 ± 0.001 B/op descriptorString:·gc.churn.G1_Eden_Space avgt 60 2832.996 ± 206.939 MB/sec descriptorString:·gc.churn.G1_Eden_Space.norm avgt 60 286.955 ± 17.853 B/op descriptorString:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec descriptorString:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻³ B/op descriptorString:·gc.count avgt 60 208.000 counts descriptorString:·gc.time avgt 60 228.000 ms ----------------- typeName avgt 60 34.273 ± 0.480 ns/op typeName:·gc.alloc.rate avgt 60 3265.356 ± 45.113 MB/sec typeName:·gc.alloc.rate.norm avgt 60 176.004 ± 0.001 B/op typeName:·gc.churn.G1_Eden_Space avgt 60 3268.454 ± 134.458 MB/sec typeName:·gc.churn.G1_Eden_Space.norm avgt 60 176.109 ± 6.595 B/op typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec typeName:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻⁴ B/op typeName:·gc.count avgt 60 240.000 counts typeName:·gc.time avgt 60 255.000 ms patched typeName avgt 60 15.787 ± 0.214 ns/op typeName:·gc.alloc.rate avgt 60 2577.554 ± 32.339 MB/sec typeName:·gc.alloc.rate.norm avgt 60 64.001 ± 0.001 B/op typeName:·gc.churn.G1_Eden_Space avgt 60 2574.039 ± 147.774 MB/sec typeName:·gc.churn.G1_Eden_Space.norm avgt 60 63.895 ± 3.511 B/op typeName:·gc.churn.G1_Survivor_Space avgt 60 0.003 ± 0.001 MB/sec typeName:·gc.churn.G1_Survivor_Space.norm avgt 60 ≈ 10⁻⁴ B/op typeName:·gc.count avgt 60 189.000 counts typeName:·gc.time avgt 60 199.000 ms I think this patch is likely to improve reflection operations related to arrays. If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible. Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here. ------------- Commit messages: - Use String.concat() where invokedynamic-based String concatenation is not available Changes: https://git.openjdk.java.net/jdk/pull/3627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266972 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627 PR: https://git.openjdk.java.net/jdk/pull/3627

5 17

RFR: 8269665: Clean-up toString() methods of some primitive wrappers
by Сергей Цыпанов 02 Aug '21

02 Aug '21

As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods. Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`. Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first): public static String toString(byte b) { return Integer.toString((int)b, 10); } public String toString() { return Integer.toString((int)value); } Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ByteToStringBenchmark { @Benchmark public String byteToString() { return Byte.toString((byte) 1); } } Results: before Benchmark Mode Cnt Score Error Units ByteToStringBenchmark.byteToString avgt 30 11,648 ± 1,906 ns/op ByteToStringBenchmark.byteToString:·gc.alloc.rate avgt 30 3288,576 ± 418,119 MB/sec ByteToStringBenchmark.byteToString:·gc.alloc.rate.norm avgt 30 48,001 ± 0,001 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space avgt 30 3301,804 ± 455,932 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space.norm avgt 30 48,158 ± 2,085 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space avgt 30 0,004 ± 0,001 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm avgt 30 ≈ 10⁻⁴ B/op ByteToStringBenchmark.byteToString:·gc.count avgt 30 202,000 counts ByteToStringBenchmark.byteToString:·gc.time avgt 30 413,000 ms after Benchmark Mode Cnt Score Error Units ByteToStringBenchmark.byteToString avgt 30 10,016 ± 0,530 ns/op ByteToStringBenchmark.byteToString:·gc.alloc.rate avgt 30 3673,700 ± 167,450 MB/sec ByteToStringBenchmark.byteToString:·gc.alloc.rate.norm avgt 30 48,001 ± 0,001 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space avgt 30 3662,406 ± 205,978 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space.norm avgt 30 47,870 ± 1,750 B/op ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space avgt 30 0,004 ± 0,002 MB/sec ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm avgt 30 ≈ 10⁻⁴ B/op ByteToStringBenchmark.byteToString:·gc.count avgt 30 224,000 counts ByteToStringBenchmark.byteToString:·gc.time avgt 30 358,000 ms ------------- Commit messages: - 8269665: Clean-up toString() methods of some primitive wrappers Changes: https://git.openjdk.java.net/jdk/pull/4633/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269665 Stats: 10 lines in 4 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4633/head:pull/4633 PR: https://git.openjdk.java.net/jdk/pull/4633

2 7