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

[robert engels]

I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is “unneeded magic"

> On Jul 3, 2024, at 12:17 PM, Sam Pullara <spullara at gmail.com> wrote:
> 
> Isn't the way around this to not use a queue at all and launch a new VT for each piece of work? If this is a common issue in your code base maybe add Closeable to the queue and abort on close? Hoping it all gets collected doesn't seem like the right answer to me and not keeping the VT as a root seems wrong as well.
> 
> On Wed, Jul 3, 2024 at 10:03 AM robert engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> wrote:
> In thinking about it some more, if there is no way to enumerate VT instances, then they already differ greatly from platform threads from an API standpoint and this will affect many monitoring systems (although they probably don’t deal with millions of threads well either - as was discussed in another thread).
> 
> I have used thread enumeration and cpu monitoring to detect “stuck” threads (i.e. maybe the thread that was supposed to be writing to the queue died, so the reader is making no progress). With this proposal, my reader thread is just going to go away with no observability.
> 
> I assume this is only for infinite reads - so if we add some level of timeout, then it seems you need some sort of way to detect “no possible writer” on the queue (if my thread was allowed to continue) as this would be important to know, otherwise you have an infinite timeout loop.
> 
> It feels like a radical change to Java queue systems and it doesn’t feel like a good one.
> 
> I still think having the take() throw a UnsatisfiableError with the default handling be thread death would be easier to reason about, and more consistent with current Java design patterns. In fact, the reader could spawn another writer if it chose in handling this. Without an exception bubbling up, I think you are going to have threads/tasks dying all of the time, and no idea where or why the thread died (i.e. how will report which queue the take() became invalid on up the callstack if not for an exception?).
> 
> It feels like that this will lead to a specialized VT monitoring api where you register listeners for these various conditions - why do this when there already exists the exception mechanism, default thread handlers, etc.
> 
> > On Jul 3, 2024, at 10:44 AM, Ron Pressler <ron.pressler at oracle.com <mailto:ron.pressler at oracle.com>> wrote:
> > 
> > 
> > 
> >> On 3 Jul 2024, at 15:58, robert engels <rengels at ix.netcom.com <mailto: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
> 

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