DM
Классная штука. Как JS, но не JS 😂
В современной разработке фронтенда GC не особо то и нужен. Вот как например работает реакт - сработал обработчик события который поменял что-то в состоянии и вызывал перерендер приложеня в процессе которого аллоцируется дерево объектов (virtual-dom) дальше оно сравнивается с предыдущим деревом объектов и выполняются точечные изменения в дом-дереве.
Для такой аллокации объектов GC не нужен потому что эти объекты живут до следующего перерендера - для этого достаточно создать два фиксированных массива - в один аллоцируем новые объеты и сравниваем с предыдущим массивом ну и свапим при следующем рендере.
Дальше есть состояние которое мы меняем и которое является долгоживущим (сохраняется между перерендерами). Тут на первый взгляд кажется что нужен GC но если подумать то это состояние больше напоминает базу даных - всегда есть явное событие/интеншн когда нужно удалить тот или иной объект - например в состоянии хранится список тодо-задач и дальше юзер кликнул на кнопку "удалить" и нужно удалить такую-то задачу из списка. И зачастую код обработки этого события в реакте уже выполняет частично задачу GC - а именно берет и явно удаляет задачу из массива списка тодошек в состоянии и я не представляют что мешает дальше поверх этого с помощью удобного хелпера добавить деаллокацию объекта если на него нет больше ссылок.
То есть я вижу больше необходимость в аллокаторе-деаллокаторе и некой бд/орм-ке для объектов (которая будет заниматься подсчетом ссылок и удаленем внутренних объектов при удалении родительского а также разруливанем циклических сслыок) при разработке фронтенда а не в дженерик сборщике мусора (который будет заниматься сканированием ссылок от рут-сета оргомного дерева состояния)
