-
Bug
-
Resolution: Fixed
-
P4
-
None
-
None
In UpcallLinker::on_entry we clear_pending_exception() right before transitioning from native to Java. This clears an oop on the thread that might be concurrently scanned by the GC. The GC may read the oop and update its address to a new location, without using any atomics at all (because we are in a safepoint and nobody should be messing around with it concurrently). The lack of atomics means that the following interleaving is possible:
GCThread: old_oop = JT1->_pending_exception
JT1: clear_pending_exception()
GCThread: JT1->_pending_exception = new_addr(old_oop);
Other interesting things can happen as well. But it's safe to say we shouldn't be messing around with oops in_native concurrently to GC safepoints.
GCThread: old_oop = JT1->_pending_exception
JT1: clear_pending_exception()
GCThread: JT1->_pending_exception = new_addr(old_oop);
Other interesting things can happen as well. But it's safe to say we shouldn't be messing around with oops in_native concurrently to GC safepoints.
- links to
-
Commit(master) openjdk/jdk/461ffafe
-
Review(master) openjdk/jdk/21742