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

[Michal Domagala]

> The reason for keeping a reference to virtual threads by default is not
finalization but observability. The cost of holding a strong reference is
near zero because we can rely on the same strong references in constructs
such as Executors and StructuredTaskScope, while adding WeakReferences
would come at a cost.

Got it.
Observability needs reference. As VT can be plenty, they are strongly
referenced, to avoid the cost of weak references.
Comparing, VT created by Executors are observable because Executors are
referenced weakly by jdk.internal.vm.ThreadContainers#CONTAINER_REGISTRY

I deduce that number of Executors is expected to be smaller than the number
of VTs and the cost of weak reference is acceptable.

I can't help feeling that VT could be freely GC'able, but when it was
realized that observability without strong reference is costly, narration
was changed and GC'able VT became surprising for developers etc.

czw., 11 lip 2024 o 17:33 Ron Pressler <ron.pressler at oracle.com> napisał(a):

>
>
> > On 11 Jul 2024, at 12:38, Michal Domagala <outsider404 at gmail.com> wrote:
> >
> > Regardless of the main issue, I understand that VT GC is problematic.
> JEP 444 is modified and GC paragraph is removed.
> > VT created by Thread API is strongly referenced to avoid finalization
> problems
>
> The reason for keeping a reference to virtual threads by default is not
> finalization but observability. The cost of holding a strong reference is
> near zero because we can rely on the same strong references in constructs
> such as Executors and StructuredTaskScope, while adding WeakReferences
> would come at a cost.
>
> >
> > What does it mean? I do not understand this paragraph. Will G1 clean VT
> or not?
>
> In most cases it will not because we keep a reference to the thread for
> observability unless you turn that off with a system property.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240711/b697d786/attachment.htm>