November 2021 - core-libs-dev

RFR: 8275728: Add simple Producer/Consumer microbenchmark for Thread.onSpinWait
by Evgeny Astigeevich 11 Nov '21

11 Nov '21

This is a microbenchmarks to demonstrate `Thread.onSpinWait` can be used to avoid heavy locks. The microbenchmark differs from [Gil's original benchmark](https://github.com/giltene/GilExamples/tree/master/SpinWaitTest) and [Dmitry's variations](http://cr.openjdk.java.net/~dchuyko/8186670/yield/spinwait.html). Those benchmarks produce/consume data by incrementing a volatile counter. The latency of such operations is almost zero. They also don't use heavy locks. According to [Gil's SpinWaitTest.java](https://github.com/giltene/GilExamples/blob/master/SpinW…: > This test can be used to measure and document the impact of Runtime.onSpinWait() behavior > on thread-to-thread communication latencies. E.g. when the two threads are pinned to > the two hardware threads of a shared x86 core (with a shared L1), this test will > demonstrate an estimate the best case thread-to-thread latencies possible on the > platform Gil's microbenchmark targets SMT cases (x86 hyperthreading). As not all CPUs support SMT, the microbenchmarks cannot demonstrate benefits of `Thread.onSpinWait`. It is actually opposite. They show `Thread.onSpinWait` has negative impact on performance. The microbenchmark from PR uses `BigInteger` to have 100 - 200 ns latencies for producing/consuming data. These latencies can cause either a producer or a consumer to wait each another. Waiting is implemented with `Object.wait`/`Object.notify` which are heavy. `Thread.onSpinWait` can be used in a spin loop to avoid them. **ARM64 results**: - No spin loop Benchmark (maxNum) (spinNum) Mode Cnt Score Error Units ThreadOnSpinWaitProducerConsumer.trial 100 0 avgt 75 1520.448 ± 40.507 us/op - No `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode Cnt Score Error Units ThreadOnSpinWaitProducerConsumer.trial 100 125 avgt 75 1580.756 ± 47.501 us/op - `ISB`-based `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode Cnt Score Error Units ThreadOnSpinWaitProducerConsumer.trial 100 125 avgt 75 617.454 ± 174.431 us/op **X86_64 results**: - No spin loop Benchmark (maxNum) (spinNum) Mode Cnt Score Error Units ThreadOnSpinWaitProducerConsumer.trial 100 125 avgt 75 1417.944 ± 1.691 us/op - No `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode Cnt Score Error Units ThreadOnSpinWaitProducerConsumer.trial 100 125 avgt 75 1410.987 ± 2.093 us/op - `PAUSE`-based `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode Cnt Score Error Units ThreadOnSpinWaitProducerConsumer.trial 100 125 avgt 75 217.054 ± 1.283 us/op ------------- Commit messages: - 8275728: Add simple Producer/Consumer microbenchmark for Thread.onSpinWait Changes: https://git.openjdk.java.net/jdk/pull/6338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6338&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275728 Stats: 204 lines in 1 file changed: 204 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6338/head:pull/6338 PR: https://git.openjdk.java.net/jdk/pull/6338

1 1

RFR: 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766
by Yoshiki Sato 11 Nov '21

11 Nov '21

Please review this PR to update the TimeZoneNames files. @naotoj @coffeys Some short name changes are not integrated to the JDK. It was detected by the change made in JDK-8275766. - Africa/Juba change was done by 2017c - Africa/Windhoek changes were done by 2018e - Antarctica/Macquarie change was done by 2017a ------------- Commit messages: - Update affected long timezone names with its English name - Fix full timezone names of Antarctica/Macquarie - 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766 Changes: https://git.openjdk.java.net/jdk/pull/6226/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6226&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276536 Stats: 88 lines in 11 files changed: 22 ins; 0 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/6226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6226/head:pull/6226 PR: https://git.openjdk.java.net/jdk/pull/6226

3 3

RFR: 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893
by Naoto Sato 10 Nov '21

10 Nov '21

Simple doc clarification where the `toString()` output only conforms to ISO 8601 if the seconds in the offset are zero. ------------- Commit messages: - 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893 Changes: https://git.openjdk.java.net/jdk/pull/6321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276775 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/6321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6321/head:pull/6321 PR: https://git.openjdk.java.net/jdk/pull/6321

6 8

RFR: 8276186: Require getAvailableLocales() methods to include Locale.ROOT
by Naoto Sato 10 Nov '21

10 Nov '21

This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249 ------------- Commit messages: - Minor fixup - Reflected CSR modifications - Added a test case - 8276186: Include Locale.ROOT in getAvailableLocales() methods Changes: https://git.openjdk.java.net/jdk/pull/6258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6258&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276186 Stats: 108 lines in 10 files changed: 86 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/6258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6258/head:pull/6258 PR: https://git.openjdk.java.net/jdk/pull/6258

4 6

OutputStreamWriter (not) flushing stateful Charsetencoder
by Bernd Eckenfels 10 Nov '21

10 Nov '21

(I thought this was discussed a while back on a OpenJDK mailing list, but I can’t find it. So apologies if this is a duplicate, but I might have seen it on Apache Commons-io instead - which fixed a similar issue on reader side) The problem: I have code using a OutputStreamWriter with a customer defined charset name. this writer is flushed, and the code expects all pending bytes to be written. However when a stateful charset like cp930 is used, this is not the case. The final unshift byte for example is only written when the writer is closed. This is probably because it does not call end of data encode on the encoder in the flush(). The class does not clearly say or not say what is the correct behavior, however the flush() is formulated in a way that one could expect it should produce a complete stream. So, is this a Bug in the implementation, if not should it be added to the documentation? Here is a small JShell reproducer, you see the extra unshift byte (dec 15) only after the close: var b = new byte[] { 0x31, (byte)0xef, (byte)0xbc, (byte)0x91 }; var s = new String(b, "UTF-8"); // „1２“ (1 is ascii, 2 is fw) var bos = new ByteArrayOutputStream(); var w = new OutputStreamWriter(bos, "cp930"); // stateful ebcdic with Shift chars w.write(s); w.flush(); bos.toByteArray() $8 ==> byte[4] { -15, 14, 66, -15 } w.close(); bos.toByteArray() $10 ==> byte[5] { -15, 14, 66, -15, 15 } -- http://bernd.eckenfels.net

2 1

RFR: 8276926: Use String.valueOf() when initializing File.separator and File.pathSeparator
by Сергей Цыпанов 10 Nov '21

10 Nov '21

Looking into File.pathSeparator I've found out that currently we initialize them as public static final String separator = "" + separatorChar; Which after compilation turns into NEW java/lang/StringBuilder DUP INVOKESPECIAL java/lang/StringBuilder.<init> ()V LDC "" INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; GETSTATIC java/io/File.pathSeparatorChar : C INVOKEVIRTUAL java/lang/StringBuilder.append (C)Ljava/lang/StringBuilder; INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String; PUTSTATIC java/io/File.pathSeparator : Ljava/lang/String; This can be simplified to public static final String separator = String.valueOf(separatorChar); Which is in turn complied into more compact GETSTATIC java/io/File.pathSeparatorChar : C INVOKESTATIC java/lang/String.valueOf (C)Ljava/lang/String; PUTSTATIC java/io/File.pathSeparator : Ljava/lang/String; The changed code is likely to slightly improve start-up time as it allocates less and does no bound checks. ------------- Commit messages: - 8276926: Use String.valueOf() when initializing File.separator and File.pathSeparator Changes: https://git.openjdk.java.net/jdk/pull/6326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276926 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6326/head:pull/6326 PR: https://git.openjdk.java.net/jdk/pull/6326

4 7

Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException
by Andrew Luo 10 Nov '21

10 Nov '21

I have a small PR to fix a bug in AbstractLdapNamingEnumeration - details are in the PR: https://github.com/openjdk/jdk/pull/6095 (Note: I'm already an OpenJDK contributor and have signed an OCA but don't have an author account to be able to create bugs) Thanks, -Andrew

2 1

RFR: 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary
by Roger Riggs 09 Nov '21

09 Nov '21

The java/lang/RuntimeTests/exec/ExecWithDir test forks 500 subprocesses hoping to trigger an intermittent problem fixed in 2002. The test can be removed, it does not exercise the condition it was created for. ------------- Commit messages: - 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary Changes: https://git.openjdk.java.net/jdk/pull/6318/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6318&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276880 Stats: 61 lines in 1 file changed: 0 ins; 61 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6318/head:pull/6318 PR: https://git.openjdk.java.net/jdk/pull/6318

2 2

RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
by Masanori Yano 09 Nov '21

09 Nov '21

Could you please review the 8250678 bug fixes? The `parse` method of ModuleDescriptor.Version class behaves incorrectly when the input string contains consecutive delimiters. The `parse` method treats strings as three sections, but the parsing method differs between the method for the version sections and the ones for others. In version sections, the `parse` method takes a single character in a loop and determines whether it is a delimiter. In pre and build sections, the parse method takes two characters in a loop and determines whether the second character is the delimiter. Therefore, if the string contains a sequence of delimiters in pre or build section, the `parse` method treats character at the odd-numbered position as a token and the one at even-numbered as a delimiter. A string containing consecutive delimiters is an incorrect version string, but this behavior does not follow the API specification. https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/l… Therefore, I propose to fix the parsing method of pre and build section in the same way as the version. ------------- Commit messages: - 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Changes: https://git.openjdk.java.net/jdk/pull/5679/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5679&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250678 Stats: 26 lines in 2 files changed: 11 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5679.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5679/head:pull/5679 PR: https://git.openjdk.java.net/jdk/pull/5679

4 17

RFR: 8276220: Reduce excessive allocations in DateTimeFormatter
by Claes Redestad 09 Nov '21

09 Nov '21

Prompted by a request from Volkan Yazıcı I took a look at why DataTimeFormatters are much less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch address some of that gap, without having looked at the third party implementations. When printing times: - Avoid turning integral values into `String`s before appending them to the buffer - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal` This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`). Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns. Testing: tier1-3 ------------- Commit messages: - 8276220: Reduce excessive allocations in DateTimeFormatter Changes: https://git.openjdk.java.net/jdk/pull/6188/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276220 Stats: 429 lines in 4 files changed: 407 ins; 10 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/6188.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188 PR: https://git.openjdk.java.net/jdk/pull/6188

4 32