UseDynamicNumberOfCompilerThreads adds and removes compiler threads as necessary and the logic is driven primarily by AbstractCompiler::_num_compiler_threads.  When a thread is removed this number is decremented by CompileBroker::can_remove by the running CompilerThread.  Later, possibly_add_compiler_threads notices that it can spin up a new thread and it uses JavaThread::start_internal_daemon to associate a new CompilerThread with the existing JavaThread instance.  The problem is that CompileBroker::can_remove is called from the running CompilerThread before it has actually exited.  The exit of the thread clears java.lang.Thread.eetop on the way out.  It's possible that a new CompilerThread is created before the old one has actually exited.  This will result in Thread.eetop being null for an actual running JavaThread.  For C1 and C2 this mostly doesn't cause problems but for libgraal this can lead to hangs, particularly with ReentrantLock since eetop being null makes the thread appear dead.