[concurrency-interest] backport: AtomicLongFieldUpdater support

[Dawid Kurzyniec]

Moran Or Avigdor wrote:

> Dawid,
> Thank you for your feedback.
>
> Isn't the reflection done only once per newUpdater call?
> If a LockedUpdater is supplied then the synchronization should work 
> well for its implications.
>
> Although it is not correct to state that on JDK1.4 the underlying JVM 
> doesn't supports lockless CompareAndSet for longs, but the
> effect will return the needed Updater.
>
> Am I missing something in my assesment?
> Am I correct to assume that the LockedUpdater should suffice?
>
I was thinking of something along the lines of the older JSR 166 
emulation code:

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/emulation/java/util/concurrent/atomic/AtomicLongFieldUpdater.java

but it requires, in the best case, two reflective calls 
(Field.getLong/Field.setLong) per an operation. It may be interesting to 
test that and see how much overhead that would cause (reflection has a 
fast path for unchecked accessor methods), but Doug's comments suggest 
that they've tried it and it was not good.

On the other hand, you're suggesting using sun.misc.Unsafe. This may be 
quite an interesting idea. The backport already uses sun.misc.Perf for 
microsecond-precision timer, if the class can be found, and otherwise 
falling back to System.currentTimeMillis(). Maybe similar approach could 
be taken for sun.misc.Unsafe?...

On the other hand, why do you need the field updater in the first place? 
Chances are, you have a non-blocking algorithm that you want to port to 
1.4. It is usually quite easy to modify such algorithms to use 
synchronization instead of atomic field updaters. Example of this is 
ConcurrentSkipListMap and some other classes in j.u.c. that I've 
backported this way.

(Technically, the algorithm is non-blocking no more, but the locks are 
held so briefly that it retains very high scalability, for the price of 
higher single-thread execution overhead.)

Regards,
Dawid