On Tue, 28 Jun 2022 10:44:01 GMT, Alan Bateman <al...@openjdk.org> wrote:
> The system property jdk.tracePinnedThreads triggers a stack trace to be > printed when a virtual thread parks while pinned. If a virtual thread is > pinned due to a native frame there is a spurious " <== monitors:0" added to > line for the native method. > > A secondary issue is that there is no stack trace when there is Panama > downcall as there isn't a native method in the stack trace. A future change > may annotate the downcalls, for now the entire stack trace is printed (no > filtering) so there is at least some output when pinned due to a call through > native code Marked as reviewed by jpai (Reviewer). Hello Alan, The changes looks fine to me. I'm not too familiar with the build files, so I can't comment about the changes to the `JtregNativeJdk.gmk` file. On a slightly related note, while reviewing this change, I noticed the code in `VirtualThread` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/VirtualThread.java#L177. Is it intentional that we don't print/use the `reason` while printing out the stacktrace? The reason appears to be one of: /** Native frame on stack */ NATIVE, /** Monitor held */ MONITOR, /** In critical section */ CRITICAL_SECTION Would printing this reason be useful for easily understanding why the thread was considered pinned? I guess the same could be inferred from the stacktraces right now? test/jdk/java/lang/Thread/virtual/TracePinnedThreads.java line 95: > 93: System.setOut(new PrintStream(baos)); > 94: try { > 95: VThreadRunner.run(task::run); The change here removes the previous call to flush the `System.out`. I believe that's fine because the `PrintStream` here is backed by a `ByteArrayOutputStream` so the flush isn't necessary. ------------- PR: https://git.openjdk.org/jdk/pull/9308
