<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Jonathan, </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The platform thread may change for a virtual thread, so it can be tricky to add support for it. Today, thread data are stored in a lookup table in the file and only the key is emitted with the event. This scheme is used to reduce the size of the recording.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
A better solution may be events when a virtual thread migrates, but first, why do you need the information?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Erik</div>
<div id="appendonsend"></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> hotspot-jfr-dev <hotspot-jfr-dev-retn@openjdk.org> on behalf of Jonathan Ross <jonathan.ross@cjug.org><br>
<b>Sent:</b> Wednesday, March 22, 2023 8:16 PM<br>
<b>To:</b> Alan Bateman <alan.bateman@oracle.com><br>
<b>Cc:</b> hotspot-jfr-dev <hotspot-jfr-dev@openjdk.java.net>; loom-dev@openjdk.org <loom-dev@openjdk.org><br>
<b>Subject:</b> Re: JFR integration</span>
<div> </div>
</div>
<div style="direction: ltr;">Okay, it must be something else causing the jfr problem, I'll contact jfr-dev as you suggest, thanks for that suggestion.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Can you comment on jfr events not including information about the carrier thread? Is there any particular reason not to (want to) include platform thread information? I, for one, would like to be able to see the underlying fork-join
scheduler at work in flight recordings.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">A second, somewhat related question: is it possible to use multiple distinct carrier thread pools, with different parallelism? (Perhaps there is some magic around creating virtual threads from within a forkjoin task?)</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Cheers,</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Jonathan</div>
<br>
<div style="direction: ltr;">On Wed, Mar 22, 2023 at 1:11 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" id="OWAd89b89f3-5fb0-52c0-a5eb-6ad9da6c9c5d" class="OWAAutoLink">Alan.Bateman@oracle.com</a>> wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204);">
On 22/03/2023 17:23, Jonathan Ross wrote:<br>
> Hi Alan, and thanks for the response.<br>
><br>
> I would agree that naming virtual threads, particularly when using a<br>
> VirtualThreadPerTaskExecutor, would not be that useful. No, what I'm<br>
> actually asking is whether we could still fill in useful carrier<br>
> thread information in the JFR events, and whether we could name the<br>
> carrier threads. (I'm using the right term, I hope? The platform<br>
> threads on which the virtual threads are run?)<br>
><br>
> Let me try to clarify the nameless thread bit. If I look at a flight<br>
> recording running a large number of jobs using a<br>
> VirtualThreadPerTaskExecutor, then the custom events I record that get<br>
> fired on virtual threads don't have any thread information. If I look<br>
> at the JMC threadview, I see all my custom events on a single row<br>
> without a thread name. If I browse the event list, I also don't see<br>
> any thread information.<br>
><br>
> I just tried looking at the raw data I captured using the jfr tool<br>
> shipped with openjdk 20, but it fails:<br>
><br>
> jfr print: unexpected internal error, Pool jdk.types.StackTrace must<br>
> contain at least one element<br>
> java.lang.InternalError: Pool jdk.types.StackTrace must contain at<br>
> least one element<br>
> at<br>
> jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.fillConstantPools(ChunkParser.java:347)<br>
> at<br>
> jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.<init>(ChunkParser.java:149)<br>
> at<br>
> 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<br>
> jdk.jfr/jdk.jfr.consumer.RecordingFile.readEvent(RecordingFile.java:111)<br>
> at<br>
> 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)<br>
><br>
> It looks like JMC isn't the only tool that gets confused by virtual<br>
> threads in flight recordings.<br>
><br>
I'm not aware of any issues or if the parsing exception in your mail is<br>
related to virtual threads or not, maybe hotspot-jfr-dev may recognize this.<br>
<br>
As a quick test, I tried some custom events committed from virtual<br>
threads and the jfr tool parses the recording, e.g.<br>
<br>
jfr print --events *Foo* ...<br>
<br>
Foo {<br>
startTime = 17:50:05.595 (2023-03-22)<br>
duration = 0.00147 ms<br>
message = "A message from a virtual thread"<br>
eventThread = "" (javaThreadId = 35, virtual)<br>
stackTrace = [<br>
Test.lambda$main$0() line: 21<br>
java.util.concurrent.FutureTask.run() line: 317<br>
java.lang.VirtualThread.run(Runnable) line: 314<br>
]<br>
}<br>
<br>
Note the eventThread line has the thread name (empty in this case), the<br>
thread ID, and it also indicates that it is a virtual thread.<br>
<br>
-Alan<br>
<br>
<br>
</blockquote>
</body>
</html>