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

[Michal Domagala]

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:
> >
> > PS. I JEP 444 I still see GC root paragraph:
>
> > Unlike platform thread stacks, virtual thread stacks are not GC roots.
> Thus the references they contain are not traversed in a stop-the-world
> pause by garbage collectors, such as G1, that perform concurrent heap
> scanning.
>
> > 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.


 I must admit I do not undestand it.

"Unlike platform thread stacks, virtual thread stacks are not GC roots. "
PT stacks are GC roots, VT stacks are not. Clear

"Thus the references they contain are not traversed in a stop-the-world
pause by garbage collectors"

PT stack references are traversed by GC, VT stack references are not
traversed. Clear.
GC starts from GC root and travers all references. Each object
encountered on the road is alive, all others are abandoned. Clear.
Live references survive, abandoned are collected. Clear.
GC travers all PT references and saves live ones against collection. GC
does not travers VT references.  They are not marked as alive. They are
treated as abandoned and collected. After the GC phase, all VT references
are null. Nonsense.
Where is the mistake in my reasoning?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240711/3c46c943/attachment-0001.htm>