Closed chacon01 closed 4 years ago
Agree. This could be fixed in several ways. What is the most appropriate option to match with likely JVM behavior across many platforms? __atomic_store_n(dest, val, __ATOMIC_RELEASE)
?
Changing it to have
WRITE_MEM_BARRIER;
*dest = val;
would be sufficient, although would not necessarily be the most performant on architectures that have dedicated instructions to store with release semantics. I think __atomic_store_n(dest, val, __ATOMIC_RELEASE)
is the right way to fix this.
The
release_store_thread
functiondoes not provide release semantics. When this is inlined into
jvmObjectMonitorExitEpilog
, it permits the store toomonitor->_succ
to be visible after the store toomonitor->_owner
, which violates what is expected in the JVM code.