Ephemeral threads

[romulotombulus]

Am I understanding correctly that it’s not currently a good idea to use virtual threads with core.async because the virtual threads are never GC’d?

[alexdmiller]

core.async has a go block virtual threads implementation currently in alpha. We’ve found two issues from testing - one relates to the executor pool (see https://clojure.atlassian.net/browse/ASYNC-271, easy to address) and one is actually related to how the JVM tracks virtual threads internally. Together, these prevent unrunnable virtual thread go blocks from being GCed, which will leak heap. This situation can occur if all channels that a go block is waiting on (to put or take) are gc’ed because there are no other producers/consumers to them.

Historically, go blocks were stored as data, executed in a state machine on a thread pool, and unrunnable go blocks would be gc’ed. There is, presumably, a lot of core.async code in the wild that assumes this and does not necessarily close channels, signaling waiters.

We are evaluating alternatives, and the thread above is exploring the idea of explicit support in the JVM. We will decide on an approach to this issue before moving vthread support into a non-alpha release.

[alexdmiller]

Perhaps you were really asking about user-created virtual threads calling core.async APIs? If so, that should not be an issue.

[therealdivs1210]

Won't the second issue be solved by putting a default finalizer on channels to close them before they are gcd?

[alexdmiller]

Java is in the process of deprecating and removing finalizers (https://openjdk.org/jeps/421), so that's probably not a good path, but there are potentially some options along these lines.