RFR: jsr166 jdk9 integration wave 7

[Peter Levart]

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?