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

Ron Pressler ron.pressler at oracle.com
Wed Jul 3 15:44:16 UTC 2024



> On 3 Jul 2024, at 15:58, robert engels <rengels at ix.netcom.com> wrote:
> 
> 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.

What change can you observe?

You could say that you could observe a difference if there’s some weak reference to the thread, in which case the reference may be enqueued for a VT but not a PT. Only we never promise that weak references are ever enqueued; that entirely depends on the particular chosen GC, so you’d be able to observe only a difference that you’d also observe with a different selection of GC.

Another difference is that you could potentially wake up a PT by enumerating all PTs, but this difference already exists today; collecting the VT doesn’t introduce any further change.

I certainly can’t see what effect any of this would have on queue handling.

— Ron


More information about the loom-dev mailing list