On Wed, 21 Aug 2024 11:10:22 GMT, Alan Bateman wrote:
>> Unfortunately there is no good, deterministic reproducer which can be used
>> as a regression test at this point in time.
>
> src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
> line 533:
>
>> 531: */
On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang wrote:
> Unfortunately there is no good, deterministic reproducer which can be used as
> a regression test at this point in time.
I think this is the most straightforward way to address. It doesn't need doc
change -- there are other cases where b
On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea wrote:
> The Exchanger class uses spin-waits that are hostile to some uses of
> VirtualThreads. Improving this requires a means of estimating whether there
> are many VirtualThreads with few carriers, which can be supported by adding a
&g
On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea wrote:
> The Exchanger class uses spin-waits that are hostile to some uses of
> VirtualThreads. Improving this requires a means of estimating whether there
> are many VirtualThreads with few carriers, which can be supported by adding a
&g
the possible expense of revealing too much
> about current VT implementation
Doug Lea has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains five additional commi
On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea wrote:
> The Exchanger class uses spin-waits that are hostile to some uses of
> VirtualThreads. Improving this requires a means of estimating whether there
> are many VirtualThreads with few carriers, which can be supported by adding a
&g
On Thu, 15 Aug 2024 08:28:24 GMT, Pavel Rappo wrote:
>> This PR fixes a few trivial grammar issues and typos in documentation.
>>
>> The main issue is the use of the word "timeout". To my mind, timeout, a
>> duration, is not the same as deadline, which is a point in time, an instant,
>> which
On Thu, 15 Aug 2024 08:28:24 GMT, Pavel Rappo wrote:
>> This PR fixes a few trivial grammar issues and typos in documentation.
>>
>> The main issue is the use of the word "timeout". To my mind, timeout, a
>> duration, is not the same as deadline, which is a point in time, an instant,
>> which
On Thu, 15 Aug 2024 15:41:21 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 858:
>>
>>> 856: * usages of ForkJoinTasks ignore interrupt status when executing
>>> 857: * or awaiting completion. Otherwise, reporting task results or
>>>
On Tue, 13 Aug 2024 11:52:05 GMT, Viktor Klang wrote:
>> The Exchanger class uses spin-waits that are hostile to some uses of
>> VirtualThreads. Improving this requires a means of estimating whether there
>> are many VirtualThreads with few carriers, which can be supported by adding
>> a metho
On Mon, 12 Aug 2024 16:08:31 GMT, Viktor Klang wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Catching both Error and RuntimeException
>
> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongS
The Exchanger class uses spin-waits that are hostile to some uses of
VirtualThreads. Improving this requires a means of estimating whether there are
many VirtualThreads with few carriers, which can be supported by adding a
method in class ForkJoinWorkerThread. This enables a reworking of the exc
On Mon, 12 Aug 2024 14:02:52 GMT, Alan Bateman wrote:
>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when
>> failing due to a LinkageError or other errors
>
> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
> line 381:
>
>> 379:
On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang wrote:
> Removes some of the old wording around the algorithmic complexity of
> ConcurrentSkipListSet::size() while still retaining the warning around the
> accuracy of the returned result.
Yes, thanks for fixing wording that should have been upda
On Tue, 2 Jul 2024 17:55:31 GMT, Suryanarayana Garlapati
wrote:
>> @wborn I think 17 should also be OK modulo deleting 2 lines for pre-21
>> mentioned above. I only checked with 19 though..
>
> @DougLea is there any timeline where we can expect the backport of this fix
> into jdk17? or any oth
On Thu, 6 Jun 2024 12:46:36 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to si
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployment
On Tue, 4 Jun 2024 13:03:45 GMT, Viktor Klang wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>>
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size z
On Sun, 2 Jun 2024 14:33:45 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinP
On Fri, 31 May 2024 14:08:49 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinP
On Fri, 31 May 2024 14:04:50 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinP
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
On Wed, 29 May 2024 14:09:51 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains 41
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
On Wed, 29 May 2024 14:19:52 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains 41
On Wed, 29 May 2024 13:26:10 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains 41
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
On Wed, 22 May 2024 21:23:04 GMT, Sunmisc Unsafe wrote:
>> After recheckiing, the best policy is to leave internal queues the same, but
>> initialize external queues larger.
>
> Probably a misplaced post again, but why can't you allocate an array of arrays
> where the outer array is 30
> and the
On Thu, 16 May 2024 10:29:48 GMT, Sunmisc Unsafe wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments
>
> Maybe I don't quite understand, or I don't hav
On Wed, 22 May 2024 15:51:05 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains 36
On Wed, 22 May 2024 15:45:43 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains 36
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
On Fri, 17 May 2024 13:19:19 GMT, Viktor Klang wrote:
>> Local testing seems to indicate that this fix (which mirrors what's done in
>> the FIFO mode) addresses the problem.
>>
>> But with that said, I haven't come up with a decent way of adding some form
>> of regression test. Suggestions are
On Fri, 17 May 2024 11:39:32 GMT, Viktor Klang wrote:
>> Local testing seems to indicate that this fix (which mirrors what's done in
>> the FIFO mode) addresses the problem.
>>
>> But with that said, I haven't come up with a decent way of adding some form
>> of regression test. Suggestions are
On Mon, 13 May 2024 17:06:10 GMT, Viktor Klang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the J
On Sun, 12 May 2024 19:46:42 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinP
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has upda
On Sat, 11 May 2024 23:39:04 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 12:20:27 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 978:
>>
>>> 976: * of two, at least 2. See above.
>>> 977: */
>>> 978: static final int INITIAL_QUEUE_CAPACITY = 1 &
On Fri, 10 May 2024 11:44:14 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1412:
>>
>>> 1410: if (stalled)
>>> 1411: Thread.onSpinWait();
>>> 1412:
On Fri, 10 May 2024 07:34:40 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:30:24 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:15:59 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:11:52 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:08:05 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:04:27 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:02:23 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 07:35:17 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
This set of changes address causes of poor utilization with small numbers of
cores due to overly aggressive contention avoidance. A number of further
adjustments were needed to still avoid most contention effects in deployments
with large numbers of cores
-
Commit messages:
- Merg
On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang wrote:
>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> src/java.base/share/classes/java/ut
On Fri, 26 Apr 2024 11:43:06 GMT, Viktor Klang wrote:
> This is an attempt to be more clear about recommendations on Lock usage.
Thanks for finally processing this after we let this good suggestion sit for
too long!
-
PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment
On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang wrote:
> This PR adds the exception documentation as per the ExecutorService API
> contract. I also took the liberty of adding @Override-annotations to be clear
> about intent.
This seems OK, but could someone read the generated javadoc to make su
On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which removes the 19 deprecated `xxObject*` alias
>> methods from `jdk.internal.misc.Unsafe`.
>>
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow
>> `jsr166.jar` to be used across JDK versi
On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang wrote:
> The common ForkJoinPool creating threads as a result of submitting tasks is
> preventing class unloading when the thread construction is initiated from a
> class loaded in a separate classloader. This fix avoids that when no
> SecurityMana
On Tue, 27 Feb 2024 10:30:44 GMT, Viktor Klang wrote:
> As an intermediate fix to the test, switching to explicit usage of an
> ExecutorService seems to do the trick to make this test reliably pass.
>
> With that said, this test (CHM::ToArray.java) seems to trigger an issue in
> ForkJoinPool,
On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang wrote:
> More aggressively breaking chains in order to prevent nodes promoted to older
> generations standing in the way for collecting younger nodes. I decided that
> it was most efficient to add this logic to the else-branch of updating the
> fi
On Mon, 15 Jan 2024 17:59:38 GMT, Chris Hegarty wrote:
>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> bro
On Mon, 15 Jan 2024 12:09:48 GMT, Chris Hegarty wrote:
>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> bro
On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang wrote:
> While this might not fix 8314515, it should at least make it more exact.
Yes, it is a bit more fragile (looking for particular methods) but similar to
other test improvements (like FJP close tests) that make them more reliable and
surpris
On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao wrote:
> ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` ->
> `transfer()`. When coming from the copy constructor, the Map is empty, so
> there is nothing to transfer. But `transfer()` will still copy all the empty
> nodes fr
On Sun, 19 Nov 2023 17:36:01 GMT, Doug Lea wrote:
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
This pull request has now been integrated.
Changeset: cc25d8b1
Author: Doug Lea
URL:
https://git.openjdk.org/jdk/
On Wed, 22 Nov 2023 20:48:05 GMT, Viktor Klang wrote:
> We've seen some rare failures of the CLQ Whitebox test on "less-strong"
> architectures, and the only thing which -- given my research -- could be the
> culprit is spuriously failing weakCAS (which is correct in terms of the
> implementat
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
Doug Lea has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. Th
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
Doug Lea has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. Th
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
Doug Lea has updated the pull request incrementally with one additional commit
since the last revision:
Reduce oversignalling and contention; add test
-
Changes:
On Tue, 28 Nov 2023 14:04:13 GMT, Alan Bateman wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert 2 lines in method scan
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinP
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
Doug Lea has updated the pull request incrementally with one additional commit
since the last revision:
Revert 2 lines in method scan
-
Changes:
- all:
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
Doug Lea has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. Th
On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote:
>> As discussed in JBS all platforms (some tweaks to Zero are in progress)
>> actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip
>> out the locked-based alternatives to using it and just add a guarantee that
>> it i
On Wed, 22 Nov 2023 08:07:00 GMT, Andrey Turbanov wrote:
>> Doug Lea has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains three
On Tue, 21 Nov 2023 21:27:08 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains three
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
Doug Lea has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. Th
On Mon, 20 Nov 2023 14:28:15 GMT, Viktor Klang wrote:
>> It would be better, but absolute-time Unsafe.park only operates at
>> millisecond accuracy (and even at that may misfire early, requiring
>> TIMEOUT_SLOP.)
>
> I was thinking more about cases where system clock moves backwards in time.
>
> This update cascades timeouts to trim subsequent workers after the first
> keepAlive inactive period.
Doug Lea has updated the pull request incrementally with one additional commit
since the last revision:
tweak cascades; reinstate an @Contended; resolve JDK-8
On Mon, 20 Nov 2023 11:23:54 GMT, Viktor Klang wrote:
>> This update cascades timeouts to trim subsequent workers after the first
>> keepAlive inactive period.
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2140:
>
>> 2138: Thread.interrupted();
This update cascades timeouts to trim subsequent workers after the first
keepAlive inactive period.
-
Commit messages:
- Support cascading idle timeouts
Changes: https://git.openjdk.org/jdk/pull/16725/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=00
Issue:
On Mon, 30 Oct 2023 14:54:08 GMT, Viktor Klang wrote:
> Discussed with @DougLea and adjusting the queue capacity to at least the
> number of participating threads seems like the most sensible fix.
Thanks for figuring out where to make the adjustment! Looks good.
-
PR Comment: http
On Sat, 3 Jun 2023 14:08:02 GMT, Doug Lea wrote:
> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java
> failed with "InterruptedException: sleep interrupted" and related issues.
>
> This is a major ForkJoin update (and hard to review -- sorry) tha
ensure consistent data structures and actions without requiring global
> synchronization or locking on every task execution that would massively
> degrade performance. The previous lack of a solution to this was the main
> reason for these incompatibilities.
Doug Lea has updated the pull reque
ensure consistent data structures and actions without requiring global
> synchronization or locking on every task execution that would massively
> degrade performance. The previous lack of a solution to this was the main
> reason for these incompatibilities.
Doug Lea has updated the pull re
On Mon, 23 Oct 2023 15:28:31 GMT, Viktor Klang wrote:
> Resolves a visibility issue in SubmissionPublisher by making the `waiter`
> member of BufferedSubscription *volatile*.
Yes, looks good to me.
-
PR Comment: https://git.openjdk.org/jdk/pull/16313#issuecomment-1775517786
ensure consistent data structures and actions without requiring global
> synchronization or locking on every task execution that would massively
> degrade performance. The previous lack of a solution to this was the main
> reason for these incompatibilities.
Doug Lea has updated the pull reque
ensure consistent data structures and actions without requiring global
> synchronization or locking on every task execution that would massively
> degrade performance. The previous lack of a solution to this was the main
> reason for these incompatibilities.
Doug Lea has updated the pull reque
ensure consistent data structures and actions without requiring global
> synchronization or locking on every task execution that would massively
> degrade performance. The previous lack of a solution to this was the main
> reason for these incompatibilities.
Doug Lea has updated the pull re
ensure consistent data structures and actions without requiring global
> synchronization or locking on every task execution that would massively
> degrade performance. The previous lack of a solution to this was the main
> reason for these incompatibilities.
Doug Lea has updated the pull reque
On Thu, 12 Oct 2023 13:48:23 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More cleanup
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinP
On Thu, 12 Oct 2023 13:46:01 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More cleanup
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java lin
ensure consistent data structures and actions without requiring global
> synchronization or locking on every task execution that would massively
> degrade performance. The previous lack of a solution to this was the main
> reason for these incompatibilities.
Doug Lea has updated the pull re
1 - 100 of 198 matches
Mail list logo
