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

[Michal Domagala]

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

sob., 6 lip 2024 o 23:32 Ron Pressler <ron.pressler at oracle.com> napisał(a):

>
>
> > On 4 Jul 2024, at 21:34, Brian S O'Neill <bronee at gmail.com> wrote:
> >
> > On 2024-07-04 11:43 AM, Ron Pressler wrote:
> >>> On 3 Jul 2024, at 18:27, robert engels <rengels at ix.netcom.com> wrote:
> >>>
> >>> I agree 100% - I am fighting that the auto-closing of the queues,
> clean-up, etc is “unneeded magic”
> >> There is no auto-closing, no cleanup, and no magic. If a thread gets
> stuck in a state where it can never be observed or continued — so if it is
> NOT waiting on a queue to which something could be enqueued because in that
> case the thread COULD possibly continue — then whether that thread consumes
> some inaccessible bytes in memory or not is the same as far as
> functionality is concerned.
> >
> > What about the case that that freeing a forever-stuck VT allows more
> objects to be freed, which then might have cleaning actions? Freeing the
> stuck VT could create a side effect that would have only occurred when it
> resumed somehow.
>
> Whatever differences there may be, you could see similar differences when
> selecting a different GCs. Any functionality that depends on decisions made
> by the GC is at the mercy of a particular algorithm that may also change
> from one JDK release to another for a specific GC (and so probably should
> be avoided).
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240708/f79f205f/attachment.htm>