GC

[Amorph]

Для игровой разработки критично время GC.
Очень хорошо что бы на ряду с GC был ReferenceCounters, что бы можно было отказаться от GC вообще.

См. Squirrel

[unitpoint]

Первые релизы OS были с ReferenceCounters, но потом от него пришлось отказаться, т.к. он ничего не упрощал, если конечно мы хотим автоматически разруливать циклические зависимости. В текущей версии ReferenceCounters используется для "захватывания" объектов OS в пользовательском коде. За это отвечает external_ref_count в struct GCValue. GC пропускает объекты с external_ref_count > 0.

[Amorph]

Идея в том чтобы объект удалялся сразу после потери ссылки не прибегая к запуску GC.
Так как GC должен будет проверить все обьекты в VM, что как бы нагрузочно.
Это дает возможность не получить непонятные микрофризы, когда GC захочет что-то обработать( лечат инкрементальным GC, но это в принципе костыли ).
Так же было бы интересно реализовать пулл объектов на самом коде OS, который мониторит референсы и возвращает в пулл когда референсов 1( ссылка самого пула на объект ).

Подобные вопросы возникают из-за возникновения проблем с GC в Lua.
Архитектура моего игрового движка построена на принципе - если объект не уничтожился значит живет, по этому приходится GC вызывать каждый кадр, на маленьком количестве объектов это допустимо, но при увеличении количества объектов (сложность игровой сцены), растет и время обхода GC.
Если делать все через методы(эмулировать декструктор) то архитектура теряет простоту.

Есть даже эксперименты по переделки Lua на ReferenceCounters, которые поднимают его производительность в разы.

Резюмируя, для какой ниши Вы позиционируете OS? Если для игровой, то GC должен быть сугубо опциональным, так как стабильный FPS наше всё.

[unitpoint]

Так то оно так, но вот что я думаю по этому поводу:

1. если бы Lua с ReferenceCounters был бы быстрее, то он был бы с ReferenceCounters, т.к. основная ниша Lua - это как раз игровые проекты
2. отчасти первый пункт подтверждают мои собственные изыскания по этому вопросу, в теории оно все верно, но на практике говоря в общем, а не о каком-то конкретном случае, мне не удалось увеличить производительность с помощью ReferenceCounters, как так код выполняющий контроль самого счетчика нивелирует возможный выигрыш

Сейчас я занимаюсь оптимизацией (о чем напишу отдельную статью) и за последние пару дней мне удалось повысить производительность в 2 раза и я продолжаю оптимизировать. Вопрос уже идет на наносекунды, поэтому на счету любая лишняя команда или вызов функции.

P.S. в OS используется инкрементный GC

[Amorph]

1. Lua не с ReferenceCounters потому что GC позволяет ловить циклические зависимости, в большинстве случаев этого достаточно за глаза, так как ничего не ликует. Lua не был разработан для игровых проектов и до версии 5.1 не было инкрементального GC, и вообще lua для игровых проектов до WoW использовали не очень многие проекты.
2. ReferenceCounters дает выигрыш когда количество объектов которые должен обойти GC достаточно велико. Так как что проще, обойти 1000 объектов( хоть и за несколько раз ) или удалять объекты которые конкретно в то время когда они ненужны.

Поэтому вопрос разве нельзя это добавить опционально как в Python?
Или это противоречит с Вашим виденьем реализации языка?

[unitpoint]

1. текущее мое мнение, что ReferenceCounters даст выигрыш, если отказываться от автоматической ловли циклических ссылок, чего я делать пока не планирую
2. это не противоречит моим видениям, более того, я планировал и начал делать OS с использованием ReferenceCounters, но мне не удалось сделать его быстрее с помощью ReferenceCounters, а качество кода без ReferenceCounters намного улучшилось и сильно упростило многие внутренние решения

[Amorph]

Ок, спасибо, Вашу позицию по данному вопросу понял