<div dir="ltr">Hi Alan, and thanks for the response.<div><br></div><div>I would agree that naming virtual threads, particularly when using a VirtualThreadPerTaskExecutor, would not be that useful. No, what I'm actually asking is whether we could still fill in useful carrier thread information in the JFR events, and whether we could name the carrier threads.  (I'm using the right term, I hope? The platform threads on which the virtual threads are run?)</div><div><br></div><div>Let me try to clarify the nameless thread bit. If I look at a flight recording running a large number of jobs using a VirtualThreadPerTaskExecutor, then the custom events I record that get fired on virtual threads don't have any thread information.  If I look at the JMC threadview, I see all my custom events on a single row without a thread name.  If I browse the event list, I also don't see any thread information.</div><div><br></div><div>I just tried looking at the raw data I captured using the jfr tool shipped with openjdk 20, but it fails:</div><div><br></div><div>jfr print: unexpected internal error, Pool jdk.types.StackTrace must contain at least one element <br>java.lang.InternalError: Pool jdk.types.StackTrace must contain at least one element <br>        at jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.fillConstantPools(ChunkParser.java:347)<br>      at jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.<init>(ChunkParser.java:149)<br>   at jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.nextChunkParser(ChunkParser.java:158)<br>        at jdk.jfr/jdk.jfr.consumer.RecordingFile.findNext(RecordingFile.java:252)<br>    at jdk.jfr/jdk.jfr.consumer.RecordingFile.readEvent(RecordingFile.java:111)<br>   at jdk.jfr/jdk.jfr.internal.tool.EventPrintWriter.print(EventPrintWriter.java:75)<br>     at jdk.jfr/jdk.jfr.internal.tool.Print.execute(Print.java:163)<br>        at jdk.jfr/jdk.jfr.internal.tool.Main.main(Main.java:87)</div><div><br></div><div>It looks like JMC isn't the only tool that gets confused by virtual threads in flight recordings.</div><div><br></div><div>Jonathan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 22, 2023 at 11:11 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 22/03/2023 15:25, Jonathan Ross wrote:<br>
> Hello all,<br>
><br>
> Apologies if this has been discussed before, I am new to this list...<br>
><br>
> I have been experimenting with virtual threads in JDK 20, and took a <br>
> look at some flight recordings. It would appear that events recorded <br>
> on virtual threads have empty 'Event Thread' fields, and that carrier <br>
> threads don't have names.<br>
><br>
> My copy of jmc (Azul Mission Control 8.3.0) currently renders all <br>
> virtual thread events on a single nameless thread in the thread view, <br>
> which, as it hopefully goes without saying, makes it much harder to <br>
> analyze program flow than when using a ThreadPoolExecutor or a <br>
> ForkJoinPool.<br>
><br>
> Is there a reason for the blanks?  Or is Mission Control at fault?<br>
><br>
<br>
Virtual threads don't have names by default. Frameworks/libraries that <br>
create virtual threads can set names where it make sense and is useful, <br>
say client info of the connection that the virtual thread is handling.  <br>
I don't know if it possible to get JMC to show other fields but the <br>
events in the recording have the thread ID, name, and a few other fields <br>
of the thread that committed the event.<br>
<br>
Your comment on "a single nameless thread" is surprising as thread names <br>
have never been unique.<br>
<br>
-Alan<br>
<br>
<br>
<br>
</blockquote></div>