RFR (S): Supporting VM operations

[Man Cao]

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