Опишіть основні принципи роботи «збирача сміття» у JS-рушіях (engines).

Повне пояснення

Що це і навіщо

• Збирач сміття (garbage collector, GC) автоматично звільняє пам’ять, яку вже не використовують програми. Це критично для JS‑рушіїв (V8, SpiderMonkey, JavaScriptCore), де розробник не керує пам’яттю вручну.

Ключові принципи

• Reference counting: кожен об’єкт зберігає лічильник посилань. Коли лічильник стає нульовим, об’єкт вважається недоступним.
• Mark‑and‑sweep: збірник проходить по графу об’єктів, починаючи з коренів (global object, call stack), позначає живі вузли («mark»). Після цього усі непомічені об’єкти видаляються («sweep»).
• Generational GC: розділення пам’яті на молоду (new) і стару (old) генерації. Більшість об’єктів короткоживі, тому збірка молодої генерації швидка і частіша.
• Incremental / Concurrent GC: збірник розбиває роботу на маленькі кроки, щоб уникнути довгих пауз.

Як це працює (логіка)

1. Підготовка: рушій визначає корені – глобальні об’єкти, локальні змінні на стеку, замикання.
2. Mark: рекурсивний DFS по графу об’єктів, позначає живі вузли.
3. Sweep: проходить по пам’яті, видаляє непомічені об’єкти.
4. Compact (не всіх рушій): переміщує живі об’єкти, щоб звільнити фрагментовану пам’ять.

Практика і реалізація

• У V8: --max-old-space-size встановлює розмір старої генерації. --gc-interval контролює частоту збірки.
• У Node.js: global.gc() (з --expose-gc) викликає ручну збірку.

Тестування

// Jest + jsdom: перевірка, що об’єкт видаляється після знищення посилань
let obj = { a: 1 };
const weakRef = new WeakRef(obj);
obj = null; // позначаємо, що більше немає сильних посилань
setTimeout(() => {
  expect(weakRef.deref()).toBeUndefined();
}, 1000);

Дизайн‑рішення

• WeakMap / WeakSet: колекції, що не збираються як посилання.
• FinalizationRegistry: виконує колбек після збирання об’єкта.

Безпека і приватність

• GC не впливає на безпечність даних; однак неправильне використання WeakRef може призвести до утримання об’єктів.

Особливості в контексті JS‑рушій

• V8: generational + incremental, --turbo оптимізує збірку.
• SpiderMonkey: «nursery» + «tenured» області, --gc-interval.
• JavaScriptCore: «mark‑compact» з підтримкою --gc-interval.

Оптимізація, типові помилки

1. Memory leaks: циклічні посилання без WeakMap.
2. Over‑allocation: надмірна кількість об’єктів у молодій генерації.
3. Frequent GC: занадто часті виклики global.gc().
4. Large objects: великі масиви/об’єкти, що не помічаються швидко.
5. Stack overflow: рекурсивні об’єкти без базового випадку.
6. WeakRef misuse: очікування, що deref() поверне об’єкт після збірки.
7. FinalizationRegistry race: колбек може виконатися в будь-який момент.
8. Unbounded closures: замикання, що утримують великі об’єкти.

Cheatsheet

• GC trigger: global.gc() (Node), --expose-gc.
• Memory limits: --max-old-space-size=4096 (4 GB).
• Weak collections: new WeakMap(), new WeakSet().
• Finalization: new FinalizationRegistry((heldValue) => { … }).

Follow‑up питання

1. Як працює generational GC у V8?
2. Що таке WeakRef і коли його використовувати?
3. Які ризики пов’язані з FinalizationRegistry?