
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">If it is blocked reading a socket, it is not on a CarrierThread (i.e. blocked not running) so there is no strong reference from the CarrierThread to the VirtualThread in this case.<div class=""><br class=""></div><div class="">I am fairly certain that the scheduler/blocking handler is what maintains the strong thread references in this case.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 25, 2024, at 8:49 AM, Matthew Swift <<a href="mailto:matthew.swift@gmail.com" class="">matthew.swift@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks for the quick response Alan. A couple of comments:<br class=""><br class=""><div class="">> You can specify a ThreadFactory to newThreadPerTaskExecutor so you can</div>> set the thread name if you need it. Virtual threads are meant to be<br class="">> lightweight and numerous so don't get a name by default. For many cases,<br class="">> this is okay as the they have a thread ID which will identity them in<br class="">> thread dumps and elsewhere.<br class=""><br class="">That may be so, but it's not very flexible, unless I'm missing something, because it's not possible to derive the thread name from the task itself. Said otherwise, a ThreadFactory lets you create very generic thread names like "HTTP Connection #1" ahead of time, but doesn't let you derive a rich name from the Runnable itself, like "HTTP Connection from 1.2.3.4 to 5.6.7.8 on port 8080". I tried cheating a bit by relying on the toString() of the Runnable, but sadly this doesn't work because the executor wraps the provided Runnable before calling the thread factory (see ThreadPerTaskExecutor#start(java.lang.Runnable)).<div class=""><br class=""></div><div class="">> A virtual thread that is blocked reading from a Socket will continue<br class="">> when there are bytes to read, the peer closes the connection, some I/O<br class="">> exception, or the thread is interrupted. So it will be strongly reachable.<br class=""></div><div class=""><br class=""></div><div class="">Ah, of course, silly me. And, following from that, the VT is strongly reachable when running because it is directly referenced by the carrier thread itself.</div><div class=""><br class=""></div><div class="">Thanks</div><div class="">Matt</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Jul 2024 at 14:55, Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" class="">Alan.Bateman@oracle.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">

<br class="">

On 25/07/2024 13:21, Matthew Swift wrote:<br class="">

> Hmm, I'm starting to think I may have fallen into the same trap here <br class="">

> as Michal.<br class="">

><br class="">

> I've been using virtual threads similar to platform threads for <br class="">

> performing IO tasks asynchronously.<br class="">

><br class="">

> Background: originally, I was using <br class="">

> Executors#newVirtualThreadPerTaskExecutor to run these tasks, which <br class="">

> was fine because the Executor tracks the virtual threads it creates in <br class="">

> order to support shutdown. However, from an observability point of <br class="">

> view I've found the executor to be a bit frustrating because it is <br class="">

> impossible to set the thread name before the thread is scheduled to <br class="">

> run[1].<br class="">

You can specify a ThreadFactory to newThreadPerTaskExecutor so you can <br class="">

set the thread name if you need it. Virtual threads are meant to be <br class="">

lightweight and numerous so don't get a name by default. For many cases, <br class="">

this is okay as the they have a thread ID which will identity them in <br class="">

thread dumps and elsewhere.<br class="">

<br class="">

<br class="">

> This means that under heavy load where the FJ pool is busy a thread <br class="">

> dump shows many unnamed threads, which are waiting to be scheduled for <br class="">

> the first time. Admittedly, this is only a minor annoyance because I'm <br class="">

> more interested in the threads that are clogging up the FJ pool than <br class="">

> the ones which are waiting to use it, even so it'd be nice to have an <br class="">

> overall picture of what's active and what's queued (note also thread <br class="">

> names are included in JFR events, which is super helpful).<br class="">

<br class="">

With the Loom EA builds [1] you can use `jcmd <pid> <br class="">

Thread.vthread_summary` to get a summary view of all thread grouping so <br class="">

you get thread counts, a summary of the scheduler, timers, and any <br class="">

socket I/O that it outstanding. We would like to bring this diagnostic <br class="">

command into the main line JDK at some point.<br class="">

<br class="">

><br class="">

> To remedy this, I've switched away from using an Executor and now I <br class="">

> just use "Thread.ofVirtual().name(initialName).start(task)". However, <br class="">

> I don't think all of the tasks are strongly reachable - some are "fire <br class="">

> and forget" tasks (e.g. async resource cleanup), so I may be <br class="">

> inadvertently relying on the JVM's observability support to keep these <br class="">

> tasks alive until they complete, which seems a bit brittle. In fact, <br class="">

> now that I think of it, it may not even be limited to fire and forget <br class="">

> tasks. A VT that is reading messages from a Socket could be GC'd<br class="">

A virtual thread that is blocked reading from a Socket will continue <br class="">

when there are bytes to read, the peer closes the connection, some I/O <br class="">

exception, or the thread is interrupted. So it will be strongly reachable.<br class="">

<br class="">

-Alan<br class="">

<br class="">

[1] <a href="https://jdk.java.net/loom/" rel="noreferrer" target="_blank" class="">https://jdk.java.net/loom/</a><br class="">

</blockquote></div>

</div></blockquote></div><br class=""></div></body></html>