<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2024 at 12:16 PM Brent Christian <<a href="mailto:brent.christian@oracle.com">brent.christian@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/10/24 10:54 AM, Hans Boehm wrote:<br>
> I'm not convinced this helps.<br>
> <br>
> The isAlive() spec says:<br>
> <br>
> "A thread is alive if it has been started and has not yet terminated."<br>
> <br>
> Clearly an object is reachable if it can be accessed by a thread that will be started in the <br>
> future. Is that part of a "potential continuing computation from any live thread"?<br>
<br>
I would think; one "computation" a live thread can perform is to start another thread, which in<br>
turn might access the object.<br>
<br>
> I think the JLS wording is a bit sloppy about what "live thread" means here. And that sloppiness <br>
> is probably better than pointing at a precise definition that I'm not sure really applies.<br>
> <br>
> "in any potential continuing computation from any live thread" really seems to mean something <br>
> like "in any continuing computation in which no finalizers are run"?<br>
<br>
Once an object becomes finalizer-reachable, it can only be reached via a running finalizer. (JLS<br>
12.6.1: "A finalizer-reachable object can be reached from some finalizable object through some chain<br>
of references, but not from any live thread.")<br>
<br>
So maybe finalizer threads should not be considered "live" threads.<br>
<br>
> Even if the object is later accessed from an existing "live" thread, it should not be considered<br>
>  reachable if that happens only after a finalizer later makes it reachable again.<br>
<br>
Agreed - if an object can (*and only can*) be accessed again after a finalizer resurrects it, that<br>
doesn't count as "reachable". In fact, at that point, the object must have transitioned from <br>
reachable to finalizer-reachable.<br>
<br>
If an object gets resurrected by a finalizer, it does become reachable again and can again be <br>
accessed by the program. (And of course if the object's own finalizer ran, it won't run again if the <br>
object again stops being reachable.)<br>
<br>
> So I don't see why the thread from which the access happens matters at all.<br>
<br>
I think it would only matter for accesses from a finalizer thread.<br></blockquote><div>I'm arguing that even that doesn't matter.  Let's say B is reachable from A, and A has a finalizer. Whether B is accessed directly by the finalizer from the finalizer thread, or the finalizer invokes some parallel algorithm on A, so that B is accessed by a helper "live thread" shouldn't matter. What does matter is that neither A nor B are reachable before the finalizer runs, because they can only be accessed as the result of a finalizer running.</div><div><br></div><div>I now wonder whether "A <em>reachable</em> object is any object that can be accessed in any potential continuing computation before any additional finalizers are started." wouldn't actually be a much better way to state this. (Officially, this wording is presumably nearly obsolete, since I don't think Cleaners or References have this particular issue. OTOH, that would also make it much clearer that this is so, and post finalizers, there is no issue here.)</div><div><br></div><div>Hans</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Brent<br>
</blockquote></div></div>