Integrated: 8286294 : ForkJoinPool.commonPool().close() spins

On Fri, 6 May 2022 15:05:57 GMT, Doug Lea wrote: > Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool This pull request has now been integrated. Changeset: 4f5d73f2 Author: Doug Lea URL: https://git.openjdk.java.net/jdk/

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v5]

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Test improvements - Changes: - all: https://git.openjdk.java.net/jd

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]

On Sun, 8 May 2022 01:51:17 GMT, Martin Buchholz wrote: >> Doug Lea has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - Accommodate restrictive SecurityManagers >> - merge with loom updates >>

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool Doug Lea has updated the pull request incrementally with three additional commits since the last revision: - Accommodate restrictive SecurityManagers - merge with loom updates Merge

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v3]

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool 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 r

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v2]

On Fri, 6 May 2022 21:46:58 GMT, Martin Buchholz wrote: >> --- a/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java >> +++ b/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java >> @@ -55,7 +55,7 @@ public class ForkJoinPool19Test extends JSR166TestCase { >> } >> >>

Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v2]

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Fix doc types - Changes: - all: https://git.openjdk.java.net/jdk/pul

RFR: 8286294 : ForkJoinPool.commonPool().close() spins

Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool - Commit messages: - Override close as explicit no-op for common pool Changes: https://git.openjdk.java.net/jdk/pull/8577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8577=00

Integrated: 8277090 : jsr166 refresh for jdk19

On Wed, 4 May 2022 12:30:53 GMT, Doug Lea wrote: > This is the revised jsr166 refresh for jdk19. See > https://bugs.openjdk.java.net/browse/JDK-8285450 and > https://bugs.openjdk.java.net/browse/JDK-8277090. Out of caution, this PR > removes the unrelated commits from orig

RFR: 8277090 : jsr166 refresh for jdk19 v2

This is the revised jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090. Out of caution, this PR removes the unrelated commits from original version. - Commit messages: - Redoing JDK-8277090 to avoid

Withdrawn: 8277090 : jsr166 refresh for jdk19

On Sun, 1 May 2022 10:53:55 GMT, Doug Lea wrote: > This is the jsr166 refresh for jdk19. See > https://bugs.openjdk.java.net/browse/JDK-8285450 and > https://bugs.openjdk.java.net/browse/JDK-8277090 This pull request has been closed without being integrated. -

Re: RFR: 8277090 : jsr166 refresh for jdk19 [v3]

On Tue, 3 May 2022 23:10:44 GMT, Doug Lea wrote: >> This is the jsr166 refresh for jdk19. See >> https://bugs.openjdk.java.net/browse/JDK-8285450 and >> https://bugs.openjdk.java.net/browse/JDK-8277090 > > Doug Lea has updated the pull request incrementally with one ad

Re: RFR: 8277090 : jsr166 refresh for jdk19 [v2]

On Tue, 3 May 2022 20:04:48 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line >> 2153: >> >>> 2151: >>> 2152: @Override >>> 2153: public Throwable exceptionNow() { >> >> The unwrapping of CompletionExceptions should be documented

Re: RFR: 8277090 : jsr166 refresh for jdk19 [v3]

> This is the jsr166 refresh for jdk19. See > https://bugs.openjdk.java.net/browse/JDK-8285450 and > https://bugs.openjdk.java.net/browse/JDK-8277090 Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Fix internal doc typo

Re: RFR: 8277090 : jsr166 refresh for jdk19 [v2]

On Tue, 3 May 2022 20:00:52 GMT, Paul Sandoz 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/ForkJoinWorkerTh

Re: RFR: 8277090 : jsr166 refresh for jdk19 [v2]

On Sun, 1 May 2022 14:35:28 GMT, Rémi Forax 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/Futur

Re: RFR: 8277090 : jsr166 refresh for jdk19 [v2]

> This is the jsr166 refresh for jdk19. See > https://bugs.openjdk.java.net/browse/JDK-8285450 and > https://bugs.openjdk.java.net/browse/JDK-8277090 Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Address review

Re: RFR: 8277090 : jsr166 refresh for jdk19

On Mon, 2 May 2022 10:42:35 GMT, Rémi Forax wrote: >> Most AutoCloseables do not mention this in class-level javadocs. Is there a >> reason you think this one should? > > close() is now equivalent to the method shutdownAndAwaitTermination() shown > in the javadoc so i believe , replacing it

Re: RFR: 8277090 : jsr166 refresh for jdk19

Service.java line > 138: > >> 136: * @author Doug Lea >> 137: */ >> 138: public interface ExecutorService extends Executor, AutoCloseable { > > The class documentation should be expanded to explain that an ExecutorService > can be used with a try-with-resource

Re: RFR: 8277090 : jsr166 refresh for jdk19

On 5/1/22 08:29, Doug Lea wrote: This is the jsr166 refresh for jdk19. Seehttps://bugs.openjdk.java.net/browse/JDK-8285450 andhttps://bugs.openjdk.java.net/browse/JDK-8277090 Hopefully a harmless glitch: An initially bad merge with (https://github.com/openjdk/jdk/commit

RFR: 8277090 : jsr166 refresh for jdk19

This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090 - Commit messages: - whitespace - sync with loom - 8276202: LogFileOutput.invalid_file_vm asserts when being executed from a read only

Re: RFR: 8284036: Make ConcurrentHashMap.CollectionView a sealed hierarchy

On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which now marks `CollectionView` as > a `sealed` class with only `EntrySetView`, `KeySetView` and `ValuesView` as > the sub-classes? This change corresponds to >

Re: RFR: 8283683: Make ThreadLocalRandom a final class

On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` > class as `final`? Related JBS issue > https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too

Re: RFR: 8274391: Suppress more warnings on non-serializable non-transient instance fields in java.util.concurrent

On Mon, 27 Sep 2021 18:40:10 GMT, Joe Darcy wrote: > Follow-up change to JDK-8232230, augmentations to javac's Xlint:serial > checking are out for review (https://github.com/openjdk/jdk/pull/5709) and > java.util.concurrent would need some changes to pass under the expanded > checks. > > The

Re: RFR: 8267110: Update java.util to use instanceof pattern variable

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` > package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick Because we still make jdk11-compatible test-release

Integrated: JDK-8264572: ForkJoinPool.getCommonPoolParallelism() reports always 1

On Fri, 2 Apr 2021 10:52:45 GMT, Doug Lea wrote: > This reinserts setting common pool parallelism inadvertently clobbered in > JDK-8259800 This pull request has now been integrated. Changeset: cec66cf8 Author: Doug Lea URL: https://git.openjdk.java.net/jdk/commit/cec66cf8

Re: RFR: JDK-8264572 reinsert common pool parallelism assignment

On Fri, 2 Apr 2021 13:20:44 GMT, Alan Bateman wrote: >> This reinserts setting common pool parallelism inadvertently clobbered in >> JDK-8259800 > > This looks okay to me, I just wonder if we should have a test to the value of > getCommonPoolParallelism. We once had a test, but now that

RFR: JDK-8264572 reinsert common pool parallelism assignment

This reinserts setting common pool parallelism inadvertently clobbered in JDK-8259800 - Commit messages: - Reinsert omitted assignment - Reinsert omitted assignment Changes: https://git.openjdk.java.net/jdk/pull/3324/files Webrev:

Integrated: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test)

On Sat, 20 Feb 2021 14:17:16 GMT, Doug Lea wrote: > This addresses interactions between parallelism-0 and new shutdown support in > https://bugs.openjdk.java.net/browse/JDK-8259800 This pull request has now been integrated. Changeset: 5b7b18c5 Author: Doug Lea URL:

Re: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2]

On Mon, 22 Feb 2021 02:50:34 GMT, David Holmes wrote: >> Doug Lea has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JDK-8259800 > > Hi Doug, > > This looked a little more involved from the versio

Re: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2]

> This addresses interactions between parallelism-0 and new shutdown support in > https://bugs.openjdk.java.net/browse/JDK-8259800 Doug Lea has updated the pull request incrementally with one additional commit since the last revision: JDK-8259800 - Changes: - all:

RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test)

This addresses interactions between parallelism-0 and new shutdown support in https://bugs.openjdk.java.net/browse/JDK-8259800 - Commit messages: - JDK-8259800 Changes: https://git.openjdk.java.net/jdk/pull/2661/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2661=00

Re: RFR: 8260664: Phaser.arrive() memory consistency effects

On Wed, 3 Feb 2021 21:55:54 GMT, Martin Buchholz wrote: > 8260664: Phaser.arrive() memory consistency effects Marked as reviewed by dl (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2388

Re: RFR: 8260461: Modernize jsr166 tck tests

On Tue, 26 Jan 2021 21:23:25 GMT, Martin Buchholz wrote: > 8260461: Modernize jsr166 tck tests Marked as reviewed by dl (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2245

Re: [jdk16] RFR: 8259796: timed CompletableFuture.get may swallow InterruptedException

On Sun, 17 Jan 2021 18:39:55 GMT, Martin Buchholz wrote: > 8259796: timed CompletableFuture.get may swallow InterruptedException Marked as reviewed by dl (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/126

Re: RFR: 8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute

On Sun, 10 Jan 2021 20:13:07 GMT, Martin Buchholz wrote: > 8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in > #execute Marked as reviewed by dl (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2018

Re: RFR: 8259518: Fixes for rare test failures due to 8246585: ForkJoin updates

On Sat, 9 Jan 2021 23:44:13 GMT, Martin Buchholz wrote: > 8259518: Fixes for rare test failures due to 8246585: ForkJoin updates Marked as reviewed by dl (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2015

Re: RFR: 8258217: PriorityBlockingQueue constructor spec and behavior mismatch

On Sat, 9 Jan 2021 23:41:24 GMT, Martin Buchholz wrote: > 8258217: PriorityBlockingQueue constructor spec and behavior mismatch Marked as reviewed by dl (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2014

Re: Monitoring wrapped ThreadPoolExecutor returned from Executors

From: core-libs-dev on behalf of Doug Lea Sent: Thursday, January 7, 2021 7:09 AM To: core-libs-dev@openjdk.java.net Subject: Re: Monitoring wrapped ThreadPoolExecutor returned from Executors On 1/5/21 10:11 PM, Tommy Ludwig wrote: In the Micrometer project, we provide

Re: Monitoring wrapped ThreadPoolExecutor returned from Executors

On 1/5/21 10:11 PM, Tommy Ludwig wrote: In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from

Re: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v4]

On Mon, 14 Dec 2020 00:40:08 GMT, Martin Buchholz wrote: >> 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 > > Martin Buchholz has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains one commit: > > JDK-8234131 Marked

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 >

Re: RFR: 8246585: ForkJoin updates [v3]

On Wed, 9 Dec 2020 20:20:49 GMT, Martin Buchholz wrote: >> 8246585: ForkJoin updates > > Martin Buchholz 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

Re: [jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException

On Sun, 13 Dec 2020 03:31:44 GMT, Martin Buchholz wrote: > 8254350: CompletableFuture.get may swallow InterruptedException Marked as reviewed by dl (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/17

Re: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v2]

On 12/8/20 3:56 AM, Alan Bateman wrote: 1558: break; 1559: } 1560: */ Is this meant to be commented out? Yes, but It should be marked as a possible improvement, not yet committed. While this (prestarting) would improve performance in some

Re: Possible subtle memory model error in ClassValue

Catching up... As implied in other posts, the minimal fix is to add a trailing release fence (using Unsafe?) to the constructor. Or less delicately, to access only using acquire/release (which will cost a bit on ARM/Power, but probably not noticeable on x86), or most simply (but expensively)

Re: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

On 2/6/20 12:31 PM, Martin Buchholz wrote: > lgtm > > Knuth didn't like linear probing, but memory locality became far more > important over time, favoring linear probing. (Or variants, like cuckoo, but they are unlikely to be improvements here.) > > I don't get what hash() is doing with the

Re: JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable non-transient instance fields in java.util.concurrent

These look OK to me. We could change some declared types to ConditionObject for sake of clarifying some Condition usages, but it would not be an improvement. I did notice though that ForkJoinTask doc should include a caveat that is normally the case now, but will always hold under some upcoming

Re: RFR: jsr166 integration 2019-09

quot;Martin Buchholz" > *À: *"Remi Forax" > *Cc: *"core-libs-dev" , "loom-dev" > , "David Holmes" > , "Doug Lea" > *Envoyé: *Jeudi 12 Septembre 2019 16:20:12 > *Objet: *Re: RFR: jsr166 integration 201

Re: Bug in parallel sorting of float / double

g** was that the merge of the correctly sorted sub-arrays > would correctly cause NaNs to bubble to the end as required, while > zeroes would also group - though I think I can see now that simply using > < would not correctly order NaNs relative to other values, nor order > -0.0 and +0.0

Re: RFR: 8223078: Add microbenchmark for array copying/clearing/resizing

On 4/29/19 12:39 PM, Martin Buchholz wrote: > 8223078: Add microbenchmark for array copying/clearing/resizing > https://cr.openjdk.java.net/~martin/webrevs/jdk/ArrayFiddle-jmh/ > https://bugs.openjdk.java.net/browse/JDK-8223078 > Looks good, although even more informative would be to try some

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

On 12/14/18 1:37 AM, Michal Vala wrote: > Thanks Martin for finding this serious issue and the testcase. > Sorry that I wasn't paying attention to this and so forced Martin to discover the hard way that because of LinkeHashMap, you can't skip doubling steps (at least not without a lot of

Re: Querstion about ForkJoinPool / SecurityManager interoperability

On 12/13/18 2:34 PM, Patrick Reinhart wrote: > Should I prepare a webrev for this change? No, I think we are all set (thanks Martin!) https://bugs.openjdk.java.net/browse/JDK-8215359 > > -Patrick > > Am 13.12.18 um 15:15 schrieb Doug Lea: >> On 12/13/18 8:44 AM, P

Re: Querstion about ForkJoinPool / SecurityManager interoperability

On 12/13/18 8:44 AM, Patrick Reinhart wrote: > > This special case could have been handled also by the > InnocuousForkJoinWorkerThread > could in my opinion be relaxed to accept null or the system classloader > to be set > using setContextClassLoader() Thanks. We should/will do this. The

Re: Querstion about ForkJoinPool / SecurityManager interoperability

On 12/13/18 7:36 AM, Patrick Reinhart wrote: > Now the special case of using those special threads with no permission > are only created when the ForkJoinPool is initialized with a security > manager installed at this point of time. If the security manager will be > installed later, it has not

Re: Extending Java Arrays/Collection Sort API

On 11/20/18 2:50 AM, Laurent Bourgès wrote: > Hi, > Any feedback on improving Java Sort API ? I think most considerations await progress on value types. I posted some ideas and links to code last summer on Valhalla list: http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-August/thread.html

Re: Useless null check in HashMap.merge()

On 07/04/2018 09:22 AM, Zheka Kozlov wrote: > Oh yes, you are right. Then this is not dead code, just a useless null > check. My vague recollection is that the check was there to ensure that the block was identical to those in the other methods when considering ways to factor it out (none of

Re: RFR: jsr166 integration 2018-06

On 06/22/2018 01:28 PM, Paul Sandoz wrote: >> 8203864: Execution error in Java's Timsort >> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/TimSort/index.html >> https://bugs.openjdk.java.net/browse/JDK-8203864 >> > > 406 if (n > 0 && runLen[n-1] <= runLen[n] +

Re: RFR 8199435 : Unsafe publication of java.util.Properties.map

On 06/18/2018 11:22 AM, Martin Buchholz wrote: > Or better, lockField.set in resetLock could instead be setRelease. > Except it is using reflection, not VarHandles. So it could be preceded > with VarHandle.releaseFence(), although it is hard to think of a > scenario in which it

Re: RFR 8199435 : Unsafe publication of java.util.Properties.map

On 06/18/2018 10:05 AM, Martin Buchholz wrote: > There's a long history of cheating and setting final fields in > pseudo-constructors readObject and clone, which is well motivated since > Java should really support pseudo-constructors in a better way.. > Cheating has used Unsafe or reflection with

Re: Durations in existing JDK APIs

Kurt's initial post did not make it to concurrency-interest. At this point, it is probably least confusing if interested readers who aren't on core-libs-dev follow this on archives: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev On 05/30/2018 01:36 PM, Martin Buchholz wrote: >

Re: RFR 8203279 : Faster calculation of power of two

On 05/17/2018 07:07 AM, Claes Redestad wrote: > Shouldn't this be called "Faster rounding up to nearest power of two"? > > Patch looks OK to me, but I'd like to see numbers with the > numberOfLeadingZeros intrinsic > disabled so that we ensure we're not incurring an unreasonable penalty > on

Re: RFR: jsr166 jdk integration 2018-05

Sorry Stuart, but I'm joining the no-modCount barrage. To pick on the main issue... On 05/16/2018 05:21 PM, Stuart Marks wrote: > Suppose that a replaceAll() on another thread occurs, and that this is > allowed. Does the application care whether the eventual printout > contains partly new

Re: Always false expressions in ConcurrentHashMap source

On 03/16/2018 02:18 AM, Tagir Valeev wrote: > Hello! > > Experimenting with code static analysis I found several always false > expressions in ConcurrentHashMap source. See addCount method: > >

Re: RFR: jsr166 jdk10 integration wave 6

On 11/29/2017 01:43 PM, Paul Sandoz wrote: > SubmissionPublisher > -- > > 1004 // Order-sensitive field declarations > > Is this still relevant Not really; layout is now discussed in class-level doc. Removed. Thanks. > > 81 * A single SubmissionPublisher may be shared among multiple

Re: ThreadPoolExecutor and finalization

On 10/31/2017 04:55 AM, David Holmes wrote: > > In 2006 we added the docs about it being unreferenced and no remaining > threads - which I guess is a necessary condition for finalization to now > occur. But as you noted at that point shutdown() is pretty much a no-op. > > Maybe Doug (cc'd) can

Re: AVL tree implemented in the style of TreeMap for better performance

On 10/18/2017 06:35 PM, David McManamon wrote: > > https://github.com/dmcmanam/bbst-showdown > > Although an old topic, it may be worth another look in Java since AVL trees > do much better in some circumstances. (And possibly worse in others.) As you note on the above page, it may be the case

Re: RFR: jsr166 jdk10 integration wave 3

On 09/27/2017 02:38 PM, Paul Sandoz wrote: >> Looks good, i just need to look a little more closely at the >> ConcurrentSkipListMap changes. >> > > > 328 * Note that, with VarHandles, a boolean result of > 329 * compareAndSet must be declared even if not used. > This should not be

Re: Long.bitCount micro-optimization

On 05/08/2017 02:14 PM, Isaac Levy wrote: Original message below: The JDK impl of bitCount can be improved -- though most users will get the hotspot intrinsic. The best source I could find for the suggestion below is page 195: http://support.amd.com/techdocs/25112.pdf The int version differs

JDK 9 VarHandle memory mode usage guide

[Reposting from concurrency-interest list] As may recall, JDK 9 VarHandles with new memory modes were incorporated without a full overhaul of the Java Memory Model that would be needed to formally specify them. For the past year or so I've been sporadically working on an expert-programmer

Re: RFR 9: 8165641 : Deprecate Object.finalize

On 03/12/2017 07:55 PM, Hans Boehm wrote: But I think we agree that it doesn't matter for this discussion; neither of these problems are addressed by deprecating finalizers. PhantomReferences have exactly the same issues. ... The motivation seems more along the lines of "denigration" vs

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

On 02/21/2017 06:36 AM, Pavel Rappo wrote: Only if you want an answer from the concurrency uber geeks :-) There seems to be no need for a further answer anyway! Thanks for pointing out that Subscription.request must be called to receive any items, and given this, the example works as

Re: RFR 8160710: Enable Thread to grant VarHandle field access to ThreadLocalRandom/Striped64

On 01/11/2017 06:39 PM, Martin Buchholz wrote: Doug, please try to remember the details of the thread group code. > > The threadgroup creation code that uses cheating has always seemed fishy to me. The straightforward > > /** > * Returns a new group with the

Re: RFR: jsr166 jdk9 integration wave 13

On 12/15/2016 01:17 PM, Stefan Zobel wrote: I recently noticed that javac creates a synthetic class and a bridge constructor for SubmissionPublisher.ThreadPerTaskExecutor because its generated constructor is private. I don't know if it really matters but that could be avoided by declaring a

Re: RFR: jsr166 jdk9 integration wave 13

On 12/15/2016 07:36 AM, Stefan Zobel wrote: SubmissionPublisherTest, line 420: "s1.awaitSubscribe();" I might be wrong, shouldn't this be "s2.awaitSubscribe();"? Thanks. Changed. Using s1 on that line wasn't wrong, but wasn't intentional. (The first use of s1 catches error-before-subscribe;

Re: RFR 8169808 Stream returning methods should specify if they are late binding

Spliterator.NONNULL | +Spliterator.SIZED | +Spliterator.SUBSIZED); } On Wed, Nov 23, 2016 at 6:14 AM, Doug Lea <d...@cs.oswego.edu <mailto:d...@cs.oswego.edu>> wrote: On 11/22/2016 08:33 PM, Martin Buchholz wrote: PriorityBlocki

Re: RFR 8169808 Stream returning methods should specify if they are late binding

On 11/22/2016 08:33 PM, Martin Buchholz wrote: PriorityBlockingQueue has a late-binding-style, snapshot spliterator that does not report IMMUTABLE. It *is* immutable ... after the first access! Should we add IMMUTABLE? Probably not. This might overly constrain future improvements; for

Re: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue

On 11/21/2016 03:52 PM, Paul Sandoz wrote: Hi, Please review specification clarifications to PriorityQueue and PriorityBlockingQueue for the spliterator. Ordinarily i would not specify what spliterator characteristics are not reported, but in this case given what is said about iterator I

Re: RFR: jsr166 jdk9 integration wave 12

(same transformation for ArrayDeque(int)). And you can remove all the casts to E and the corresponnding SuppressWarnings and remove the method elementAt. Rémi - Mail original - De: "Martin Buchholz" <marti...@google.com> À: "core-libs-dev" <core-libs-dev@

Re: RFR: jsr166 jdk9 integration wave 12

On Thu, Nov 17, 2016 at 12:03 PM, Paul Sandoz > wrote: Semaphore — 633 /** 634 * Acquires and returns all permits that are immediately available. 635 * Upon return, zero permits are available.

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

On 11/09/2016 03:32 AM, Remi Forax wrote: We should really lock Doug Lea and a GC guy in a room and only release them when they have produce a java.util.EphemeronHashMap (or maybe something which doesn't implement the whole Map contract but only put and get), using a WeakHashMap

Re: Documentation for ForkJoinPool class

On 11/02/2016 11:27 AM, David Holmes wrote: Moving discussion to core-libs-dev. Please follow-up there. Thanks, David On 3/11/2016 1:20 AM, Dmitry Zhikharev wrote: Hi! ForkJoinPool class documentation says nothing about it using daemon threads since Java 8

Re: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain

On 08/30/2016 06:52 PM, Paul Sandoz wrote: I still think it’s kind of sneaky to substitute, especially because of propagation to wrapping classes such as AtomicDoubleArray. Doug, not sure you care enough to have an opinion :-) but i might as well ask, do you? Not a strong one, but I don't

Re: Exceptional behavior of parallel stream

On 08/17/2016 09:01 AM, Tagir F. Valeev wrote: Hello! I found no information in Stream API documentation on how it behaves in case if exception occurs during the stream processing. While it's quite evident for sequential stream (stream processing is terminated and exception is propagated to the

Re: RFR: jsr166 jdk9 integration wave 7

On 07/07/2016 10:06 AM, Peter Levart wrote: Why the naming wasn't more like the following: No matter which conventions you choose here, some people will be unhappy or confused. The current scheme seems to make the current users of both Unsafe and AtomicX least unhappy or confused.

Re: RFR: jsr166 jdk9 integration wave 7

On 06/30/2016 10:08 AM, Paul Sandoz wrote: Hi Peter, Thanks, that’s interesting. I am uncertain if our 166 fellows will be reluctant or not to pull in a dependency on jdk.internal.misc.SharedSecrets. Background: we are reluctant to rely on anything that makes sources impossible to use in

Re: Semantics of VarHandle CAS methods

On 06/30/2016 06:38 AM, Martin Buchholz wrote: It's not only about naming. So yes, I'd like the name weakCompareAndSet to be the sequentially consistent version, BUT I'd also expect the next more relaxed version to be memory_order_acq_rel which we don't provide. There are a few flavors of C++

Re: RFR: jsr166 jdk9 integration wave 7

On 06/29/2016 01:28 PM, Peter Levart wrote: I see it was intentional as it is described in the docs... Is new behavior better? In tests so far, I see smaller variances, and approximately same average, so yes, a little better. Other usages of onSpinWait probably have more effect than this one

Re: RFR: jsr166 jdk9 integration wave 7

Responding to ForkJoinPool reviews (thanks for these!)... On 06/29/2016 06:41 PM, Martin Buchholz wrote: It may be better if the common pool and other pools are configured the same way, by having a maxSpares parameter instead of a maximumPoolSize parameter. The choice was between being

Re: RFR: jsr166 jdk9 integration wave 7

On 06/28/2016 12:38 PM, Martin Buchholz wrote: On Tue, Jun 28, 2016 at 5:55 AM, Paul Sandoz > wrote: You can use VALUE.addAndGet same for other similar methods here and in other classes. Done: And, amazingly, not in conflict

Re: RFR(s): 8154801 deprecate java.util.Observable/Observer

On 04/21/2016 10:17 PM, Stuart Marks wrote: Hi all, Here's a small proposal to deprecate the java.util.Observable and Observer. This deprecation will not be for removal. These days, anyone encountering these is probably hitting them by mistake while using RxJava or other reactive-stream

Re: RFR 8151198: VarHandle factory-specific exceptions

order" normally requires a compiler fence. Most people don't know what a compiler fence is though, and it is not especially easy to define. So I don't think this would help. -Doug On Saturday, April 9, 2016, Doug Lea <d...@cs.oswego.edu <mailto:d...@cs.oswego.edu>> wrote:

Re: RFR 8151198: VarHandle factory-specific exceptions

On 04/08/2016 02:39 PM, Hans Boehm wrote: My prior impression was that Opaque was intended to be similar to a C++ memory_order_relaxed access to a variable that is declared as both atomic and volatile, with the unordered interpretation of C++ "volatile". Yes. This is awkward to spell out in

Re: RFR: jsr166 jdk9 integration wave 6

On 04/07/2016 11:29 AM, Paul Sandoz wrote: I am struggling to square the CF updates to the test. AFAICT the cleaning of a CF stack is now less aggressive. A dependent’s stack stack will now only be cleared if it has not completed (rather than if also the computation is nested). Thus in

Re: RFR: jsr166 jdk9 integration wave 6

On 04/03/2016 06:17 PM, fo...@univ-mlv.fr wrote: De: "Martin Buchholz" http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ aka introducing a new constructor seems to be a regression to me, the less overloads we have the better

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

On 03/31/2016 05:14 PM, Dohrmann, Steve wrote: This is a JDK 9 proposal to support allocation of direct java.nio.ByteBuffer instances backed by memory other than off-heap RAM. I like it. Various kinds of heterogeneous memories are becoming more common, and this seems like the simplest

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 02/23/2016 04:30 PM, Vitaly Davidovich wrote: Why not drop the (superfluous, IMO) "on" prefix while you're changing the receiver? Because then it reads as if the method itself is doing a spinWait. "onSpinWait" is the only proposed name that no one has said they cannot live with. So, live

Re: API review of VarHandles

On 01/22/2016 04:51 AM, Andrew Haley wrote: On 22/01/16 00:01, Vitaly Davidovich wrote: I think the get/setOpaque methods need a bit more explanation ("opaque" is an odd naming choice, IMO). Specifically, it says the operations are done in program order but have no effect on inter-thread

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

On 12/16/2015 05:53 PM, Aleksey Shipilev wrote: Hi, Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as package-private volatile fields. Their only use is to cache keySet and valueSet implementations from java.util collections. I think these were declared volatile to be

Re: RFR: jsr166 jdk9 integration wave 2

On 12/02/2015 07:51 PM, Martin Buchholz wrote: We're stuck. Peter wants to make Throwables cloneable, I want to reverse the order of throwables and add the past Throwable as a suppressed exception to the exception of a dependent action, and Doug wants the current webrev behavior of adding the

  1   2   3   4   >