Since the thread oop moved to OopStorage, a bug was introduced. The oop is now read with load barriers. If the JFR thread shoots a thread that holds a load barrier lock, it is stuck holding that lock. Then the JFR thread tries to read the threadObj(), which might grab the same lock. This causes a deadlock.
There are also some ZGC asserts that fire, not expecting relocation to happen from an unknown non-Java thread.
I had fixes for said problems in my own concurrent stack scanning branch, but forgot to point it out in the review thread for JDK-8244997.