For JavaThreads, as they terminate they explicitly invoke their destructor:

void JavaThread::thread_main_inner() {
  ...
  delete this;
}

However most system-related threads do not expect to explicitly terminate, except sometimes as part of VM termination. Such threads don't have their destructors called, but should.

This omission came to light due to the ThreadLocalStorage changes in JDK-8132510. As part of that change we deleted the following from the termination path of the VMThread:

 // Thread destructor usually does this.
 ThreadLocalStorage::set_thread(NULL);

The clearing of TLS seemed irrelevant to the VMThread as it primarily is used to aid in JNI attach/detach. However Brian Gardner reported:

http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html

a problem on FreeBSD caused by this change and the interaction with the POSIX  pthread TLS destructor use introduced by JDK-8033696. Because the VMThread terminated without clearing TLS, when the TLS-destructor was called it got into a loop which ran four times (as happens on Linux) and then prints a warning to the console (which doesn't happen on Linux).

This indicates we need to restore the:

 // Thread destructor usually does this.
 ThreadLocalStorage::set_thread(NULL);

but on further consideration it seems to me that this is not confined to the VMThread, and the most appropriate fix would be to always invoke the Thread destructor as a thread terminates.