RFR: 8252627: Make it safe for JFR thread to read threadObj
Erik Österlund
erik.osterlund at oracle.com
Tue Sep 1 10:55:07 UTC 2020
Hi,
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 signal at a thread that holds a load barrier
lock, the target thread 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.
My solution is to read the threadObj before the target thread is shot
down, and simply pass in the already
sampled thread oop to the context where the events are created. All of
this is done with the Threads_lock
taken (today) to lock out safepoints from destroying the oop.
Webrev:
http://cr.openjdk.java.net/~eosterlund/8252627/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8252627
Thanks,
/Erik
More information about the hotspot-dev
mailing list