RFR (S): Supporting VM operations
Jean Christophe Beyler
jcbeyler at google.com
Tue May 14 19:11:11 UTC 2019
Hi all,
Here is a webrev that adds a bit of logic to get the VM operation supported
and not provoke false positive races:
http://cr.openjdk.java.net/~jcbeyler/vm_operation/
The backstory to this is:
- When a thread is going to do certain JVMTI operations (or other btw),
it can do a VM operation. When this happens, there might be a callback into
user code which could change the state of the user memory.
- If this happens, TSAN did not see that the thread actually has
passed owner ship to the VM thread via a vm event queue and wait
- To solve this, the best solution I have found is to tell TSAN of the
thread memory via an acquire/release on the thread object itself
This thus becomes (note all mentions of locking below are fictitious and
just calls to TSAN to make it believe all is well in the world):
- A thread running has a "lock" on its on JavaThread object
- When it is going to wait for a VMThread to do something (including do
a callback) it relinquishes its "lock" and then waits (if the operation is
concurrent)
- Then the VM thread gets that "lock" and does its operation; including
doing callbacks
- When the VM thread is done, it relinquishes the "lock" again and the
JavaThread can acquire it back
This in essence does seem to work, the JvmtiTaggerTest no longer requires a
user lock on its own memory. The down-side is that now we have to track
this thread "lock" and I had to instrument the start of a thread.
Thanks,
Jc
More information about the tsan-dev
mailing list