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