Compressed oops are copied bytewise on windows amd64.

[Volker Simonis]

Oh, it's not just Windows. Just try the attached test on Solaris/SPARC
like this:

java -Xint  ArraycopyTest

Depending on your machine, you'll see more or less errors.
The program does unaligned short array copies which suffer from the
same memmove problem.
In the case of short arrays that only leads to incorrect results and
not to crashes - but thats bad enough!

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

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ArraycopyTest.java
Type: text/x-java
Size: 1071 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111014/91dd9e47/ArraycopyTest.java