RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 (original) (raw)
Chris Hegarty chris.hegarty at oracle.com
Thu Jan 10 17:15:47 UTC 2013
- Previous message: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898
- Next message: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
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?
-Chris.
-Aleksey. [1] https://github.com/shipilev/java-concurrency-torture/ [2] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/util/concurrent/atomic/AtomicIntegerV8.java
- Previous message: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898
- Next message: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]