RFR: 8252627: Make it safe for JFR thread to read threadObj

Markus Gronlund markus.gronlund at oracle.com
Tue Sep 1 21:00:48 UTC 2020


Hi Erik,

Looks good.

Thanks
Markus

-----Original Message-----
From: Erik Österlund 
Sent: den 1 september 2020 12:55
To: hotspot-dev <hotspot-dev at openjdk.java.net>
Cc: Markus Gronlund <markus.gronlund at oracle.com>; Erik Gahlin <erik.gahlin at oracle.com>
Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj

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