<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I am not being clear. <div><br><div>I am NOT arguing that there could be no demonstrable differences between VT GCed and not.</div><div>For my case we are not interested in such differences. They can be detected as disallowed.</div><div>As I mentioned previously we generally don’t let users use threading primitives, not locks and surely not LockSupport.</div><div><br></div><div>My example with our custom Try is just to say we can allow an “escape” for special cases.</div><div>I can similarly allow any case by wrapping it into a function that will “register” the thread.</div><div><br></div><div>Your case TBH is not a great case.<br><div><blockquote type="cite"><blockquote type="cite" cite="mid:7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com"><blockquote type="cite"><p> long fileDescriptor = acquireFileDescriptor();<br> LockSupport.park();<span class="Apple-tab-span" style="white-space:pre"> </span><br> releaseFileDescriptor(fileDescriptor);</p></blockquote></blockquote></blockquote></div><div>The only way VT would get GCed if someone dropped all the VT references and that would mean that park() would never return.</div><div>So GCed or not releaseXXX is not called.</div><div>I admit (I think that’s what Alan was saying) that it would be easier to debug such case, if one still finds a thread on a heap.</div><div><br></div><div>The reason I am so interested in dropping a VT which was cancelled is that we need to make sure that no code under a given cancellation scope will execute after some barrier …. cancellAndWait(someCancellationScope) </div><div>That function first cancels the scope (sets the variable), that means no new tasks will be started under that scope.</div><div>Now, I have to wait for all currently running tasks to complete in some shape or form.</div><div>Now if some tasks are cancelled but “parked” I would have to hydrate them and inject an exception hoping to complete them as soon as possible.</div><div>It’s rather expensive and a complete waste in our system.</div><div><br></div><div>I think cancellation would be very important for scoped tasks. Logically at least they are closer to what our system is doing.</div><div><br></div><div>But even if you don’t want such cancellation for scoped tasks, maybe you can allow us to commit an evil thing and drop the VT.</div><div>i.e. make it an option on virtual thread builder or some way as part of VirtualScheduler interface?</div><div><br></div><div>Thanks again.</div><div>I really appreciate super quick response here (on Sunday!)</div><div><br></div><div><br></div><div><div><br><blockquote type="cite"><div>On Jan 11, 2026, at 11:30 AM, Viktor Klang <viktor.klang@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div><p>>Meaning park() doesn’t have to return…. Exception could be
thrown and release never called….<br>
<br>
<a moz-do-not-send="true" href="https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()">park()</a>
isn't documented to throw any exception, and even if it were to
throw an exception, it would unwind the stack and end up in some
UncaughtExceptionHandler.<br>
<br>
>Resources must be used with try blocks (or some logically
similar construct) <br>
<br>
I deliberately omitted the try-finally to be able to say this:
try-finally wouldn't help here if the VT is GCed when parked.</p>
<div class="moz-cite-prefix">On 2026-01-11 05:17, Dmitry Zaslavsky
wrote:<br>
</div>
<blockquote type="cite" cite="mid:7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com">
Your code would be broken in our case, but it’s broken in “plain”
java case as well.
<div>Meaning park() doesn’t have to return…. Exception could be
thrown and release never called….</div>
<div><br>
</div>
<div>Resources must be used with try blocks (or some logically
similar construct) </div>
<div>That’s what we are trying to “manage” by having a library
construct.</div>
<div>That library construct ensures (optionally) that finally
(clean up) called up in any case.</div>
<div><br>
</div>
<div>The other option I would want to consider is allowing
try/finally and throwing an interrupt exception.</div>
<div>I haven’t played with this. Ideally JVM support that lets me
know if there is a finally block on stack would be nice.</div>
<div>But I know it’s too much to ask.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div><br>
<blockquote type="cite">
<div>On Jan 10, 2026, at 7:02 PM, Viktor Klang
<a class="moz-txt-link-rfc2396E" href="mailto:viktor.klang@oracle.com"><viktor.klang@oracle.com></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div><p>Hi Dmitry,<br>
<br>
An example can look like:<br>
<br>
void method() {<br>
long fileDescriptor = acquireFileDescriptor();<br>
LockSupport.park();<br>
releaseFileDescriptor(fileDescriptor);<br>
}<br>
<br>
If an ephemeral VT executes that method, and there
are no other references to that ephemeral VT, then
at the point of park(), nothing can unpark it
anymore, and it will then never release the file
descriptor.<br>
<br>
<br>
><span style="white-space: pre-wrap">We generally don’t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.</span></p><p><br>
I don't see how that can work in practice, because
it requires all users of your constructs to be
familiar about exactly how all third-party logic
(including JDK classes) are implemented under the
hood. Perhaps I'm misunderstanding?<br>
<br>
</p>
<div class="moz-cite-prefix">On 2026-01-09 17:27,
Dmitry Zaslavsky wrote:<br>
</div>
<blockquote type="cite" cite="mid:5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com">
<pre wrap="" class="moz-quote-pre">Not sure what you mean by native resources?
Do you mean what people would use like try resources?
We generally don’t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
Which makes me think that there is a better way to express my point from before.
I think there is actually a common pattern here.
We use VT inside of the lib. We don’t want users to actually use any threads all.
I think it’s a goal of Alex as well.
We use VT as a way to avoid using threads (if that makes sense).
I think ScopedTasks is going in the same direction. Ideally user just doesn’t know there are threads.
We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
We don’t want users to think about Threads period.
So the thought of "GC roots on a VT … we don’t want that though to ever occur or we failed ;)
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On Jan 9, 2026, at 10:26 AM, Viktor Klang <a class="moz-txt-link-rfc2396E" href="mailto:viktor.klang@oracle.com" moz-do-not-send="true"><viktor.klang@oracle.com></a> wrote:
On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">someCollection.apar.map { …. }
Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don’t need to rest of the code to run, it’s costly.
If the task are not actively mounted but previously started and are waiting… (in our case it’s LockSupport.park) we just want to drop that entire queue and everything around it….
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">How do you handle acquired native resources that are yet to be released?
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</div>
</div></blockquote></div><br></div></div></div></body></html>