Быстрый запуск JavaScript является ключом к отзывчивости веб-приложений. Даже с продвинутыми оптимизациями V8, парсинг и компиляция критически важных JavaScript во время запуска могут оставаться узкими местами производительности. Знание функций JavaScript, которые нужно скомпилировать при первоначальной компиляции скрипта, может ускорить загрузку веб-страниц.
Финальный уровень оптимизирующего компилятора V8 — Turbofan — известен тем, что является одним из немногих крупномасштабных компиляторов, использующих Море узлов (SoN). Однако, почти три года назад мы начали избавляться от Моря узлов и вернулись к более традиционному графу управления потоком (CFG) промежуточному представлению (IR), который мы назвали Turboshaft. На данный момент весь бэкенд JavaScript в Turbofan использует Turboshaft, и WebAssembly использует Turboshaft на протяжении всего своего конвейера. Две части Turbofan все еще используют некоторые элементы Моря узлов: встроенный конвейер, который мы постепенно заменяем на Turboshaft, и фронтенд JavaScript конвейера, который мы заменяем на Maglev, другое промежуточное представление на основе CFG. В этом посте объясняются причины, которые привели нас к отказу от Моря узлов.
В V8 мы постоянно стремимся улучшать производительность JavaScript. В рамках этих усилий мы недавно пересмотрели набор бенчмарков JetStream2, чтобы устранить узкие места производительности. В этом посте описывается конкретная оптимизация, которую мы внедрили, что привело к значительному улучшению результата async-fs в 2.5x, способствуя заметному улучшению общего счета. Оптимизация была вдохновлена этим бенчмарком, но подобные шаблоны действительно встречаются в реальном коде.
API JavaScript Promise Integration (JSPI) позволяет приложениям WebAssembly, которые были написаны с расчётом на синхронный доступ к внешней функциональности, работать корректно в среде, где функциональность фактически является асинхронной.
В API интеграции JavaScript Promise (JSPI) WebAssembly появился новый API, доступный в Chrome версии M126. Мы расскажем, что изменилось, как использовать это с Emscripten, и как выглядит дорожная карта JSPI.
JSPI — это API, который позволяет приложениям WebAssembly, использующим последовательные API, обращаться к веб-API, которые являются асинхронными. Многие веб-API работают с объектами JavaScript Promise: вместо непосредственного выполнения запрашиваемой операции они возвращают Promise для выполнения. С другой стороны, многие приложения, скомпилированные в WebAssembly, приходят из мира C/C++, где доминируют API, блокирующие вызвавшего до завершения операции.
Спустя почти три года после первоначального проектного документа и сотен CL за это время, песочница V8 — лёгкая песочница в процессе выполнения для V8 — достигла стадии, когда её больше не считают экспериментальной функцией безопасности. Начиная с сегодняшнего дня, Песочница V8 включена в Программу вознаграждений за уязвимости Chrome (VRP). Хотя ещё остаётся множество задач, которые нужно решить, прежде чем песочница станет надёжной границей безопасности, включение её в VRP является важным шагом в этом направлении. Таким образом, Chrome 123 можно рассматривать как своего рода «бета» выпуск песочницы. Этот пост в блоге использует эту возможность для обсуждения мотивации создания песочницы, демонстрации того, как она предотвращает распространение повреждения памяти в V8 внутри хост-процесса, и объяснения, почему это необходимый шаг на пути к безопасности памяти.
JavaScript Promise Integration (JSPI) API для WebAssembly входит в этап внутреннего тестирования с выпуском Chrome версии M123. Это означает, что вы можете протестировать, принесли ли вы и ваши пользователи пользу от этого нового API.
JSPI — это API, который позволяет так называемому последовательному коду, скомпилированному для WebAssembly, получать доступ к веб-API, которые являются асинхронными. Многие веб-API разработаны на основе JavaScript Promise: вместо немедленного выполнения запрашиваемой операции они возвращают Promise для ее выполнения. Когда действие наконец выполнено, планировщик задач браузера вызывает любые обратные вызовы с Promise. JSPI интегрируется в эту архитектуру, позволяя приложению WebAssembly приостанавливать выполнение при возврате Promise и возобновлять выполнение, когда Promise разрешается.
Вы когда-нибудь задумывались, откуда взялись undefined, true и другие основные объекты JavaScript? Эти объекты являются основами любых пользовательских объектов и должны существовать первыми. V8 называет их неизменяемыми корнями, которые располагаются в собственной куче – только для чтения. Так как они постоянно используются, быстрый доступ крайне важен. А что может быть быстрее правильного угадывания их адреса в памяти на этапе компиляции?
Добро пожаловать в захватывающий мир V8, где скорость — это не просто функция, а образ жизни. Наступил момент попрощаться с 2023 годом и отпраздновать впечатляющие достижения, которых V8 достиг в этом году.
Благодаря инновационным оптимизациям производительности V8 продолжает расширять границы возможного в постоянно меняющемся ландшафте Веба. Мы представили новый компилятор среднего уровня и реализовали множество улучшений в инфраструктуре компилятора высокого уровня, среде выполнения и сборщике мусора, что привело к значительному увеличению скорости работы.
В Chrome M117 мы представили новый оптимизирующий компилятор: Maglev. Maglev расположен между нашими существующими компиляторами Sparkplug и TurboFan, выполняя роль быстрого оптимизирующего компилятора, который создает достаточно хороший код достаточно быстро.
До 2021 года V8 имел два основных уровня исполнения: Ignition, интерпретатор; и TurboFan, оптимизирующий компилятор V8, ориентированный на максимальную производительность. Весь код JavaScript сначала компилируется в байт-код Ignition и исполняется путем интерпретации. Во время выполнения V8 отслеживает поведение программы, включая формы объектов и типы. Метаданные выполнения и байт-код поступают в оптимизирующий компилятор для генерации высокопроизводительного, часто спекулятивного машинного кода, который работает значительно быстрее, чем интерпретатор.