[concurrency-interest] Array element compareAndSet

Roman Elizarov elizarov at devexperts.com
Wed Dec 17 06:02:44 EST 2008


Hello Doug!

On Tuesday, December 16, 2008 11:18:26 PM you wrote:

DL> It seems that a better way to do this is to add three
DL> methods to java.lang.reflect.Array:
DL>    compareAndSetObject(Object target, int i, Object exp, Object val)
DL>    compareAndSetInt(Object target, int i, int exp, int val)
DL>    compareAndSetLong(Object target, int i, long exp, long val)

How about volatile get/set methods? You could change
Array.getInt/setInt to work as volatile and introduce lazySet/eagerGet
for non-volatile accesses (old get/set), but that would be a semantic
change of the existing methods (although a compatible one).

The other problem with Array is that a target array is declared as
"Object" argument in its methods, and there is always a performance
penalty for a type check (Array.getInt works for short[] and byte[]
according to its javadoc).

Btw, it is strange, that java.lang.reflect.Array class is still
written via native methods instead of sun.mics.Unsafe, so it is hard
to see what it really does inside. The actual implementation is quite
scary performance-wise.

Sincerely,
Roman Elizarov

DL> This is a little delicate but ought to lead to better performance.
DL> I'll try this out under openJDK. If successful, it may be time to
DL> also allow people to evade ugly/painful AtomicXYUpdaters by
DL> adding similar methods to java.lang.reflect.Field:
DL>    compareAndSetObject(Object target, Object exp, Object val)
DL>    compareAndSetInt(Object target, int exp, int val)
DL>    compareAndSetLong(Object target, long exp, long val)
DL> It will a few weeks at best before I can report on enough
DL> experience to decide to argue for Java7 inclusion.

DL> -Doug





Sincerely,
Roman Elizarov



More information about the Concurrency-interest mailing list