[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