Compressed oops are copied bytewise on windows amd64.

David Holmes david.holmes at
Fri Oct 14 15:32:57 PDT 2011

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.


> Regards,
> Volker
> On Fri, Oct 14, 2011 at 12:36 PM, David Holmes<david.holmes at>  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

More information about the hotspot-runtime-dev mailing list