RFR: 8322846: Running with -Djdk.tracePinnedThreads set can hang

[Jaikiran Pai]

On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> -Djdk.tracePinnedThreads is a debugging option that dates from early development in the loom repo to identify pinned threads. It has several issues and this tracing option will eventually be removed (use the JFR events instead). Several hangs have been reported when running with the system property set. The "hangs" stem from the onPinned callback executing while the virtual thread is in a transition state (typically parking). If the virtual parks while printing the stack trace then it works like a nested park where the thread state is never restored. Contention on the System.out can also lead to deadlock when there are platform and pinned virtual threads printing to System.out around the same time.
> 
> This PR brings over the changes from the loom repo to avoid these hangs. The changes mean the stack trace is only printed to System.out when the PrintStream lock can be acquired without blocking. It also restores the thread state after printing. An alternative to not printing traces would of course be to queue the traces so they are printed by another thread but this is just adding complexity for a debugging option that we want to go away.

Hello Alan,

> > I guess that then means that the some pinned threads might not even appear in this generated thread dumps.
> 
> Just to be clear. The changes here have no impact on thread dumps, the thread dump generated by jcmd Thread.dump_to_file has all virtual threads, including pinned threads.

I didn't word my previous comment correctly. As you say, the `jdk.tracePinnedThreads` system property doesn't play a role in the thread dumps that generated through the jcmd command. This  system property just enables auto generation of a thread dump of a virtual thread when that virtual thread gets pinned. That thread dump logging happens from within that virtual thread, which is what I understand to be the reason behind the potential hang.

My understanding is that the `jcmd Thread.dump_to_file` command, when invoked, does the thread dump generation (for all threads) from within the Attach Listener thread which is a platform thread and thus isn't susceptible to this issue of hanging. 

> 
> As regards jdk.tracePinnedThreads. We want this system property to go away, it's just unfortunate that it seems to be widely used.

I think it was the ease of use (unlike having to start JFR recording) and the "event driven" automated thread dump (it gets logged only when the virtual thread is pinned unlike having to manually generate thread dumps) which made it attractive, especially during the early testing of virtual threads with other parts of the JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17221#issuecomment-1875066674