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

[Sam Pullara]

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> 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>
> wrote:
> >
> >
> >
> >> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240703/963b1c6d/attachment.htm>