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

[Robert Engels]

As an aside, that seems like a much more complicated and obscure design than using closable queues.

> On Jul 9, 2024, at 10:24 AM, Michal Domagala <outsider404 at gmail.com> wrote:
> 
> Indeed, for 25+ years thread is GC root.
> But for 3+ years virtual threads are present and they are documented as ephemeral.
> Developers are used to alive threads and virtual, alive threads are not confusing. But virtual, alive threads documented as ephemeral are confusing.
> Moreover, the idea that VT from Executors API is GCed but from Thread API not looks inconsistent. But it is low confusion. Working against documentation is high confusion.
> 
> Let's consider my case. I take 1000 Kafka events for concrete people each poll. 90% of events are ignored (not my customers), 10% are processed (my customers), but each event must be acked.
> Each customer has a blocking queue. 10% is distributed to proper queues. Each queue has a VT, which processes the event and finally ack the event.
> From time to time customers are off. Their blocking queues are thrown away. 
> There is a chance that at the same moment the customer is off, new poll come with customer events. Kafka listener put event to customer queue and expects VT will ack the event.
> VT can't be stopped by the "customer-off" process, because new events may come to the blocking queue anytime.
> 
> Race can be solved without synchronization. GC "knows" when the blocking queue is not visible by Kafka listener thread and "stops" the VT by reclaiming its resources.
> 
> I hope this example is clear enough to see that reclaiming VT resources by GC is simple and automatic when manual solution requires thread synchronization and is prone to errors.
> 
> wt., 9 lip 2024 o 16:24 Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> napisał(a):
> On 09/07/2024 12:51, Michal Domagala wrote:
> > Thanks for valuable observability context
> >
> > As I understand, initially VT created by Thread API was not observable 
> > in thread dump and VT created by Executors API was observable. It was 
> > confusing and now both kinds of VT are observable. Make sense.
> > But observability is reached by strong reference. VT created by Thread 
> > API are strongly referenced until stop and not GC'ed until stop and VT 
> > created by Executors API are not referenced at all and GC'ed when not 
> > reachable, regardless of being stopped or not. That's not OK and much 
> > worse than previous confusion.
> 
> An ExecutorService implementation has to keep a reference to each 
> task/thread because of the shutdownNow and close method. There are other 
> thread groupings that arise when using structured concurrency that 
> require a thread executing a main task wait for threads executing 
> subtasks to finish executing.
> 
> As things stand I don't expect there will be much confusion. For 25+ 
> years, a started thread is alive (and strongly reachable) until it 
> terminates. Having virtual thread work mostly the same shouldn't be a 
> surprise. As I said, the door hasn't been closed on introducing some 
> notion of ephemeral thread in the future. It's not really feasible right 
> now because of finalization and because of several issues related to 
> cleaner actions and explicit APIs to keep some object reachable until a 
> thread gets to some point in its execution. So there is more to this 
> than just observability (and yes of course observability could traverse 
> other reference types if needed).
> 
> As regards the thread counting in the root container when running with 
> the undocumented system property jdk.trackAllThreads is set to false. 
> That is the count of the live (started but not terminated) threads in 
> that thread grouping. It is a left over from when we will mulling over 
> what the right default should be (reporting a thread count when you 
> can't list the threads has some value).
> 
> -Alan

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