Интересные моменты из доклада о JS движке - "Nova", который пишется как "самый интересный движок на rust" человеком из комьюнити Deno

🔸Под капотом использует парсер OXC
🔸 В нем вообще нету AST для VM.
🔸Дизайн движка - DoD (Data Oriented Design).
🔸Ориентирован на экономию места в кэше, для того чтобы сделать максимально быстрым доступ к большинству базовых вещей в js.
🔸 Исходный код структурирован так чтобы отражать EcmaScript спеку 1 в 1. В плане - папки с кодом названы так же как разделы спеки, например.

Что интересного можно узнать из доклада:

🔹в ARM архитектуре заложены специальные инструкции для работы с числами, то как с дробными, то как с целыми, в зависимости от операций, что идеально ложится на то как Number работает в js (совпадение?)

🔹v8 хранит числа попадающие в i32 прямо в стеке, вперемешку вместе с ссылками на другие типы, которые тоже представлены как числа. Значения которые являются настоящими числами а не ссылками специальным образом помечаются. JavaScriptCore поступает аналогично, но хранит в стеке f64.
Это позволяет работать с числами очень быстро, но подобный код считается небезопасным (unsafe) в парадигме rust. Кроме того это полностью ломает управление кэшами в ARM (как то связано с криптографией, но этот момент не был достаточно раскрыт).

🔹Вместо этого в Nova решили использовать Enum для хранения типа, и Vec для хранения значения, что позволило упаковать указатели, и реализовать Value (u8, u32).
В оставшиеся 7 байт впихнули самые популярные строки которые используются в js - value, length, data, т.е. они тоже хранятся в стеке и к ним очень быстрый доступ.

🔹 Вместо того чтобы наследовать все не примитивные типы от объекта, т.е. в стиле ООП, используется компонентный подход. Например массивы не наследуются от объекта, а изначально тупые и приближенные к нативному массиву, так как в основном они используются в таком виде, и только в случае если массив используется каким-то способом специфичным для js (например при попытке перебрать свойства прототипа, или добавить новое свойство, т.е. не числовой индекс и и.т.п) создается обертка в виде объекта, что замедляет "странное" использование массивов, но сильно ускоряет "обыкновенное"

🔹Окончание доклада немного скомканное, т.к. у докладчика заканчивалось время, но насколько я понял, благодаря расту им удалось сделать очень быстрый сборщик мусора, так как движок, в силу особенностей работы с памятью в расте, помечает что нужно почистить прямо в то время, как закончил работу с объектом, так что сборщику не нужно потом прыгать по памяти в поиске того что нужно почистить.
(Этот пункт я возможно понял вообще не правильно)
Больше деталей о сборщике мусора и его особенностях есть в блоге автора, там же добавляет что после его доклада многие заинтересовались и присоединились к проекту, и его так же пригласили рассказать о движке на митинге TC39

Ссылка на доклад
Ссылка на реп