Re: RFR: 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs
On Thu, 25 Nov 2021 11:57:52 GMT, Stuart Monteith wrote: > Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread > to finish before restarting trial method. @stooart-mon Thank you for fixing the bug. lgtm - Marked as reviewed by eas...@github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/6560
Withdrawn: 8275728: Add simple Producer/Consumer microbenchmark for Thread.onSpinWait
On Wed, 10 Nov 2021 18:07:47 GMT, Evgeny Astigeevich wrote: > 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/SpinWaitTest/src/main/java/SpinWaitTest.java): >> 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 > ScoreError Units > ThreadOnSpinWaitProducerConsumer.trial 100 0 avgt 75 > 1520.448 ± 40.507 us/op > > - No `Thread.onSpinWait` intrinsic > > Benchmark (maxNum) (spinNum) Mode Cnt > ScoreError Units > ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 > 1580.756 ± 47.501 us/op > > - `ISB`-based `Thread.onSpinWait` intrinsic > > Benchmark (maxNum) (spinNum) Mode Cnt > Score Error Units > ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 > 617.454 ± 174.431 us/op > > > **X86_64 results**: > - No spin loop > > Benchmark (maxNum) (spinNum) Mode Cnt > Score Error Units > ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 > 1417.944 ± 1.691 us/op > > - No `Thread.onSpinWait` intrinsic > > Benchmark (maxNum) (spinNum) Mode Cnt > Score Error Units > ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 > 1410.987 ± 2.093 us/op > > - `PAUSE`-based `Thread.onSpinWait` intrinsic > > Benchmark (maxNum) (spinNum) Mode Cnt > Score Error Units > ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 > 217.054 ± 1.283 us/op This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/6338
RFR: 8275728: Add simple Producer/Consumer microbenchmark for Thread.onSpinWait
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/SpinWaitTest/src/main/java/SpinWaitTest.java): > 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 ScoreError Units ThreadOnSpinWaitProducerConsumer.trial 100 0 avgt 75 1520.448 ± 40.507 us/op - No `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode Cnt ScoreError Units ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 1580.756 ± 47.501 us/op - `ISB`-based `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode CntScore Error Units ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 617.454 ± 174.431 us/op **X86_64 results**: - No spin loop Benchmark (maxNum) (spinNum) Mode CntScore Error Units ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 1417.944 ± 1.691 us/op - No `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode CntScore Error Units ThreadOnSpinWaitProducerConsumer.trial 100125 avgt 75 1410.987 ± 2.093 us/op - `PAUSE`-based `Thread.onSpinWait` intrinsic Benchmark (maxNum) (spinNum) Mode CntScore Error Units ThreadOnSpinWaitProducerConsumer.trial 100125 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=6338=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
Integrated: 8271737: Only normalize the cached user.dir property once
On Thu, 7 Oct 2021 14:05:19 GMT, Evgeny Astigeevich wrote: > The change completes the fix of > [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has > added normalisation in a constructor but not removed it from the get method. This pull request has now been integrated. Changeset: b8bd259b Author: Evgeny Astigeevich Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/b8bd259bb83096f8727222a4e5cd84e80e096275 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8271737: Only normalize the cached user.dir property once Reviewed-by: phh - PR: https://git.openjdk.java.net/jdk/pull/5850
RFR: 8271737: Only normalize the cached user.dir property once
The change completes the fix of [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has added normalisation in a constructor but not removed it from the get method. - Commit messages: - 8271737: Only normalize the cached user.dir property once Changes: https://git.openjdk.java.net/jdk/pull/5850/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5850=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271737 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5850/head:pull/5850 PR: https://git.openjdk.java.net/jdk/pull/5850
Re: RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates [v2]
On Tue, 8 Dec 2020 05:54:24 GMT, Martin Buchholz wrote: >> 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates > > Martin Buchholz has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. This PR causes 16x performance regression in SynchronousQueue. Details are in https://bugs.openjdk.java.net/browse/JDK-8267502 - PR: https://git.openjdk.java.net/jdk/pull/1645
