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

[Pedro Lamarão]

Certainly it would be incorrect to execute the finally block after
reclaiming a.
But the finally block, in this case, will never, ever, run.
Therefore, the machine will never, ever, execute the finally block after
reclaiming a.
No execution ordering mistake can be made by the machine here.
That this whole situation is undesirable seems to be a particular case of
the general undesirability of deadlocks.
Unfortunately, in the machine under consideration, threads are allowed to
deadlock -- both "platform" and "virtual".
Since it is out of question to require that deadlocks be impossible, one
must accept that the finally block may not execute, and etc. etc.

Em qua., 31 de jul. de 2024 às 14:52, robert engels <robaho at icloud.com>
escreveu:

> Right but then you can’t reclaim ‘a’ especially with a finalizer but even
> then it will break all sorts of things even when it doesn’t.
>
> On Jul 31, 2024, at 12:25 PM, Pedro Lamarão <pedro.lamarao at prodist.com.br>
> wrote:
>
> 
> In the situation being considered, the finally block will never, ever, run.
> What is the meaning of requiring that this effect be ordered before or
> after some point in time?
> Effects that will never, ever, happen, have no place in time to be ordered
> here or there.
> The machine cannot fail to properly order an effect that will never, ever,
> happen.
>
> Em qua., 31 de jul. de 2024 às 14:16, robert engels <robaho at icloud.com>
> escreveu:
>
>> More specifically, it is that ‘a’ cannot be reclaimed and the finally not
>> run. This breaks the program ordering guarantees as related to
>> retainability.
>>
>> On Jul 31, 2024, at 11:59 AM, Pedro Lamarão <pedro.lamarao at prodist.com.br>
>> wrote:
>>
>> 
>> 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.
>>
>>
> --
> Pedro Lamarão
>
>

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