Збирання сміття в асинхронному контексті ​

У PHP збирач сміття зазвичай працює синхронно. Коли буфер можливих коренів переповнюється, у поточному контексті викликається gc_collect_cycles(). GC обчислює циклічні посилання та в циклі викликає деструктори об'єктів, позначених для видалення.

У конкурентному середовищі ця модель ламається. Деструктор об'єкта може викликати await — наприклад, щоб коректно закрити з'єднання з базою даних. Якщо GC виконується всередині корутини, await призупинить цю корутину, залишивши GC у незавершеному стані. Інші корутини побачать частково зібрані об'єкти.

Саме тому в TrueAsync довелося змінити логіку збирання сміття.

Корутина GC ​

Коли буфер gc_possible_root заповнюється і спрацьовує поріг, zend_gc_collect_cycles() запускає себе в окремій корутині.

ZEND_API int zend_gc_collect_cycles(void)
{
    if (UNEXPECTED(ZEND_ASYNC_IS_ACTIVE
        && ZEND_ASYNC_CURRENT_COROUTINE != GC_G(gc_coroutine))) {

        if (GC_G(gc_coroutine)) {
            return 0;  // GC вже виконується в іншій корутині
        }

        start_gc_in_coroutine();
        return 0;
    }

    // ... власне збирання сміття
}

Корутина, яка ініціювала GC, не блокується та продовжує свою роботу, а збирання сміття відбувається на наступному тіку Scheduler.

Корутина GC отримує власний Scope верхнього рівня (parent = NULL). Це ізолює збирання сміття від користувацького коду: скасування користувацького Scope не вплине на GC.

Деструктори в корутинах ​

Основна проблема виникає саме при виклику деструкторів, оскільки деструктори можуть несподівано призупинити корутину. Тому GC використовує алгоритм конкурентного ітератора на основі мікрозадач. Для запуску ітерації GC створює ще одну корутину-ітератор. Це зроблено для створення ілюзії послідовного виконання, що значно спрощує GC.

static bool gc_call_destructors_in_coroutine(void)
{
    GC_G(dtor_idx) = GC_FIRST_ROOT;
    GC_G(dtor_end) = GC_G(first_unused);

    // Створення дочірньої корутини для деструкторів
    zend_coroutine_t *coroutine = gc_spawn_destructors_coroutine();

    // Корутина GC призупиняється на dtor_scope
    zend_async_resume_when(GC_G(gc_coroutine), &scope->event, ...);
    ZEND_ASYNC_SUSPEND();   // GC засинає, поки виконуються деструктори

    return true;
}

Деструктор використовує механізм Scope не лише для контролю часу життя корутин, а й для очікування їх завершення. Для цього створюється ще один дочірній Scope, щоб інкапсулювати всі корутини-деструктори:

gc_scope                          <- верхній рівень `GC`
  \-- GC coroutine                <- маркування + координація
       \-- dtor_scope             <- дочірній scope
            \-- dtor-coroutine[0] <- виклик деструкторів (HI_PRIORITY)

Корутина GC підписується на подію завершення dtor_scope. Вона прокинеться лише тоді, коли всі деструктори в dtor_scope завершаться.

Що якщо деструктор викликає await? ​

Тут використовується класичний алгоритм конкурентного ітератора на основі мікрозадач:

• Реєструється мікрозадача, яка спрацює, якщо відбудеться перемикання контексту
• Якщо перемикання відбулося, мікрозадача створює ще одну корутину для продовження ітерації

Ітератор перевіряє, чи він все ще в тій самій корутині:

static zend_result gc_call_destructors(uint32_t idx, uint32_t end, ...)
{
    zend_coroutine_t *coroutine = ZEND_ASYNC_CURRENT_COROUTINE;

    while (idx != end) {
        obj->handlers->dtor_obj(obj);   // виклик деструктора

        // Якщо корутина змінилася — деструктор викликав await
        if (coroutine != NULL && coroutine != *current_coroutine_ptr) {
            return FAILURE;   // перервати обхід
        }
        idx++;
    }
    return SUCCESS;
}

Якщо ZEND_ASYNC_CURRENT_COROUTINE змінилася, це означає, що деструктор викликав await і поточна корутина заснула. У цьому випадку ітератор просто виходить, а наступний крок ітерації буде запущений у новій корутині.