Compressed oops are copied bytewise on windows amd64.

[David Holmes]

On 15/10/2011 1:45 AM, Volker Simonis wrote:
> Oh, it's not just Windows. Just try the attached test on Solaris/SPARC
> like this:
>
> java -Xint  ArraycopyTest

Thanks for the additional info Volker.

It was a long standing but that array copies of primitives were not 
element-wise atomic (4504054) but that was supposed to have been fixed. 
It looks like C1 and C2 were fixed but not the interpreter.

> Anyway, thank you for opening the bug. Axel will prepare a new webrev
> which also catches the Solaris case on Monday.

As Vladimir indicated preferably without templates. The changes should 
follow the basic style of the existing loop using code.

David

> Regards,
> Volker
>
>
> On Fri, Oct 14, 2011 at 12:36 PM, David Holmes<david.holmes at oracle.com>  wrote:
>> I filed:
>>
>> 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic
>> operations
>>
>> It's odd that the windows versions continued to use memmove when its use on
>> other platforms was removed for similar reasons quite some time ago.
>>
>> I was quite startled to find that your test program actually crashed the VM
>> on my 64-bit Windows system, so I bumped the priority to a P2.
>>
>> David
>>
>> On 14/10/2011 7:20 PM, David Holmes wrote:
>>>
>>> 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
>>