[External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads
Ron Pressler
ron.pressler at oracle.com
Sat Jul 6 20:28:54 UTC 2024
> 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
More information about the loom-dev
mailing list