On Wed, 13 Jul 2022 09:47:50 GMT, Alan Bateman 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 fo
On Tue, 12 Jul 2022 07:22:14 GMT, Jaikiran Pai wrote:
> 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.
That's a good observation, it would be more
> 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
On Tue, 12 Jul 2022 07:20:24 GMT, Jaikiran Pai wrote:
> 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?
The stack trace shows the native frames and highlights any frames w
On Tue, 28 Jun 2022 10:44:01 GMT, Alan Bateman 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 th
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 tr
