-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P2
-
Affects Version/s: 8u40, 9
-
Component/s: hotspot
-
b42
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8083514 | emb-9 | Mikael Gerdin | P2 | Resolved | Fixed | team |
In JDK-8058209 I discovered that two stores separated by a call to OrderAccess::storestore were in fact incorrectly reordered by GCC, exposing a race condition and causing crashes in the G1 collector.
The suggested fix is to add a proper "compiler barrier" to the acquire() and release() functions in orderAccess_linux_x86.hpp to ensure that no compiler reordering occurs.
Something along the lines of:
static inline void compiler_barrier() {
__asm__ volatile ("" : : : "memory");
}
The suggested fix is to add a proper "compiler barrier" to the acquire() and release() functions in orderAccess_linux_x86.hpp to ensure that no compiler reordering occurs.
Something along the lines of:
static inline void compiler_barrier() {
__asm__ volatile ("" : : : "memory");
}
- backported by
-
JDK-8083514 Insufficient compiler barriers for GCC in OrderAccess functions
-
- Resolved
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
JDK-6975121 OrderAccess should use compiler intrinsics where possible
-
- Closed
-
-
-
- Resolved
-