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

[Michal Domagala]

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?

śr., 10 lip 2024 o 16:54 robert engels <robaho at icloud.com> napisał(a):

> Also, my original point were about observability (monitoring, detecting
> hung threads, lifecycle events, etc). I think that is the same as what Alan
> was referring too.
>
> > On Jul 10, 2024, at 8:15 AM, Ron Pressler <ron.pressler at oracle.com>
> wrote:
> >
> > 
> >
> >> On 9 Jul 2024, at 17:11, robert engels <robaho at icloud.com> wrote:
> >>
> >> With a closable queue you can have natural synchronization so that all
> submitted items can be acked then any further reads will cause a “queue
> closed exception” causing the reader to terminate.
> >>
> >> It is very similar in design to an executor service.
> >
> > You are talking about something quite different from the subject of this
> discussion. You’re talking about a mechanism for *terminating* threads. The
> discussion is about collecting the effectively meaningless bytes of
> “effectively dead” *unterminated* threads. The only impact of that is on
> heap usage and observability, not on any functional thread behaviour. These
> two things are orthogonal.
> >
> > You may ask what the pros and cons of collecting “effectively dead”
> threads are, given that there is no functional difference whether you do or
> don’t, but I’ll leave that for a separate discussion.
> >
> > — Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240710/fcf2fe95/attachment.htm>