11 записей с тегом "внутренности"

Финальный уровень оптимизирующего компилятора V8 — Turbofan — известен тем, что является одним из немногих крупномасштабных компиляторов, использующих Море узлов (SoN). Однако, почти три года назад мы начали избавляться от Моря узлов и вернулись к более традиционному графу управления потоком (CFG) промежуточному представлению (IR), который мы назвали Turboshaft. На данный момент весь бэкенд JavaScript в Turbofan использует Turboshaft, и WebAssembly использует Turboshaft на протяжении всего своего конвейера. Две части Turbofan все еще используют некоторые элементы Моря узлов: встроенный конвейер, который мы постепенно заменяем на Turboshaft, и фронтенд JavaScript конвейера, который мы заменяем на Maglev, другое промежуточное представление на основе CFG. В этом посте объясняются причины, которые привели нас к отказу от Моря узлов.

В V8 мы постоянно стремимся улучшать производительность JavaScript. В рамках этих усилий мы недавно пересмотрели набор бенчмарков JetStream2, чтобы устранить узкие места производительности. В этом посте описывается конкретная оптимизация, которую мы внедрили, что привело к значительному улучшению результата async-fs в 2.5x, способствуя заметному улучшению общего счета. Оптимизация была вдохновлена этим бенчмарком, но подобные шаблоны действительно встречаются в реальном коде.

Среди разработчиков есть поговорка, что самый быстрый код — это код, который не выполняется. Аналогично, самый быстрый компиляционный код — это код, который не нужно компилировать. Кэширование кода WebAssembly — это новая оптимизация в Chrome и V8, которая старается избежать компиляции кода, кэшируя скомпилированный нативный код. Мы писали о том, как Chrome и V8 кэшируют JavaScript-код в прошлом, а также о лучших практиках использования этой оптимизации. В этом посте мы опишем, как работает система кэширования кода WebAssembly в Chrome и как разработчики могут использовать её для ускорения загрузки приложений с большими модулями WebAssembly.

Чтобы выполнить JavaScript-программу, исходный текст необходимо обработать, чтобы V8 мог его понять. V8 начинает с парсинга исходного текста в абстрактное синтаксическое дерево (AST), набор объектов, представляющих структуру программы. Это AST компилируется в байткод с помощью Ignition. Производительность этапов парсинга и компиляции важна: V8 не может выполнить код до завершения компиляции. В этой серии статей блога мы сосредоточимся на парсинге и работе, проделанной в V8, чтобы создать молниеносно быстрый парсер.

За последние годы сборщик мусора (GC) в V8 сильно изменился. Проект Orinoco преобразовал последовательный сборщик мусора с полной остановкой мира в в основном параллельный и конкурентный сборщик с плановой обратной связью.

V8 v6.9 включает Liftoff, новый базовый компилятор для WebAssembly. Liftoff теперь включён по умолчанию на настольных системах. В этой статье рассмотрены причины добавления ещё одного уровня компиляции, а также описаны реализация и производительность Liftoff.

V8 использует кэширование кода для кэширования сгенерированного кода часто используемых скриптов. Начиная с Chrome 66, мы кэшируем больше кода, создавая кэш после выполнения верхнего уровня. Это приводит к сокращению времени анализа и компиляции на 20–40% при первоначальной загрузке.

TL;DR: Ленивая десериализация была недавно включена по умолчанию в V8 v6.4, снижая потребление памяти V8 в среднем на более чем 500 КБ на вкладку браузера. Читайте дальше, чтобы узнать больше!

Введение в функции снапшотов V8​

Но сначала давайте отступим назад и посмотрим, как V8 использует снапшоты памяти для ускорения создания новых изолятов (что примерно соответствует вкладке в браузере Chrome). Мой коллега Ян Гуо дал хороший обзор на эту тему в своей статье о настраиваемых снапшотах запуска:

Сегодня мы рады объявить о запуске нового конвейера выполнения JavaScript для V8 v5.9, который достигнет Stable-версии Chrome в v59. С новым конвейером мы достигаем значительных улучшений производительности и значительной экономии памяти в реальных приложениях JavaScript. Мы обсудим цифры более подробно в конце этого поста, но сначала давайте взглянем на сам конвейер.

В предыдущем посте в блоге мы рассмотрели проблему джанка, вызванного сборкой мусора, которая прерывает плавный процесс просмотра. В этом посте мы представляем три оптимизации, которые являются основой для нового сборщика мусора в V8, кодовое название которого — Orinoco. Orinoco основан на идее реализации преимущественно параллельного и конкурентного сборщика мусора без строгих границ поколений, что позволит уменьшить джанк от сборки мусора и снизить потребление памяти, обеспечивая при этом высокую пропускную способность. Вместо того чтобы реализовывать Orinoco в виде отдельного сборщика мусора с флагом, мы решили постепенно вводить его функции в основной ветке V8, чтобы пользователи могли сразу извлечь из этого пользу. Три функции, обсуждаемые в этом посте, — это параллельная компактация, параллельная обработка запомненного набора и черное выделение.