[External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads

Brian S O'Neill bronee at gmail.com
Wed Jul 3 14:55:16 UTC 2024


If the take method never returns, the stop method will never be called 
in either case. Does it matter if the VT is reclaimed or not?

I think the more interesting case is when the timer is finalizable or 
uses a Cleaner. If the VT decides that it cannot continue and goes away, 
then the timer can be reclaimed too. The invocation of the cleaning 
action might give the impression that the take method did continue, when 
in fact it never did.


On 2024-07-03 07:36 AM, robert engels wrote:
> But won’t that be a breaking api change:
> 
> /**
> * Retrieves and removes the head of this queue, waiting if necessary
> * until an element becomes available.
> *
> * @returnthe head of this queue
> * @throwsInterruptedExceptionif interrupted while waiting
> */
> E take() throws InterruptedException;
> 
> For example, given this code:
> 
> T timedGetElement() throws InterruptedException {
>    Timer t = Timer.start();
>     try {
>        return queue.take();
>     } finally {
>        t.stop();
>     }
> }
> 
> With the proposed changes, stop() may never be called - leading to 
> potential resource leaks.
> 
> Whereas currently the rules ensure stop() will be called unless the 
> application hard terminates. This would essentially equating thread 
> “death” with a hard application termination from an observability 
> standpoint.
> 
> You would have similar issues with any tracing/logging type frameworks.
> 
> 
>> On Jul 3, 2024, at 9:12 AM, Ron Pressler <ron.pressler at oracle.com 
>> <mailto:ron.pressler at oracle.com>> wrote:
>>
>>
>>
>>> On 2 Jul 2024, at 19:41, robert engels <rengels at ix.netcom.com 
>>> <mailto:rengels at ix.netcom.com>> wrote:
>>>
>>> Is this in an effort to allow the automatic clean-up the OP refers to?
>>
>> Not cleanup, but memory reclamation. If a thread provably can never 
>> continue, it can continue running forever (conceptually) without 
>> consuming any RAM (although you want be able to observe it). If a 
>> thread can never do anything, it behaves exactly as if the thread 
>> doesn’t exist.
>>


More information about the loom-dev mailing list