Import miscellaneous maintenance on CopyOnWriteArrayList from Doug Lea's
CVS repository

Doug Lea writes:

"Those of you who had argued that for consistency, CopyOnWriteArrayList
should use use ReentrantLock, not "synchronized" will be pleased
to know that there was finally a reason to do this. A marginal
reason, but just enough to push me over the edge while
revising anyway (*): The efficiency of COWArrayList relies in part
on the ability of optimizers to specially handle the combination
of a volatile write followed by an unlock. It is possible that
in Mustang, new fast-paths for never-contended locks will not
be able to peform this optimization (but still can/will with
j.u.c locks). While the net result may still be faster with builtin
locks in some cases, it won't be in others, so it seems
marginally preferable to use RL to get more predictable performance.

On current Mustang builds (that don't have any of the new
lock stuff in them), performance is about the same with
RL vs synchronized.

The only ugly part of this is that I had to resort to sun.misc.Unsafe
hacks to bind the transient final ReentrantLock during deserialization.
It had to be transient so as to be serialization-compatible with J2SE5.
And the only way to set a transient final during deserialization is
to cheat either using unsafe or setAccessible + reflection. And the
former is a little faster (but only applies if the code is in 
bootclasspath), so I did it that way. (No, there has not been any
progress on changing serialization rules in some way that would evade
this, and I don't see any way anything will happen for Mustang.)

(*) The "revising anyway" part is to adapt to use new
array-cloning methods that will be in Mustang."


###@###.### 2005-06-08 03:16:59 GMT