RFR (M): Use TSAN_RUNTIME_ONLY for most instrumentation

[Arthur Eubanks]

LGTM.

*From: *Man Cao <manc at google.com>
*Date: *Mon, May 6, 2019 at 11:56 AM
*To: *Jean Christophe Beyler
*Cc: *Arthur Eubanks, <tsan-dev at openjdk.java.net>

Done. New webrev and incremental webrev:
>
> https://cr.openjdk.java.net/~manc/tsan20190506/webrev.01/
> https://cr.openjdk.java.net/~manc/tsan20190506/webrev.diff.00-01/
>
> -Man
>
>
> *From: *Jean Christophe Beyler <jcbeyler at google.com>
> *Date: *Mon, May 6, 2019 at 10:24 AM
> *To: *Arthur Eubanks
> *Cc: *Man Cao, <tsan-dev at openjdk.java.net>
>
> I agree with Arthur, though nested macros makes me sad, it would be better
>> than having to do LINE/FILE every time...
>> Jc
>>
>> On Mon, May 6, 2019 at 9:58 AM Arthur Eubanks <aeubanks at google.com>
>> wrote:
>>
>>> Having to type "__FILE__, __LINE__" to every TsanRawLock*() call is
>>> annoying. Is it possible to still keep the TSAN_RAW_LOCK_* macros in
>>> tsan.hpp and call them in a TSAN_RUNTIME_ONLY block? That way they're
>>> stripped out by the preprocessor in non-TSAN builds, and they'll still be
>>> available in TSAN builds.
>>>
>>> *From: *Man Cao <manc at google.com>
>>> *Date: *Mon, May 6, 2019 at 9:48 AM
>>> *To: * <tsan-dev at openjdk.java.net>
>>>
>>> Hi all,
>>> >
>>> > Can I have reviews for this bug fix and cleanup?
>>> > http://cr.openjdk.java.net/~manc/tsan/20190506/webrev.00/
>>> >
>>> > Copying commit message below:
>>> > Use TSAN_RUNTIME_ONLY for most instrumentation.
>>> > This fixes build error using --with-jvm-features=-tsan,
>>> > and reduces boilerplate code for instrumentation.
>>> > Also simplified oopDesc:is_oop() uses and updated a comment.
>>> >
>>> > -Man
>>> >
>>>
>>
>>
>> --
>>
>> Thanks,
>> Jc
>>
>