Compressed oops are copied bytewise on windows amd64.
david.holmes at oracle.com
Fri Oct 14 02:20:35 PDT 2011
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
>>> 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.
More information about the hotspot-runtime-dev