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?
