Compressed oops are copied bytewise on windows amd64.

[David Holmes]

On 14/10/2011 12:05 AM, Siebenborn, Axel wrote:
>> 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.

Ok - but the  problem is the basic non-atomicity of memmove as it 
relates to conjoint_jints_atomic - right? Given an oop is a multi-word 
entity the overall copy will not be atomic anyway.

> 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.

AFAICS memmove is defined to do byte-copies so anything larger than a 
byte is just an optimization. Seems memmove should never have been used 
for an atomic copy.

I'll file a bug for this.

>> 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.

Yes lots of assembler on all other x986 platforms but not on Windows.

Thanks,
David
-----

> Axel