<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">I can understand that reasoning but the problem is that it doesn’t align with current openjdk implementation. The observed behavior is the exact reason stop was deprecated with the exact same vulnerabilities. </div><div dir="ltr"><br><blockquote type="cite">On Aug 4, 2024, at 6:14 AM, Alex Otenko <oleksandr.otenko@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><p dir="ltr">I think the anguish may be coming from the GC / GC roots / finalizer behaviour being undefined. We'd all prefer things to be deterministic, but this one thing isn't.</p>
<p dir="ltr">So the solution is to not try and make a certain flavour of behaviour guaranteed, but to revisit our assumptions about the expected code behaviours. That some of our proofs of correctness may be based on implementation detail and not on real guarantees.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 4 Aug 2024, 12:05 robert engels, <<a href="mailto:robaho@icloud.com">robaho@icloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Avoiding was not the right word. Apologies. I only mean that I would like to understand the difference. I know it is at a know point vs arbitrary, but stop()could have been changed to only be at a safe point. Stop has an issue with possibly being in native code as well - but the deprecation justification doesn’t state any of this - only the stack unwinding which is the same issue that this capability in virtual thread has. <br>
<br>
> On Aug 3, 2024, at 7:00 PM, robert engels <<a href="mailto:robaho@icloud.com" target="_blank" rel="noreferrer">robaho@icloud.com</a>> wrote:<br>
> <br>
> Can you help me by stating why this is different than the thread stop?<br>
> <br>
> Because I think you could implement this by throwing a ThreadDeath - or as I suggested just reclaiming the memory. It feels like you are avoiding this issue for some reason.<br>
> <br>
>> On Aug 3, 2024, at 6:08 PM, Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank" rel="noreferrer">ron.pressler@oracle.com</a>> wrote:<br>
>> <br>
>> <br>
>> <br>
>>>> On 2 Aug 2024, at 15:58, robert engels <<a href="mailto:robaho@icloud.com" target="_blank" rel="noreferrer">robaho@icloud.com</a>> wrote:<br>
>>> <br>
>>> Sorry to keep this thread going but in reviewing my test results I think this capability is now dangerous, as I related to the Thread.stop(). It is going to be the same issue.<br>
>>> <br>
>>> A lot of native resource backed objects have Java shadows with finalizers / reference queues. If the referenced are released without traveling up the stack the program/system can be in an inconsistent state.<br>
>>> <br>
>>> Take for instance a file system lock file that is removed on finalization. This would be removed allowing other processing to continue even though the locking process never completed nor rolled back.<br>
>>> <br>
>>> Maybe you could argue it is a bad design to do this but I think the pattern with Cleaners, etc is fairly pervasive.<br>
>>> <br>
>>> By releasing the objects program order guarantees are broken - I don’t think it is valid to do this - especially concerning try/finally.<br>
>>> <br>
>>> As I also said you could maybe be very tricky and just release the memory but that isn’t what is happening here. It is collecting the objects which allows side effects through finalization and reference queues.<br>
>> <br>
>> <br>
>> You are absolutely right that finalizers (and reference queues/cleaners in general) are a dangerous feature that should be avoided, but that’s the case regardless of thread collection, and even in the case of thread stacks, remember that references on the stack may be collected even if the thread is reachable, which is why ReachabilityFence exists. It is simply *not* the case, neither in theory nor in practice, that only references that have been popped off the stack are collected. That is *not* a guarantee, and if it's your assumption, then you’re in for some surprises and shouldn’t use finalizers/cleaners. In fact, the general advice is not to use these mechanisms at all. They don’t work as most people might assume they do.<br>
>> <br>
>> Having said all that, collecting a thread whose references are already allowed to be collected is valid.<br>
</blockquote></div>
</div></blockquote></body></html>