JFR integration

[Alan Bateman]

On 22/03/2023 17:23, Jonathan Ross wrote:
> 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.
>
I'm not aware of any issues or if the parsing exception in your mail is 
related to virtual threads or not, maybe hotspot-jfr-dev may recognize this.

As a quick test, I tried some custom events committed from virtual 
threads and the jfr tool parses the recording, e.g.

jfr print --events *Foo* ...

Foo {
   startTime = 17:50:05.595 (2023-03-22)
   duration = 0.00147 ms
   message = "A message from a virtual thread"
   eventThread = "" (javaThreadId = 35, virtual)
   stackTrace = [
     Test.lambda$main$0() line: 21
     java.util.concurrent.FutureTask.run() line: 317
     java.lang.VirtualThread.run(Runnable) line: 314
   ]
}

Note the eventThread line has the thread name (empty in this case), the 
thread ID, and it also indicates that it is a virtual thread.

-Alan