ARM: a very small change.

[Andrew Dinn]

On 28/05/12 13:00, Andrew Haley wrote:
> atomic_copy64 is used by Object.clone().  It's used instead of
> memcpy() because otherwise a copy might be interrupted partway
> through copying a jlong.  We were using the generic code on ARM,
> but we really should make sure we use an atomic load.  This only
> really matters on multi-core ARMs; on others the 64-bit read is
> restarted after an interrupt.

This patch looks fine and built ok.

I tested it by running a program which set multiple threads off cloning
a shared object and then rewriting a volatile long field of the shared
original with one of two distinct values (distinct both in their upper
and lower words). After each clone call the cloned object is tested to
ensure that the long field has one of the two legitimate values rather
than some half-baked hybrid.

This test exercises object cloning (which is the important thing).
Also,-- even when the threads run for many 10s of seconds -- it has a(n
almost vanishingly small) probability of exercising the clone at a point
where a timer interrupt might coincide with a copy of the long field.

Anyway the patched code  passed the test for what that is worth. Ship it.

regards,


Andrew Dinn
-----------