RFR (S): Supporting VM operations

[Jean Christophe Beyler]

Fine... I think it is a very weird case and probably is a user mistake BUT
you are right, it's not a race since there are the right locks in place.

I'll dive into safepoint code handling to see if I can move the
lock/release model from the handling of the VM_Operation queue to a more
generic safepoint/VM checked all threads are in a safepoint mechanism.

*From: *Man Cao <manc at google.com>
*Date: *Wed, May 15, 2019 at 12:03 PM
*To: *Arthur Eubanks
*Cc: * <tsan-dev at openjdk.java.net>, Jean Christophe Beyler

I don't think there's a race. T2 does not have any synchronization with T1,
> but T2 does not read or write to sum.
>
> T1 and the VM thread are synchronized by the stop-the-world safe point,
> which behaves as a global barrier, so there is no race either.
>
> -Man
>
>
> On Wed, May 15, 2019, 10:34 Arthur Eubanks <aeubanks at google.com> wrote:
>
>> 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.
>>>
>> Is that not a real race? What's the synchronization between T1 and
>> T2/VMThread?
>>
>>>
>>> Another question, should we call TSAN_RAW_LOCK_CREATE and
>>> TSAN_RAW_LOCK_DESTROY for the fake per-thread lock also?
>>>
>> Yes that's probably necessary for correctness since if a thread is
>> destroyed and another one is created in its place, TSAN will think it's the
>> same lock (I think?).
>>
>>>
>>> -Man
>>>
>>

-- 

Thanks,
Jc