[External] : Re: Ephemeral threads

[Viktor Klang]

 >Meaning park() doesn’t have to return…. Exception could be thrown and 
release never called….

park() 
<https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()> 
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.

 >Resources must be used with try blocks (or some logically similar 
construct)

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.

On 2026-01-11 05:17, Dmitry Zaslavsky wrote:
> Your code would be broken in our case, but it’s broken in “plain” java 
> case as well.
> Meaning park() doesn’t have to return…. Exception could be thrown and 
> release never called….
>
> Resources must be used with try blocks (or some logically similar 
> construct)
> That’s what we are trying to “manage” by having a library construct.
> That library construct ensures (optionally) that finally (clean up) 
> called up in any case.
>
> The other option I would want to consider is allowing try/finally and 
> throwing an interrupt exception.
> I haven’t played with this. Ideally JVM support that lets me know if 
> there is a finally block on stack would be nice.
> But I know it’s too much to ask.
>
>
>
>> On Jan 10, 2026, at 7:02 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/191ff255/attachment.htm>