On Tue, 2 Jan 2024 13:53:39 GMT, Alan Bateman <al...@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 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. Hello Alan, I haven't yet looked in detail the changes, so this merely a comment based on first glance: > The changes mean the stack trace is only printed to System.out when the > PrintStream lock can be acquired without blocking. I guess that then means that the some pinned threads might not even appear in this generated thread dumps. I can't think of a way where we could at least print something that would at least hint that some pinned threads weren't dumped in the output. This reduces the utility of this system property which is unfortunate, but I do understand the reason. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17221#issuecomment-1874208143
