RFR: jsr166 jdk9 integration wave 7

[Peter Levart]

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