-
Bug
-
Resolution: Fixed
-
P2
-
7
-
b03
-
x86
-
windows
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2216404 | 8 | Vladimir Kozlov | P2 | Closed | Fixed | b11 |
JDK-8037373 | 7 | Mattis Castegren | P2 | Closed | Duplicate | |
JDK-8017361 | 6u65 | Andreas Eriksson | P2 | Closed | Fixed | b01 |
JDK-2215972 | 6u60 | Andreas Eriksson | P2 | Closed | Fixed | b01 |
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!
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!
- backported by
-
JDK-2215972 win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations
-
- Closed
-
-
JDK-2216404 win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations
-
- Closed
-
-
JDK-8017361 win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations
-
- Closed
-
-
JDK-8037373 win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations
-
- Closed
-
- duplicates
-
JDK-8037373 win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations
-
- Closed
-