RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898

[Chris Hegarty]

On 01/10/2013 07:48 PM, Aleksey Shipilev wrote:
> On 01/10/2013 09:15 PM, Chris Hegarty wrote:
>> On 01/10/2013 05:05 PM, Aleksey Shipilev wrote:
>>> On 01/10/2013 08:40 PM, Chris Hegarty wrote:
>>>> Doug, Aleksey,
>>>>
>>>> I updated the appropriate methods in the Atomic classes to use the
>>>> instinsics defined by 7023898 , Unsafe getAndAddInt, getAndSetInt,
>>>> getAndAddLong, getAndSetLong, getAndSetObject.
>>>>
>>>> http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/
>>>
>>> Good. Two comments:
>>>    a) Any java-concurrency-torture [1] failures for these classes?
>>
>> Can you give me a brief introduction to running these? I have run the
>> JDK regression tests and the appropriate JCK tests, all pass.
>
> Build it, run it, see results/index.html. Should be 100% pass rate. If
> not, drill down to exact tests.

Maven has just finished downloading the dependencies to build this 
project! ;-) All tests pass.

You can probably remove the *.atomic.*V8 source and tests once these 
changes are integrated.

>
>>>    b) Can we delegate all the suitable methods to Unsafe directly, without
>>> calling the middleman (i.e. getAndDec() -> getAndAdd() -> unsafe), as in
>>> [2]?
>>
>> Yes, we could. The existing implementation was not consistent.
>>
>> I took the view that this was not performance critical, since some
>> existing methods already delegate, and my preference, for simplicity, is
>> for the middleman ;-) Do you think there is a perf benefit to changing
>> this, or is this a style issue?
>
> Yeah, that's mostly stylistic issue. If that's not in Doug's repo, you
> can just disregard this. (There is a tempting desire to not to blow up
> the call tree to help inliner, since the delegating method is not private).

I'll leave it as is, I find it much less error prone. We can revisit if 
necessary.

Thanks,
-Chris.

>
> -Aleksey.
>