build openjdk with fsanitizer=thread

[Dmitry Vyukov]

On Wed, Feb 26, 2020 at 2:46 PM Jie He <Jie.He at arm.com> wrote:
>
> Is this case you mentioned "_owned_by_self"
>
> >     #0 Mutex::owned_by_self() const /home/wave/workspace/jdk_master/src/hotspot/share/runtime/mutex.cpp:301:10 (libjvm.so+0x1925966)
> >     #1 assert_lock_strong(Mutex const*) /home/wave/workspace/jdk_master/src/hotspot/share/runtime/mutexLocker.cpp:187:13 (libjvm.so+0x19272fa)
> >     #2 MutexLocker::~MutexLocker() /home/wave/workspace/jdk_master/src/hotspot/share/runtime/mutexLocker.hpp:237:7 (libjvm.so+0x33da8a)
> >     #3 G1YoungRemSetSamplingThread::stop_service() /home/wave/workspace/jdk_master/src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp:129:1 (libjvm.so+0x10c50e0)
> >     #4 ConcurrentGCThread::stop() /home/wave/workspace/jdk_master/src/hotspot/share/gc/shared/concurrentGCThread.cpp:65:3 (libjvm.so+0xc9fa11)
> >     #5 G1CollectedHeap::stop() /home/wave/workspace/jdk_master/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:1867:31 (libjvm.so+0xfae058)
> >     #6 before_exit(JavaThread*) /home/wave/workspace/jdk_master/src/hotspot/share/runtime/java.cpp:461:21 (libjvm.so+0x1215b84)
> >     #7 Threads::destroy_vm() /home/wave/workspace/jdk_master/src/hotspot/share/runtime/thread.cpp:4418:3 (libjvm.so+0x1e326ee)
> >     #8 jni_DestroyJavaVM_inner(JavaVM_*) /home/wave/workspace/jdk_master/src/hotspot/share/prims/jni.cpp:3989:7 (libjvm.so+0x137a5eb)
> >     #9 jni_DestroyJavaVM /home/wave/workspace/jdk_master/src/hotspot/share/prims/jni.cpp:4007:14 (libjvm.so+0x137a3ef)
> >     #10 JavaMain
>
> Seems thread::current() is a TLS variable, refer to the code:
>
> inline Thread* Thread::current_or_null() {
> #ifndef USE_LIBRARY_BASED_TLS_ONLY
>   return _thr_current;
> #else
>   if (ThreadLocalStorage::is_initialized()) {
>     return ThreadLocalStorage::thread();
>   }
>   return NULL;
> #endif
> }
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------
> For chunk_pool case,
>
> ThreadCritical implementation code in threadCritical_linux.cpp \jdk\src\hotspot\os\linux
> Seems they implemented a recursive lock here.

This should be understood by tsan then.

FTR the code is here:
https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/threadCritical_linux.cpp

> I searched the places where access _num_chunks, all have a ThreadCritical to protect.

Hard to say without the second stack...
Maybe not what we think it is. E.g. unsafe publication of the
ChunkPool, or maybe race is on the Chunk object itself...