Примечание: Этот пост был первоначально опубликован в Google Security Blog.
Безопасность памяти в Chrome — это постоянные усилия по защите наших пользователей. Мы постоянно экспериментируем с различными технологиями, чтобы опередить злоумышленников. В этом духе эта публикация рассказывает о нашем опыте использования технологий сканирования кучи для улучшения безопасности памяти в C++.
Хотя название этой публикации может предположить углубление в сборник книг о масляных поддонах — тема, которая, учитывая строительные нормы для поддонов, оказалась неожиданно богатой литературой — мы вместо этого взглянем немного ближе на Oilpan, сборщик мусора для C++, который интегрирован в V8 как библиотека с версии V8 v9.4.
JavaScript позволяет вызывать функцию с количеством аргументов, отличающимся от ожидаемого числа параметров, т.е. можно передавать меньше или больше аргументов, чем объявлено в формальных параметрах. Первый случай называется недо-применением, а второй - пере-применением.
Начиная с версии v8.8, V8 поставляется с новым экспериментальным механизмом RegExp без обратного отслеживания (в дополнение к существующему движку Irregexp), который гарантирует выполнение за линейное время относительно размера входной строки. Экспериментальный механизм доступен за флагами функций, упомянутыми ниже.
Отслеживание неиспользуемого пространства — это способ дать новым объектам изначальный размер, который больше, чем они могут фактически использовать, чтобы новые свойства можно было добавлять быстро. А затем, по истечении некоторого времени, магическим образом вернуть неиспользованное пространство системе. Здорово, правда?
В прошлом мы уже писали статьи о сборке мусора для JavaScript, объектной модели документа (DOM) и о том, как все это реализовано и оптимизировано в V8. Однако не весь Chromium написан на JavaScript — большая часть браузера и его движка рендеринга Blink, где встроен V8, написаны на C++. JavaScript используется для взаимодействия с DOM, который затем обрабатывается рендерингом.
Существует постоянная борьба между памятью и производительностью. Как пользователи, мы хотим, чтобы программы работали быстро и потребляли как можно меньше памяти. К сожалению, обычно улучшение производительности приводит к увеличению расхода памяти (и наоборот).
В стандартной конфигурации V8 компилирует регулярные выражения в машинный код при первом выполнении. В рамках нашей работы над V8 без JIT, мы внедрили интерпретатор для регулярных выражений. Интерпретация регулярных выражений имеет преимущество в том, что требует меньше памяти, но приводит к снижению производительности. В этом блоге мы описываем, как мы используем преимущества интерпретации регулярных выражений, минимизируя их недостатки.
В конце 2018 года мы начали проект под названием V8 Lite, целью которого было значительно уменьшить использование памяти V8. Изначально этот проект был задуман как отдельный легкий режим V8, специально предназначенный для мобильных устройств с низким объемом памяти или сценариев использования, где важнее снижение использования памяти, чем скорость выполнения. Однако в процессе этой работы мы поняли, что многие из сделанных нами оптимизаций памяти для этого легкого режима можно перенести в обычный V8, тем самым улучшив его для всех пользователей.
Ранее мы обсуждали, как движки JavaScript оптимизируют доступ к объектам и массивам с помощью Shapes и Inline Caches, а также исследовали как движки ускоряют доступ к свойствам прототипа. В этой статье описано, как V8 выбирает оптимальные внутренние представления в памяти для различных значений JavaScript и как это влияет на механизм форм — что помогает объяснить недавнее падение производительности V8 в ядре React.