The fix for JDK-8240918 had to deal with a problem when the thread terminating the VM had to be careful not to delete itself if it may be accessible from a local ThreadsList:

"To avoid this possible issue of deleting a JavaThread that called Thread::destroy_vm() while there are handshakers blocked in the handshake_turn_sem semaphore, I added a check to verify the JavaThread in question is not protected by some ThreadsList reference before attempting the delete it. In case it is protected, we need to at least clear the value for _thread_key to avoid possible infinite loops at thread exit (this can happen in Solaris). "

This worked but seemed somewhat awkward to me:

" At some point during the shutdown sequence the thread needs to be able to execute "process any pending handshake and mark this thread as no longer handshake-capable". But it is unclear how to achieve that at this time so I'm okay with deferring this to a future RFE."

I think a possible simple fix here is to have a variant of ThreadSMRSupport::smr_delete that blocks until it is safe to delete but doesn't do the delete. The destroying thread can call that early on before the termination safepoint and then safely delete itself later.  That will not only address this situation but also more generally allow greater flexibility in the thread termination protocol by allowing other actions to occur between the point where the thread becomes safe-to-delete and the actual deletion.