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

[Robert Engels]

Weak Refs don’t fully work - at least not the with the standard queus.

if you do

weakref.get().take()

you’ve created a strong reference in during the duration of the take() if the VT is a GC root - which I thought they were until this discussion. But it sounds like they are only considered a GC root if they can ever be Runnable again - and that the system is going to try and determine that the VT is never runnable, so a take() will be magically ended and every reference the VT thread had to any object is cleared and things just get cleaned up. I assume finalizers and cleaners will still run for all affected objects, including the queue object itself.

It’s fine and workable, but I think it is magic that Java doesn’t need. Clearly the Loom teams understands how they would implement it (I admit I have no idea - I think about it and it feels very complex to try and implement without special cases some types of VT blocks).

Having PT be GC roots and not having VT threads be GC roots feels wrong to me, but I am having a hard time fully articulating why.



> On Jul 3, 2024, at 12:28 PM, Davor Hrg <hrgdavor at gmail.com> wrote:
> 
> I am likely misunderstanding. Could weak reference to VT be ok, to be able to enumerate from inside the app? And gc to do its thing
> 
> 
> 
> On Wed, 3 Jul 2024, 19:24 Attila Kelemen, <attila.kelemen85 at gmail.com <mailto:attila.kelemen85 at gmail.com>> wrote:
> Maybe Ron will prove me wrong, but I never felt that the design of the JEP was meant to make VT appear as PT in all aspects. In fact, what the JEP is usually about is that it equates VT with tasks submitted to an executor. And in that case, VT being a GC root is a strange thing. Though I think either case is unlikely to make a difference in practice.
> 
> robert engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> ezt írta (időpont: 2024. júl. 3., Sze, 16:58):
> 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.
> 

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