Compressed oops are copied bytewise on windows amd64.

[Siebenborn, Axel]

Hi David,

> 
> Hi Axel,
> 
> On 13/10/2011 5:24 PM, Siebenborn, Axel wrote:
> > on windows-amd64 the interpreter copies compressed oops using
> memmove.
> >
> > However, memmove is not thread safe and might copy bytewise.
> >
> > Another thread can see a partly copied compressed oop.
> 
> I'm not seeing the connection with compressed oops here.

Compressed oops are copied using pd_conjoint_jints_atomic. This function copies using memmove on Windows. Uncompressed oops are copied using a copy loop, similar to my suggested fix. 

> > I added a small test, where a second java thread reads from the
> array,
> > while the first copies.
> >
> > The second thread could also be the parallel marking of the CMS.
> >
> > I prepared the following webrev:
> >
> > http://www.sapjvm.com/as/webrevs/atomic_array_copy/
> >
> > The suggested fix replaces the memmove by a simple copy loop.
> 
> How is the copy loop any more "atomic" than the memmove ? I confess I'm
> having trouble understanding what the "atomic" refers to in these
> functions.

The problem of memmove is that it copies byte per byte until it reaches an
alignment of 8 bytes. After that it copies 64 bits. In the context of these functions, atomic means, that a 32 bit value is copied using 32 bit load and store instructions. To use a copy loop written in c++ implies, that the c++ compiler doesn't generate code that stores (aligned) values not atomically.  

> 
> That said I think win-x64 should do the same as linux-x64 and presently
> they differ (perhaps a tool issue, I'm not sure)
> 

On linux the copy functions are implemented using assembler. I'm not an expert of the windows tool chain. I don't know if it's easy to do the assembler implementation here. However, the c++ loop is less error prone and portable. 

Axel