RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned due to native frame

[Jaikiran Pai]

On Tue, 28 Jun 2022 10:44:01 GMT, Alan Bateman <alanb at 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