I see it was intentional as it is described in the docs... Is new behavior better? Regards, Peter On 06/29/2016 07:19 PM, Peter Levart wrote:
Hi Martin,
I'm looking at changes in StampedLock. I noticed that you have consistently (in 4 places) replaced usages of the following idiom:
1044 if (LockSupport.nextSecondarySeed() >= 0) 1045 --spins;
with the following:
1056 --spins; 1057 Thread.onSpinWait();
Was that intentional? It looks almost like you thought that LockSupport.nextSecondarySeed() >= 0 is always true and that it is used just to introduce some pause into the spin loop. It is only true in roughly half of invocations as nextSecondarySeed() has the full signed int span.
Regards, Peter
On 06/27/2016 09:38 PM, Martin Buchholz wrote:
jsr166 has been pervasively modified to use VarHandles, but there are some other pending changes (that cannot be cleanly separated from VarHandle conversion). We expect this to be the last feature integration for jdk9.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
We're asking Paul to do most of the review work here, as owner of VarHandles JEP and as Oracle employee. We need approval for API changes in
https://bugs.openjdk.java.net/browse/JDK-8157523 Various improvements to ForkJoin/SubmissionPublisher code
https://bugs.openjdk.java.net/browse/JDK-8080603 Replace Unsafe with VarHandle in java.util.concurrent classes
There is currently a VarHandle bootstrap problem with ThreadLocal/AtomicInteger that causes java/util/Locale/Bug4152725.java to fail. Again I'm hoping that Paul will figure out what to do. In the past rearranging the order of operations in <clinit> has worked for similar problems. It's not surprising we have problems, since j.u.c. needs VarHandles initialized to do work, and j.l.invoke needs j.u.c. (notably AtomicInteger and ConcurrentHashMap) to do work. Maybe we need some very low-level concurrency infrastructure that does not use VarHandles, only for bootstrap?