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) t

Re: Bug in parallel sorting of float / double

standing** 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.

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: 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 c

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 lo

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 scenarios

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: 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 con

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 > compa

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 a

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 `ThreadPoolExe

Re: Monitoring wrapped ThreadPoolExecutor returned from Executors

Jason From: core-libs-dev on behalf of Doug Lea Sent: Thursday, January 7, 2021 7:09 AM To: [email protected] Subject: Re: Monitoring wrapped ThreadPoolExecutor returned from Executors On 1/5/21 10:11 PM, Tommy Ludwig wrote: In the Micrometer project, we pr

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: 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: 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: [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: 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: 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

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&pr=2661&rang

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:

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 version I

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:

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: https://webrevs.openjdk.java.net/?repo=jdk&pr=332

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 Runtim

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: 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 java.u

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: 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 https://bugs.openjdk.java.net/browse/JDK-8

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 > https://bugs.openjdk.java.net/brows

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: 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

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 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 wit

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 [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]

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 [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 typos;

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]

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

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. -

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 s

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 original ve

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&pr=8577&ran

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

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 { >> } >> >> public

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 [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 [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 [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

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/

ArrayList.subList

While puzzling over why one of the demo videos on ForkJoin out there required surprisingly high sequential thresholds, I noticed that ArrayList.subList creates lists with per-access overhead proportional to the sublist depth. Which is not at all conducive to recursive use. Does anyone know any re

Re: ArrayList.subList

fashion that iterations in progress may yield incorrect results.) On Jul 28 2011, at 13:40 , Doug Lea wrote: While puzzling over why one of the demo videos on ForkJoin out there required surprisingly high sequential thresholds, I noticed that ArrayList.subList creates lists with per-access o

Re: ArrayList.subList

On 07/28/11 19:20, Doug Lea wrote: Thanks. I hadn't noticed that the parenthesized "i.e., this list" in the List specs (http://download.oracle.com/javase/7/docs/api/java/util/List.html#subList%28int,%20int%29 -- pasted below) overly constrains the interpretation of "backin

Re: ArrayList.subList

On 07/29/11 06:34, Doug Lea wrote: As a bandaid, a faster but still compatible path for simple get/set operations on ArrayList.subList could be put in at the expense of adding a a few extra fields. I should have checked before posting -- exactly this bandaid already exists in current version

Re: DelayQueue is not Serializable?

On 09/20/11 12:29, Aleksey Shipilev wrote: Hi, I've been stumbled upon this for a bit. Is there any specific reason DelayQueue is not serializable? Or is it an API bug? The backing PriorityQueue *is* serializable. It was a deliberate decision. DelayQueues use relative times, so the delays don

Re: DelayQueue is not Serializable?

On 09/21/11 05:17, Aleksey Shipilev wrote: On Wed, Sep 21, 2011 at 1:12 PM, Aleksey Shipilev wrote: On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea wrote: From the code perspective, it appears to be point change. I take that assertion back. I understand the Delayed elements which are using

Re: Code Review 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero

On 09/22/11 17:45, David Holmes wrote: Sorry Doug/Chris I should have seen this previously, the order here is wrong: 1552 void ensurePrestart() { 1553 int wc = workerCountOf(ctl.get()); 1554 if (wc == 0) 1555 addWorker(null, false); 1556 else if (wc < corePoolSize) 1557 addWorker(null, true); 15

Re: JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post

On 10/05/11 03:53, Kasper Nielsen wrote: On 05-10-2011 05:08, Andrew Thompson wrote: So is there any convergence between these ideas? Should we be thinking about adding a default ForkJoinPool to the platform, or should we be thinking about adding a default ExecutorService to the platform, Ther

Re: RFR 7117360: Warnings in java.util.concurrent.atomic package

On 12/02/11 09:25, Chris Hegarty wrote: Cleanup compiler warnings in the java.util.concurrent.atomic package. This is a sync up with the raw type warning fixes in Doug's CVS, along with some minor style cleanup. With this change there are still 2 outstanding unchecked casts in AtomicReferenceAr

Re: RFR 7118066: Warnings in java.util.concurrent package

On 12/05/11 12:54, Maurizio Cimadamore wrote: http://cr.openjdk.java.net/~chegar/7118066/webrev.00/webrev/ -Chris. P.S. I have already reviewed this, and the contribution is of course from Doug. Nice work! Some comments below: Thanks for looking at this! In both cases, reducing warnings woul

Re: RFR 7118066: Warnings in java.util.concurrent package

Thanks for all the comments. We changed to having the annotations on their own lines (even though it furthers the Java tendency of gratuitously occupying too much vertical space :-). Thanks to Chris for explaining why we didn't incorporate some of the other suggestions. Also ... - you added: *

Re: RFR 7118066: Warnings in java.util.concurrent package

On 12/08/11 23:16, David Holmes wrote: Maybe we still need something that tests SynchronousQueue to verify its iterator is indeed empty. Bear in mind that we have all the tck tests for j.u.c, that cover such things. The JCK folks at Oracle regularly run them. In general, we use jtreg tests in

Re: CFV: New core-libs Group Member: Brian Goetz

Vote: yes It's weird that Brian was not already on this. Also David Holmes? On 01/05/12 07:39, Alan Bateman wrote: I hereby nominate Brian Goetz to membership of the core-libs group. Brian doesn't need too much introduction. He's lead for OpenJDK's Project Lambda, and while this project is sp

Re: CFV: New core-libs Group Member: David Holmes

Vote: yes. I guess I should have given you a few minutes to put out this CFV before asking about it :-) On 01/05/12 08:08, Alan Bateman wrote: I hereby nominate David Holmes to membership of the core-libs group. David doesn't need too much introduction. He is a reviewer on several OpenJDK proj

Re: 100218: BigInteger staticRandom field

On 01/05/12 01:02, Bill Pugh wrote: So I think the right thing to do is to abandon the original patch, and instead make the following changes: * add the following method to BigInteger public boolean *isProbablePrime*(int certainty, Random end) , which allows primality testing wi

Re: RFR 7132378: Race in FutureTask if used with explicit set ( not Runnable )

Sorry for delay; swamped... On 01/24/12 06:00, Chris Hegarty wrote: I don't understand the purpose of handlePossibleCancellationInterrupt. Given it doesn't clear the interrupt state why does it need to wait? Yes, this is true. I can't see any need for it to wait now since it doesn't clear the

Re: RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List)

On 02/22/12 21:44, David Holmes wrote: I'm not a fan of collections containing themselves, but I think it is simple to fix contains(o)/contains[Key]|[Value](o) and remove(o) in a similar way. Though none of the wrapped collections currently handle that case, so I'm okay with not addressing this

Re: Asking about the interesting behaviours of TreeMap.putAll

On 03/05/12 05:53, David Holmes wrote: Charles, I just realized that your webrev is for Map not AbstractMap and that it is Map the states putAll does a put() on each entry. No, Map says: The effect of this call is equivalent to that of calling put(k, v) on this map once for each mapping from

Re: RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently

On 03/26/12 23:04, Chris Hegarty wrote: David, Doug, This test has been failing intermittently on jdk7u-dev and jdk8 for a while now. It only appears to fail when run in our internal build/test system (JPRT). I believe the cause of the failure to be simply that the machines the test is run on a

Re: RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently

ust delay but need not re-interrupt. -Doug David The solution is to retry the interrupt if we know the target thread hasn't thrown anything. http://cr.openjdk.java.net/~chegar/6963841/webrev.01/webrev/ -Chris. On 27/03/2012 11:58, Doug Lea wrote: On 03/26/12 23:04, Chris Hegarty wrote

Re: RFR 6963841: java/util/concurrent/Phaser/Basic.java fails intermittently

ing, right? Yes. -Doug -Chris. -Doug David The solution is to retry the interrupt if we know the target thread hasn't thrown anything. http://cr.openjdk.java.net/~chegar/6963841/webrev.01/webrev/ -Chris. On 27/03/2012 11:58, Doug Lea wrote: On 03/26/12 23:04, Chris Hegarty wrot

Draft j.u.c JEP

Author: Doug Lea Organization: SUNY Oswego Created: 2012/4/21 Type: Feature State: Draft Exposure: Open Component: core/lib Scope: SE Discussion: [email protected] Template: 1.0 Summary --- In addition to features in support of lambdas, we plan inclusion for OpenJDK8 of a few

Re: Draft j.u.c JEP

On 04/21/12 13:10, Brian Goetz wrote: My only concern is the mention of a "fences" API; I would think that this might rise to the level of wanting its own JSR, since the memory model does not necessarily provide for the all various relaxed consistency modes that such an API would seem to imply, a

Re: RFR: 7103570 AtomicIntegerFieldUpdater does not work when SecurityManager is installed

On 04/27/12 00:47, David Holmes wrote: Due to a problem with jtreg and the installation of a security manager I've had to modify the test to install the security manager itself. updated webrev: http://cr.openjdk.java.net/~dholmes/7103570/webrev.02/ Looks OK, although the main sources seems t

Re: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps

On 05/24/12 15:34, Mike Duigou wrote: Hello All; I have updated the webrevs for alternative hashing for String [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ Not that it matters at all since they will be changed anyway for JDK8 CHM, but all of the Conc

Re: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps

On 05/29/12 17:25, Mike Duigou wrote: An intrinsic and/or native version might be added later if it turns out that the Java murmur3 implementation is a performance bottleneck. I don't think that going native will make much difference. The main disadvantages of using Murmur3 for char[]s are tha

Re: hg: jdk8/tl/jdk: 7126277: Alternative String hashing implementation

On 05/31/12 12:58, Mike Duigou wrote: So couldn't method hash(Object) be moved to AbstractMap? The differences in the avalanche (XOR scrambling) preclude this. It could be decided for Java 8 to use a consistent scrambling implementation. I would want to hear from Doug Lea whether he t

Re: HashMap bug for large sizes

On 06/01/12 05:29, Kasper Nielsen wrote: Hi, I don't know if this has been discussed before. But I was looking at the HashMap implementation today and noticed that there are some issues with very large sized hashmaps with more then Integer.MAX_VALUE elements. I think this arose on this list (o

An Alternative Hashing Alternative

I just posted the following to the concurrency-interest list. I'll send a follow-up on tie-ins to core-lib issues next. ... Finally acting on an old idea, I committed an update to ConcurrentHashMap (currently only the one in our jdk8 preview package, as jsr166e.ConcurrentHashMap8) that much mo

Re: An Alternative Hashing Alternative

On 06/06/12 12:22, Doug Lea wrote: I just posted the following to the concurrency-interest list. I'll send a follow-up on tie-ins to core-lib issues next. The main issue is whether adding generic overflow-handling techniques to hash table classes (as used here for ConcurrentHashMap

Re: An Alternative Hashing Alternative

On 06/06/12 13:09, Rémi Forax wrote: I haven't read the whole code (I need a blackboard :) (The mostly-non-blocking retries here lead to a lot of code sprawl. Macros would help :-) I wonder if it's not better to use unsafe.tryMonitorEnter() instead of a lock bit. I need a lock with a form o

Re: An Alternative Hashing Alternative

On 06/06/12 15:03, Rémi Forax wrote: tryMonitorEnter is the equivalent of tryLock for synchronized block (monitorEnter/monitorExit). Sorry; yes. This method exists, but seems to be designed to only be used in unusual situations. So the performance is dreadful on JVMs I've tried it on. Working o

Re: JEP 155: Concurrency updates (jsr166e)

On 06/18/12 17:34, David M. Lloyd wrote: On 06/18/2012 04:12 PM, [email protected] wrote: Posted: http://openjdk.java.net/jeps/155 - Mark Might Doug's two-field atomic operations support idea possibly be a part of this (i.e. make it in time for Java 8)? I think it is unlikely for JD

Re: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads

On 06/21/12 11:59, Jim Gish wrote: Please review the proposed spec change to StringBuffer below, which informs the user about additional thread safety issues as described in the bug. (Thanks to Brian for the language). Brian: Nice wording! It misses mentioning the constructor StringBuffer(CharS

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

Rémi Forax wrote: Hi Dan, I'm not sure to like the fact that you introduce some local variables just to get ride of some warnings given that Hotspot compilers are sometimes sensitive to that. I think this practice should be discussed on this list before committing this changeset. Yes. We

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

Vitaly Davidovich wrote: So it sounds like avoiding these locals is basically trying to work around current compiler limitations, rather than something more fundamental. If javac did even a smidgen of optimization, this problem would also go away. I'm also curious if someone has actually n

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

Vitaly Davidovich wrote: I figured you did, but wanted to check. :) So the perf hit was with c2 compilation? Were you able to check the assembly (or enable inlining printing in hotspot) and see that lack of inlining (and whatever further opto that enabled) was the difference by simply adding

Re: c.toArray might (incorrectly) not return Object[] (see 6260652)

David Holmes - Sun Microsystems wrote: Florian Weimer said the following on 05/22/09 14:46: It's there, but not in the documentation for toArray(): | Note that toArray(new Object[0]) is identical in function to toArray().

Re: c.toArray might (incorrectly) not return Object[] (see 6260652)

David Holmes - Sun Microsystems wrote: Thanks for the info, one query though ... Ummm why didn't it just use: elementData = c.toArray(new Object[c.size()]); Because "c" might be a concurrent collection, so you don't want to independently call c.size(). Notice that AbstractCollection corr

Re: c.toArray might (incorrectly) not return Object[] (see 6260652)

David Holmes - Sun Microsystems wrote: Doug Lea said the following on 05/22/09 21:31: David Holmes - Sun Microsystems wrote: Thanks for the info, one query though ... Ummm why didn't it just use: elementData = c.toArray(new Object[c.size()]); Because "c" might

Re: Faster HashMap implementation

Alex Yakovlev wrote: Hello, While playing with scala programming language I've come to a HashMap implementation that appears to be faster than current java.util.HashMap, also with a lower memory footprint. This is a promising approach. The indirection using the index array makes for a bett

Re: Faster HashMap implementation

Alex Yakovlev wrote: Doug, I've finished HashMap, HashSet, LinkedHashMap, and LinkedHashSet porting to my approach. I run several tests I've found in jdk/test/java/util/* that are directly related to these classes, not sure I've found all of them. There are a lot of tests around for HashMap

Re: Faster HashMap implementation

A few notes on your implementation... Alex Yakovlev wrote: Main trick is in storing all data in 2 arrays without any HashEntry objects. One is array of Objects with keys and values, another in a complex array of indices. Notice that footprint comparisons with current HashMap are load-depen

Re: Faster HashMap implementation

Florian Weimer wrote: Or don't use the hash structure at all and just do a sequential search. Then the index array isn't needed at all. It is possible to use a look-aside strategy for tiny HashMaps. I think one of the Apache commons maps does this. But the idea of using open-address tables to

Re: Faster HashMap implementation

Alex Yakovlev wrote: entrySet() iterator which is very expensive. Very big speedup would be to reuse Entry object, We had originally done this in a few classes. The Iterator spec even allows it. However, most usages ignore that part of the spec, and it led to a bunch of bug reports, so now all

Re: HashMap - Hybrid approach

Alex Yakovlev wrote: To have single-indirect access we need to read key/value objects with the first array read. Backing up a little, there are five main forces in hash table design. These are fresh in my mind because I've been trying to put together CustomConcurrentHashMap, the last planned JS

Re: HashMap - Hybrid approach

Alex Yakovlev wrote: I thought about tree-like structures for collisions, but what came to my mind is that the problem is not in search depth that can be reduced by non-linear structures, but in memory fragmentation. There were three reasons I suggested tries for collisions (1) to remove a dep

Re: HashMap - Hybrid approach

Alex Yakovlev wrote: This suggests a different sort of tactic for helping with indirections and prefetches. Suppose that index[h] was usually just h; that is, with the key in elements[2*h]. I did a little test of this and saw no performance gain, I even posted a link to sources right after ch

Re: Faster HashMap implementation

Ismael Juma wrote: Out of curiosity, do you know if any tests have been done with an open addressing scheme similar to Python dictionaries[1] in Java? Near the top, there's a comment explaining how it works and the motivation. More or less. This is roughly similar to the schemes I mentioned a

Re: Faster HashMap implementation

Sorry for the delay; I've been side-tracked exploring concurrent trie/hash algorithms But I did want to point out a problem shared with all purely table-based approaches, including yours. Assuming power of 2 capacities, you can only hold up to 1 << 29 entries, because max power of 2 array length

  1   2   3   4   5   >