On Mon, May 13, 2024 at 12:16 PM Brent Christian <brent.christ...@oracle.com> wrote:
> On 5/10/24 10:54 AM, Hans Boehm wrote: > > I'm not convinced this helps. > > > > The isAlive() spec says: > > > > "A thread is alive if it has been started and has not yet terminated." > > > > Clearly an object is reachable if it can be accessed by a thread that > will be started in the > > future. Is that part of a "potential continuing computation from any > live thread"? > > I would think; one "computation" a live thread can perform is to start > another thread, which in > turn might access the object. > > > I think the JLS wording is a bit sloppy about what "live thread" means > here. And that sloppiness > > is probably better than pointing at a precise definition that I'm not > sure really applies. > > > > "in any potential continuing computation from any live thread" really > seems to mean something > > like "in any continuing computation in which no finalizers are run"? > > Once an object becomes finalizer-reachable, it can only be reached via a > running finalizer. (JLS > 12.6.1: "A finalizer-reachable object can be reached from some finalizable > object through some chain > of references, but not from any live thread.") > > So maybe finalizer threads should not be considered "live" threads. > > > Even if the object is later accessed from an existing "live" thread, it > should not be considered > > reachable if that happens only after a finalizer later makes it > reachable again. > > Agreed - if an object can (*and only can*) be accessed again after a > finalizer resurrects it, that > doesn't count as "reachable". In fact, at that point, the object must have > transitioned from > reachable to finalizer-reachable. > > If an object gets resurrected by a finalizer, it does become reachable > again and can again be > accessed by the program. (And of course if the object's own finalizer ran, > it won't run again if the > object again stops being reachable.) > > > So I don't see why the thread from which the access happens matters at > all. > > I think it would only matter for accesses from a finalizer thread. > 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. 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.) Hans > > -Brent >
