RFR: jsr166 jdk9 integration wave 7

[Doug Lea]

On 06/29/2016 01:28 PM, Peter Levart wrote:
> I see it was intentional as it is described in the docs...
>
> Is new behavior better?

In tests so far, I see smaller variances, and approximately same average,
so yes, a little better. Other usages of onSpinWait probably have more
effect than this one in StampedLock.

-Doug

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