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

[Pedro Lamarão]

This seems to me a simple contradiction of requirements.
One cannot require that this program behaves as stated, that this thread
cannot proceed, and then require that the finally block runs.
Either the thread can proceed, or it cannot.
If it cannot, requiring that this thread runs code is nonsensical to me.
Perhaps one should just revise one's queue design and/or implementation to
avoid becoming "impossible" instead.
The fact the queue in question allows for "zombie platform thread" does not
seem a feature to me.
"zombie platform threads" is just a resource leak in a system with no
automatic resource reclamation.

Em qua., 31 de jul. de 2024 às 13:53, Robert Engels <rengels at ix.netcom.com>
escreveu:

> More importantly the reason to reclaim the VT would be to release its
> stack memory I assume. So then there are no rererences to a which would
> means would get reclaimed without running the finally. This is invalid.
>
> On Jul 31, 2024, at 11:50 AM, robert engels <robaho at icloud.com> wrote:
>
> 
> Correct and that is valid. Reclaiming a without running the finally block
> is invalid.
>
> On Jul 31, 2024, at 11:44 AM, Pedro Lamarão <pedro.lamarao at prodist.com.br>
> wrote:
>
> 
> if take cannot possibly proceed, then the body of the finally block will
> never, ever, run, and all memory involved has just leaked.
>
>
> Em qua., 31 de jul. de 2024 às 13:41, robert engels <robaho at icloud.com>
> escreveu:
>
>> To clarify, there is no other reference to the queue so take() cannot
>> proceed
>>
>> > On Jul 31, 2024, at 11:36 AM, robert engels <robaho at icloud.com> wrote:
>> >
>> > Ron,
>> >
>> > Given the following code 4 running in a VT:
>> >
>> > A a = new VeryLargeObjectWithFinalizer();
>> >
>> > try {
>> >    queue.take();
>> > } finally {
>> >   a.doSonething();
>> > }
>> >
>> > What in the Java spec would allow a to be reclaimed without
>> doSomething() being called?
>> >
>> > If a can’t be reclaimed then the reclaiming on VT in this case is
>> pointless.
>> >
>> >> On Jul 31, 2024, at 10:54 AM, Ron Pressler <ron.pressler at oracle.com>
>> wrote:
>> >>
>> >> 
>> >>
>> >>>> On 31 Jul 2024, at 15:24, Robert Engels <robaho at icloud.com> wrote:
>> >>>
>> >>> The purpose of the queue implementation is so that a VT is not left
>> running - hung on a queue that will never receive a value, and the reader
>> has a way of cleaning up cleanly if needed.
>> >>>
>> >>> I still don’t see how automatically “terminating/vanishing” the
>> reading thread when it can’t make progress will work.
>> >>
>> >> There is no automatic termination or vanishing of anything. A virtual
>> thread that cannot possibly ever have any effect and _already_ cannot be
>> accessed or observed in any way, may or may not have its memory reclaimed,
>> same as for all Java objects.
>> >>
>> >>>
>> >>> It will be an absolute nightmare to audit any system that relies on
>> this.
>> >>
>> >>
>> >> Every Java system relies on this already, as this is how Java’s GCs
>> have always worked.
>> >>
>> >>
>> >>> I confess I am not a JDK engineer but without special casing how can
>> the runtime know this - a special reference type for queue classes only?
>> I.e. the blocked reader is using a WeakReference internally? Today,
>> circular references are not circular in the context of a Thread GC root.
>> >>
>> >> There is nothing about queues or anything special here. No new kind of
>> vanishing or cleanup. Just about the GC reclaiming and reusing the heap
>> bytes of objects that have already vanished. If a thread can be observed,
>> then its memory won't be reclaimed. If it cannot, then whether or not the
>> bytes are reused is an internal implementation detail, just as it is for
>> any Java object.
>> >>
>> >> — Ron
>> >>
>> >>
>>
>
>
> --
> Pedro Lamarão
>
>

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240731/acf4d978/attachment-0001.htm>