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

[Michal Domagala]

First, today I successfully reported the issue to https://bugreport.java.com.
I do not need help or assistance anymore.

Second, indeed, technically speaking, it is a memory leak issue, not GC
root issue. Unfortunately, I do not know any documentation which declares
that memory leaks in JDK are not allowed.
However, the issue is strictly related to JEP 444, which directly explains
how VTs are reclaimed by GC. Including an example. I'm pretty sure that the
memory leak bug is caused by lack of awareness that VTs are not GC root.

Continuing technical speaking, GC never MUST reclaim any particular object.
GC MUST separate used and unused objects and MAY reclaim memory taken by
unused objects.
It means the contract "...the [virtual] thread can be garbage collected" is
broken because blocked VT can NOT be garbage collected.

Nevertheless, I'm satisfied because thread goal - report the issue to
Oracle - is done. Thanks to any thread participant for taking effort

wt., 9 lip 2024 o 00:02 Brian S O'Neill <bronee at gmail.com> napisał(a):

> The exact phrase in JEP 444 is, "Unlike platform thread stacks, virtual
> thread stacks are not GC roots."  GC roots also include static fields,
> but the tracked VT is only indirectly referenced by a static field, via
> a map object. So technically speaking, JEP 444 and JDK 21 are in agreement.
>
> Also note that JEP 444 says, "...the [virtual] thread can be garbage
> collected"  It doesn't say that the virtual thread MUST be garbage
> collected.
>
>
> On 2024-07-08 02:12 PM, Michal Domagala wrote:
> > Hi
> >
> > As a thread author, I would like to say I opened the thread because I
> > could not report a memory leak as a bug. Page
> > https://bugreport.java.com/bugreport/submit_start
> > <
> https://urldefense.com/v3/__https://bugreport.java.com/bugreport/submit_start__;!!ACWV5N9M2RV99hQ!O3-6Y8rB_Q3TnOXLeIa2WkhSm-X8hYgCkqwGAG4EqpVKaFgdKdh4kpH4juXWBBVbkBbMxFZDjRsTawE7Yeih$>
> does not work.
> >
> > In my understanding JEP 444 is finished and delivered in JDK 21. Any
> > deviation between JEP 444 and JDK 21 is a bug.
> > I hoped somebody will say "OMG" and start fixing procedure. But it seems
> > to me discussion concerns on JEP 444 - good or bad decision was taken.
> >
> > Personally, I have high confidence in the written word. Written word
> > convinced me that VT is GC'ed. It's very interesting to see other
> > opinions, but in my understanding the time is out of joint and seek for
> > help to set it right
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240709/8f1fce37/attachment-0001.htm>