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

[Erik Österlund]

Hi Markus,

Thanks for the review.

/Erik

> On 1 Sep 2020, at 23:00, Markus Gronlund <markus.gronlund at oracle.com> wrote:
> 
> 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