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

[Michal Domagala]

It is a reason to NOT hold strong reference to VT created by Executor API
but NOT a reason to hold strong reference to VT created by Thread API.
Assume GC'able VT is risky due "Finalization is one topic. Another is
Cleaner actions". Assume 99% VT is created by Executor API and 1% is
created by Thread API

If I can afford 99% VT is risky GC'ed, I can afford 100% VT is risky GC'ed
and keep system simple without strong reference to any VT



śr., 10 lip 2024 o 22:57 Brian S O'Neill <bronee at gmail.com> napisał(a):

> I think there's also the question of efficiency. If every new VT needs
> to be registered, then this adds a bit of overhead and makes them
> slightly less useful for running short-lived tasks.
>
> On 2024-07-10 12:56 PM, Michal Domagala wrote:
> > Hi,
> >
> > My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be
> > GC'ed before they terminate (java.com)
> > <https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8336061> and
> > solved as documentation defect.
> >
> > Still one issue is not clear to me. Is VT strongly referenced because
> > being blocked and GC'ed is not useful or is problematic to implement?
> >
> > There were voices in discussion that VT GC  is surprising for
> > developers. For that reason I showed my case. I wanted to present that
> > "closing" blocking queue by nullifying and GC does not need
> > synchronization. Unsynchronized code is less prone to errors than code
> > with synchronization.
> >
> > But there are voices that garbage collection "alive" VT is problematic:
> > "Finalization is one topic. Another is Cleaner actions that may run
> > while a resource is in an inconsistent state." I don't know this area so
> > I can't deny it.
> >
> > I checked that the blocked task created by
> > Executors.newVirtualThreadPerTaskExecutor().submit() is GCed. Does it
> > mean that:
> >
> > 1) Executors.newVirtualThreadPerTaskExecutor().submit() does not create
> VT?
> > 2) VT created by Executors API is different from that created by Thread
> > API and can GCed without problem with finalization and Cleaner action?
> > 3) VT created by Executors API is has the same problem as created by
> > Thread API and in future all VT will be strongly referenced?
> > 4) Is it a fairy tale that VT GC is problematic?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240711/274e5647/attachment-0001.htm>