Сегодня будет ещё один релизный пост. Пару часов назад в блоге V8 появился анонс фич, которые попадут в версию 7.8.

Script streaming — загрузка скриптов из сети в парсер без ожидания главного потока Chrome — теперь будет работать для preload-скриптов (в Chrome 76 и выше). Эта фича позволит сократить время инициализации страницы.

При компиляции JavaScript в байткод движок собирает специальные таблицы, которые матчат байткод на конкретные позиции в исходном коде. Эти таблицы потребляют память. С версии 7.8 они будут генерироваться, только во время создания стектрейсов. Разработчики пошли на компромисс, так как эта операция требует повторного парсинга и перекомпиляции. В результате потребление памяти было уменьшено на 1-2.5%.

Ускорили деструктуризацию объектов и работу регулярных выражений в случае, когда искомый паттерн не может быть найден в строке.

Поддержка Wasm С/C++ API перешла из экспериментального статуса в официальный. Это API позволяет использовать V8 как движок для исполнения WebAssembly в C/C++-приложениях. Был ускорен старт wasm-модулей.

#release #v8

https://v8.dev/blog/v8-release-78

Начиная с версии 7.9 в V8 изменяется работа с регулярными выражениями. Патрик Тиер и Ана Пешко написали пост с объяснением всех деталей — "Improving V8 regular expressions".

По умолчанию V8 компилирует регулярные выражения в нативный код при их первом запуске. Это влечёт за собой нагрузку на память. Около полугода назад как часть работы над "JIT-less V8" был добавлен интерпретатор для регулярных выражений. С версии 7.9 по умолчанию регулярные выражения будут исполняться с его помощью. Компиляция будет происходить только после того как одно и то же регулярное выражение будет выполняться несколько раз (hot-path). Новая стратегия позволяет уменьшить потребление оперативной памяти на 4-7%. Интерпретатор регулярных выражений был оптимизирован, теперь он в 2 раза быстрее. Это позволило не сильно просадить метрики по скорости относительно скомпилированных регулярок.

В статье много технических деталей того, как это всё работает. Читать сложно, но интересно.

#v8 #regexp #performance

https://v8.dev/blog/regexp-tier-up

Сегодня увидел в твиттере новость — в V8 v7.9 появилась реализация пропозала "RegExp Match Indices" (пока спрятана за экспериментальным флагом). Майа Лекова из команды разработки движка написала статью с объяснением, где он может быть полезен.

Методы Regexp#exec(), String#match() и String#matchAll() ищут заданный шаблон в строке и в случае успеха возвращают "match object". В нём находится индекс первого символа строки, который совпал с шаблоном. Этой информации недостаточно, если в выражении есть скобочные группы (capturing group), и если мы хотим получить позицию каждой сматченной группы. Именно эту проблему решает "Match Indicies" — он расширяет возвращаемый match object новым свойством indicies, в котором находятся позиции всех найденных групп. В статье есть пример того, как это свойство может быть использовано для понятного отображения ошибок парсинга кода.

На данный момент "RegExp Match Indices" находится на третьем этапе добавления в стандарт. Вполне возможно, что он попадёт в грядущий стандарт ECMAScript 2020 (ох... красивая цифра).

#js #regexp #proposal #v8

https://v8.dev/features/regexp-match-indices

Среди разработчиков иногда проскакивала шутка: "Что будет, когда V8 доберётся до версии V8?". И вот сегодня зарелизился V8 version 8.0 — V8. Лесджек Свирски рассказал про новые фичи в движке.

В новой версии было оптимизировано потребление памяти — график из статьи показывает падение на 40%. Оптимизация была достигнута за счёт компрессии tagged values (указателей на кучу V8 и small integers). Хорошим побочным эффектом оптимизации стало улучшение производительности движка на реальных сайтах. В статье мало подробностей, но обещают написать подробнее в другом посте.

Оптимизировали работу со встроенными в язык методами Function.prototype.apply, Reflect.apply и методами Array. Теперь код, в котором используются эти методы, оптимизируется с помощью Turbofan.

Теперь в движке есть полноценная поддержка Optional chaining и Nullish coalescing. Это новые фичи языка, которые помогают при обработке nullish-значений:

function Component(props) {
  const enable = props?.enabled ?? true;
  // …
}

#v8 #release #announcement

https://v8.dev/blog/v8-release-80

В блоге v8 появилась статья про использование SIMD в WebAssembly — "Fast, parallel applications with WebAssembly SIMD".

SIMD (Single Instruction, Multiple Data) — набор низкоуровневых инструкций процессора, которые позволяют распараллеливать обработку данных в рамках одного ядра. SIMD используется для ускорения работы кодеков, алгоритмов обработки изображений, компьютерного зрения и т.п. Чтобы web-приложения могли использовать SIMD-операции, разрабатывается расширение стандарта WebAssembly. В окончательном стандарте набор инструкций будет ограничиваться только теми инструкциями, которые можно использовать вне зависимости от архитектуры процессора.

Разработчики v8 представили экспериментальную реализацию предложения, благодаря ей демо отслеживания жестов рук ускорилось в пять раз. Демку можно запустить в последней версии Chrome, включив "WebAssembly SIMD support" в chrome://flags/.

#webassembly #v8

https://v8.dev/features/simd
https://storage.googleapis.com/mediapipe-viz.appspot.com/wasm-demos/hand-tracking-simd/hand_tracking_demo.html

Андрей Печкуров написал статью про внутреннее устройство Map в V8 — "[V8 Deep Dives] Understanding Map Internals".

В V8 для Map используется детерминированная хэш-таблица (deterministic hash table) — структура данных, которая гарантирует порядок обхода хранящихся в ней значений (в порядке их добавления в Map). Все данные для организации структуры данных находятся в одном большом массиве, который поделён на три логические части: заголовок, хэш-таблицу и данные. При добавлении и удалении значений из Map алгоритм периодически создаёт новую таблицу, поэтому операции вставки и удаления могут иметь временную сложность O(N). Операция извлечения данных из Map работает за O(1).

Интересная статья. Рекомендую почитать, если интересуетесь тем, как работает V8 изнутри.

#internals #v8 #algorithm

https://itnext.io/v8-deep-dives-understanding-map-internals-45eb94a183df

Зейнеп Канкара в блоге V8 написала статью про Indicium — новый инструмент рантайм анализа V8 — "Indicium: V8 runtime tracer tool".

Чтобы понять, зачем нужен этот инструмент, нужно немного разобраться в кишках V8. Для представления JavaScript-объектов V8 использует специальную структуру — Map (не тот Map, который определён в ECMAScript). Благодаря этой структуре движок экономит оперативную память при работе с большим числом однотипных объектов. Map в свою очередь использует оптимизацию Inline Cache (IC) для быстрого доступа к свойствам объектов.

Внутри V8 уже есть всё необходимое для получения информации о Map и IC, и уже есть готовые инструменты для их анализа. Indicium представляет эту информацию в удобном виде, связывая между собой Map и IC. С помощью него можно проанализировать создание объектов и быстро выявить проблемные места в исходном коде.

Indicium — это ещё один полезный инструмент для анализа проблем производительности в Chromium и Node.js.

#performance #tool #v8

https://v8.dev/blog/system-analyzer

В блоге V8 Мартин Бидлингмайер опубликовал статью про новый вспомогательный движок регэкспов, который позволяет избежать катастрофических откатов — "An additional non-backtracking RegExp engine".

V8 по умолчанию использует регэксп-движок Irregexp, который в свою очередь использует алгоритм бэктрекинга для проверки паттернов регэкспов. Этот алгоритм может приводить к катастрофическим откатам (сatastrophic backtracking). Катастрофический откат — это ситуация, когда проверка регулярного выражения не может быть выполнена за разумное время из-за экспоненциального роста количества возможных вариантов, которые должны быть обработаны движком. Катастрофические откаты могут использоваться для совершения DOS-атак, когда web-сервис обрабатывает входные данные пользователей с помощью регулярных выражений.

В V8 версии v8.8 был добавлен новый экспериментальный движок, который не подвержен проблеме экспоненциального взрыва, но гораздо медленнее (на данный момент) Irregexp. Его можно включить с помощью экспериментальных флагов V8.

Довольно хардкорная статья. Рекомендую почитать всем, кто интересуется темой разработки браузеров и безопасностью.

#v8 #security #internals

https://v8.dev/blog/non-backtracking-regexp

На прошлой неделе Ингвар Степанян рассказал о новых фичах девятой версии V8 — "V8 release v9.0".

В регулярных выражениях появилась поддержка флага /d, благодаря которому в результате выполнения регулярки (match object) появляется свойство indicies с позициями текущих скобочных групп (capturing group).

На порядки ускорен доступ к полям родительского объекта с помощью super.

Последовательность токенов for ( async of теперь больше не парсится.

В WebAssembly появилась экспериментальная поддержка инлайна враппера JS-to-Wasm для более эффективного преобразования параметров функций при их передаче из JS в Wasm. Эта фича будет особенно полезна в тех случаях, когда вызов Wasm-функции находится на горячем участке JavaScript-кода.

На данный момент V8 v9.0 находится в бете. Стабильная версия выйдет вместе с Chrome 90.

#v8 #release

https://v8.dev/blog/v8-release-90

Андрей Печкуров — участвует в разработке Node.js — написал статью про внутреннее устройство Math.random в V8 — "[V8 Deep Dives] Random Thoughts on Math.random()".

V8 использует генератор псевдослучайных чисел (PRNG), поставляемый окружением (Node.js, Chromium) или откатывается на системный источник случайности (например, /dev/urandom в Linux), если он не был задан в окружении. После того как генератор был проинициализирован seed-значением, все последующие случайные числа генерируются детерминировано с помощью алгоритма xorshift128+ и сохраняются в пуле из 64 значений, который заполняется по мере необходимости. Использование пула заранее сгенерированных случайных чисел очень распространённый подход, который используется при реализации PRNG.

Math.random не рекомендуется использовать для задач, связанных с безопасностью, потому что под капотом он не использует криптографически безопасный генератор псевдослучайных чисел (CSPRNG). Для таких задач вместо Math.random рекомендуется использовать генератор из Web Crypto API или модуля crypto в Node.js.

#js #v8 #internals #security

https://apechkurov.medium.com/v8-deep-dives-random-thoughts-on-math-random-fb155075e9e5

Поиск причины деградации времени сборки Webpack 5

Оуэн Хэннесси поделился историей поиска бага, из-за которого время запуска dev-сервера Webpack замедлилось в пятнадцать раз — "Understanding why our build got 15x slower with Webpack 5".

Проблема возникла после добавления невинной тёмной темы. Первые подозрения упали на CSS-in-JS-библиотеку Linaria. С помощью профилировщика внутри библиотеки была найдена проблемная функция, в которой использовался метод массива .concat(). Переписывание кода без использования .concat() решило проблему. Однако оставались вопросы, из-за того что в оригинальном коде просадки скорости не было при сборке проекта с помощью Webpack 4. Надо было исследовать исходники V8.

В V8 у метода .concat() есть две ветки выполнения кода — медленная и быстрая. Медленная ветка начинает работать в том случае, если движок хотя бы один раз устанавливал Symbol.isConcatSpreadable. В Webpack 5 это происходило в коде, отвечающем за обратную совместимость с четвёртой версией. Для решения проблемы разработчики Webpack добавили экспериментальную опцию backCompat, которая полностью отключает обратную совместимость, избавляясь от ещё большего количества проблемного кода.

#v8 #performance #webpack

https://engineering.tines.com/blog/understanding-why-our-build-got-15x-slower-with-webpack