RFR (S): Supporting VM operations

[Arthur Eubanks]

src/hotspot/share/runtime/vmThread.cpp:
In VMThread::execute(), would having an object that called
TSAN_RAW_LOCK_RELEASED() on construct and TSAN_RAW_LOCK_ACQUIRED() on
destruct be cleaner? That way you don't need to have the
TSAN_RAW_LOCK_ACQUIRED() in every exit path. If you did that, it could also
work with VMThread::evaluate_operation()

*From: *Jean Christophe Beyler <jcbeyler at google.com>
*Date: *Tue, May 14, 2019 at 12:12 PM
*To: * <tsan-dev at openjdk.java.net>

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
>