JFR integration

[Jonathan Ross]

Hi Alan, and thanks for the response.

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?)

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.

I just tried looking at the raw data I captured using the jfr tool shipped
with openjdk 20, but it fails:

jfr print: unexpected internal error, Pool jdk.types.StackTrace must
contain at least one element
java.lang.InternalError: Pool jdk.types.StackTrace must contain at least
one element
at
jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.fillConstantPools(ChunkParser.java:347)
at
jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.<init>(ChunkParser.java:149)
at
jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.nextChunkParser(ChunkParser.java:158)
at jdk.jfr/jdk.jfr.consumer.RecordingFile.findNext(RecordingFile.java:252)
at jdk.jfr/jdk.jfr.consumer.RecordingFile.readEvent(RecordingFile.java:111)
at
jdk.jfr/jdk.jfr.internal.tool.EventPrintWriter.print(EventPrintWriter.java:75)
at jdk.jfr/jdk.jfr.internal.tool.Print.execute(Print.java:163)
at jdk.jfr/jdk.jfr.internal.tool.Main.main(Main.java:87)

It looks like JMC isn't the only tool that gets confused by virtual threads
in flight recordings.

Jonathan

On Wed, Mar 22, 2023 at 11:11 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 22/03/2023 15:25, Jonathan Ross wrote:
> > Hello all,
> >
> > Apologies if this has been discussed before, I am new to this list...
> >
> > I have been experimenting with virtual threads in JDK 20, and took a
> > look at some flight recordings. It would appear that events recorded
> > on virtual threads have empty 'Event Thread' fields, and that carrier
> > threads don't have names.
> >
> > My copy of jmc (Azul Mission Control 8.3.0) currently renders all
> > virtual thread events on a single nameless thread in the thread view,
> > which, as it hopefully goes without saying, makes it much harder to
> > analyze program flow than when using a ThreadPoolExecutor or a
> > ForkJoinPool.
> >
> > Is there a reason for the blanks?  Or is Mission Control at fault?
> >
>
> Virtual threads don't have names by default. Frameworks/libraries that
> create virtual threads can set names where it make sense and is useful,
> say client info of the connection that the virtual thread is handling.
> I don't know if it possible to get JMC to show other fields but the
> events in the recording have the thread ID, name, and a few other fields
> of the thread that committed the event.
>
> Your comment on "a single nameless thread" is surprising as thread names
> have never been unique.
>
> -Alan
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230322/12924b97/attachment-0001.htm>