Ref counting based object release is not applied if cycle is broken in destructor during GC run

[mvorisek]

Description

repro: https://3v4l.org/USrWu

see UPDATE below

It seems the GC can be improved. Currently, when a cycle is broken during GC run, a 2nd run of GC is needed to really release the object.

b58d74547f "solves this issue" since PHP 8.2+, but is that the most efficient solution for everything? If a cycle (all cycles/references to an object) is explicitly broken during GC, is there anything againts releasing that object by standard refcounting?

Resulted in this output:

d
gc
bool(true) <- notice object is kept alive after the destructor has broken the cycle (and refcount dropped to 0)
gc rerun
bool(false)
bool(false)
done

But I expected this output instead:

d
gc
bool(false)
gc rerun
bool(false)
bool(false)
done

UPDATE:

Based on https://3v4l.org/mgoqd I would call this a bug as 2nd WeakReference::get() call is expected to always give the same result if no GC is run in between the calls.

PHP Version

any (tested PHP 7.4, 8.3)

Operating System

any

[arnaud-lb]

It seems the GC can be improved. Currently, when a cycle is broken during GC run, a 2nd run of GC is needed to really release the object.

To be precise, this is only the case for objects with destructors. That's because an object may resurrect itself during destruction:

class C {
    public function __destruct() {
        global $c;
        $c = $this;
    }
}

It may be possible to avoid it in simple cases, like in your example when the refcount falls to zero after destruction, but most cases will require a re-scan anyway. I think there are ways to detect resurrections, but I don't know if they are applicable to our case, or if they are efficient.

Destructors are always tricky for GCs.

I you have examples where this is causing performance issues, I may try to take a look.

Based on https://3v4l.org/mgoqd I would call this a bug as 2nd WeakReference::get() call is expected to always give the same result if no GC is run in between the calls.

What is happening in this case is that the Cycle object returned by the first call to get() already had its destructor called, had refcount of 0, and was scheduled for scanning again in the next GC run. get() increases its refcount to 1, but after $ref->get() !== null is evaluated it is decreased to 0 again, and the object is freed. This should be safe, as the GC is aware that calling dtors may free other objects.

expected to always give the same result if no GC is run in between the calls

Relying on this would be very fragile, since the GC may run anytime an object refcount is decremented between the two calls. E.g. $ref->get() increases the refcount of $ref before the call, then decreases it after the call, which may trigger a GC. (Found a leak while trying to demonstrate this, I will investigate.)

[mvorisek]

It may be possible to avoid it in simple cases, like in your example when the refcount falls to zero after destruction

This is exactly what this issue is about.

The standard behaviour of PHP is to immediately release an object if refcount is decreased to zero. In GC, I would expect the same check on the destructed instance after destructor is called. If refcount is zero, release that object.