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

robert engels rengels at ix.netcom.com
Wed Jul 3 14:58:08 UTC 2024


I understand, but with a PT thread being a GC, and methods like Thread.enumerate() is was never possibly - and a “service” could always find the “blocked” threads and interrupt them.

If VT are not findable (or optionally findable), I think it is a breaking change which goes against the JEP design for virtual threads, and it is going to lead to two different types of patterns for queue handling based on the thread types involved - I think this is a very bad idea.

> On Jul 3, 2024, at 9:53 AM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> The assumption is that the thread can provably never continue. That implies `stop` never being called. So, there is no observable difference.
> 
> robert engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> ezt írta (időpont: 2024. júl. 3., Sze, 16:38):
> 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.
>      *
>      * @return the head of this queue
>      * @throws InterruptedException if 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240703/8a06435a/attachment.htm>


More information about the loom-dev mailing list