Compressed oops are copied bytewise on windows amd64.

[Vladimir Kozlov]

Thank you, Axel, for pointing this to us. And thank you, David, for taking care of this problem.

I just want to point that Axel suggested to use template method but I think we should not do this.  I don't know what 
Win compiler does with templates but Sun's compilers, for example, will not inline templates. I think we should just do 
the same as linux version.

And David, please, add Axel's test to Hotspot regression tests.

Thanks,
Vladimir

On 10/14/11 3:36 AM, David Holmes 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