RFR (S): Supporting VM operations

[Man Cao]

I don't think this approach fixes all the issues. We want to capture the
happens-before edge at a safepoint between all Java threads and the VM
thread, but this approach only captures the edge between the Java thread
that calls jvmti->IterateThroughHeap() with the VM thread.

Consider the following example:
T1, T2 are Java threads executing JNI code.

static int sum = 0;

T1:
sum = 10;

T2:
jvmti->IterateThroughHeap(&callback, &sum);

VMThread:
TSAN_RAW_LOCK_ACQUIRED(T2)
*sum_ptr += 1;
TSAN_RAW_LOCK_RELEASED(T2)

Then it will still report race between T1 and the VM thread.

Another question, should we call TSAN_RAW_LOCK_CREATE and
TSAN_RAW_LOCK_DESTROY for the fake per-thread lock also?

-Man

On Tue, May 14, 2019 at 3:50 PM Arthur Eubanks <aeubanks at google.com> wrote:

> 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
> >
>