Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7100935

win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations

XMLWordPrintable

    • b03
    • x86
    • windows
    • Verified

        http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-October/002473.html

        Axel Siebenhorn reports:

        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 added a small test, where a second java thread reads from the array, 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.
        Volker Simonis reports:

        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!

              kvn Vladimir Kozlov
              dholmes David Holmes
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: