[External] : Re: Ephemeral threads

Mon Jan 12 11:53:11 UTC 2026

What I'm saying is that detecting, and debugging, such issues is vastly 
more difficult when the forgotten thread has been GC:ed.

On 2026-01-12 12:31, Robert Engels wrote:
> No, just ensure that there is always a thread this will eventually 
> call unpark().
>
> You can ensure this with proper use of try/finally.
>
> If you write that code any nothing ever calls unpark - it is hung (and 
> leaked). You can resolve this without any new APIs.
>
> It has nothing to do with queues - it is all about correctness. It 
> seems queues (or channels) has been discussed because this is a common 
> source of this issue (especially in Go). See #2 here: 
> https://oneuptime.com/blog/post/2026-01-07-go-goroutine-leaks/view 
> <https://urldefense.com/v3/__https://oneuptime.com/blog/post/2026-01-07-go-goroutine-leaks/view__;!!ACWV5N9M2RV99hQ!Lc6RAKDcwT9pWlm7RR0zEh8Bw0kuCIHACWakPWcDKd89LJW1dwJMlK3Suc5v2grGe5E02hM6uJKJvH9m4PI$>
>
>> On Jan 12, 2026, at 4:00 AM, Viktor Klang <viktor.klang at oracle.com> 
>> wrote:
>>
>> 
>>
>> In my example there is no queue. Are you suggesting that all 
>> pre-existing code and all new code should get rewritten using some 
>> new API?
>>
>> On 2026-01-11 18:57, robert engels wrote:
>>> because if park wakes up, the thread already has a reference to the 
>>> queue meaning it can start another thread that puts items into the 
>>> queue.  Meaning the queue is not “unreferenceable”, so you can’t 
>>> simply destroy a thread waiting in park().
>>>
>>>> On Jan 11, 2026, at 10:30 AM, Viktor Klang 
>>>> <viktor.klang at oracle.com> wrote:
>>>>
>>>> 
>>>>
>>>> >This code is fundamentally broken. Park() can wake up for any reason.
>>>>
>>>> I don't see how "When park wakes up" (i.e. the temporal aspect) 
>>>> affects correctness in any way in the example given.
>>>>
>>>> >I suggest you look at ClosableQueue - it is correct and far easier 
>>>> to use.
>>>>
>>>> The example is completely devoid of any queuing concerns. We're 
>>>> talking about logic which is executed by some thread, and the 
>>>> person who writes the code does not strictly know whether that 
>>>> thread is a platform thread, a pooled platform thread, a virtual 
>>>> thread, an ephemeral virtual thread, a GC finalizer thread.
>>>>
>>>> In short, this is about: pre-existing code which may get executed 
>>>> by an ephemeral virtual thread may /silently/ leak resources under 
>>>> certain circumstances. Now, it can be argued that most of that code 
>>>> was "not ideal" in the first place, but the big difference is that 
>>>> when any such defect gets noticed in a running application, there's 
>>>> a much better visibility if the thread which ran into the problem 
>>>> is still there (evidence) vs not (no evidence).
>>>>
>>>> On 2026-01-11 01:50, Robert Engels wrote:
>>>>> This code is fundamentally broken. Park() can wake up for any reason.
>>>>>
>>>>> I suggest you look at ClosableQueue - it is correct and far easier 
>>>>> to use.
>>>>>
>>>>>> On Jan 10, 2026, at 6:03 PM, Viktor Klang 
>>>>>> <viktor.klang at oracle.com> wrote:
>>>>>>
>>>>>> 
>>>>>>
>>>>>> Hi Dmitry,
>>>>>>
>>>>>> An example can look like:
>>>>>>
>>>>>> void method() {
>>>>>>     long fileDescriptor = acquireFileDescriptor();
>>>>>>     LockSupport.park();
>>>>>>     releaseFileDescriptor(fileDescriptor);
>>>>>> }
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> >We generally don’t allow try blocks (providing other 
>>>>>> constructs), we also very strongly discourage (just a drop short 
>>>>>> of disallowing) ANY threading primitives.
>>>>>>
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>> On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
>>>>>>> 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 ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>> On Jan 9, 2026, at 10:26 AM, Viktor Klang<viktor.klang at oracle.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>>>>>>>> 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….
>>>>>>>>>
>>>>>>>>>
>>>>>>>> How do you handle acquired native resources that are yet to be released?
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Cheers,
>>>>>>>> √
>>>>>>>>
>>>>>>>>
>>>>>>>> Viktor Klang
>>>>>>>> Software Architect, Java Platform Group
>>>>>>>> Oracle
>>>>>>>>
>>>>>> -- 
>>>>>> Cheers,
>>>>>> √
>>>>>>
>>>>>>
>>>>>> Viktor Klang
>>>>>> Software Architect, Java Platform Group
>>>>>> Oracle
>>>> -- 
>>>> Cheers,
>>>> √
>>>>
>>>>
>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle
>> -- 
>> Cheers,
>> √
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

-- 
Cheers,
√

Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/16b13a16/attachment.htm>