Compressed oops are copied bytewise on windows amd64.
axel.siebenborn at sap.com
Thu Oct 13 07:05:44 PDT 2011
> Hi Axel,
> 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.
> > I added a small test, where a second java thread reads from the
> > while the first copies.
> > The second thread could also be the parallel marking of the CMS.
> > I prepared the following webrev:
> > http://www.sapjvm.com/as/webrevs/atomic_array_copy/
> > The suggested fix replaces the memmove by a simple copy loop.
> How is the copy loop any more "atomic" than the memmove ? I confess I'm
> having trouble understanding what the "atomic" refers to in these
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.
> 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.
More information about the hotspot-runtime-dev