RFR (S): Supporting VM operations

[Jean Christophe Beyler]

Hi Man,

I believe as Arthur that your example is a real race. There's nothing we
can do about that case and we should actually expose it as a race in my
opinion.

For the create/destroy, I'll add that to the webrev and do testing and I'll
do some clean up to have a class do the acquire/release as Arthur pointed
out. I hesitated when I did it but you've convinced me :)
Jc

*From: *Arthur Eubanks <aeubanks at google.com>
*Date: *Wed, May 15, 2019 at 10:34 AM
*To: *Man Cao
*Cc: * <tsan-dev at openjdk.java.net>, Jean Christophe Beyler

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