Примечание: Этот пост был первоначально опубликован в Google Security Blog.
Безопасность памяти в Chrome — это постоянные усилия по защите наших пользователей. Мы постоянно экспериментируем с различными технологиями, чтобы опередить злоумышленников. В этом духе эта публикация рассказывает о нашем опыте использования технологий сканирования кучи для улучшения безопасности памяти в C++.
Хотя название этой публикации может предположить углубление в сборник книг о масляных поддонах — тема, которая, учитывая строительные нормы для поддонов, оказалась неожиданно богатой литературой — мы вместо этого взглянем немного ближе на Oilpan, сборщик мусора для C++, который интегрирован в V8 как библиотека с версии V8 v9.4.
В прошлом мы уже писали статьи о сборке мусора для JavaScript, объектной модели документа (DOM) и о том, как все это реализовано и оптимизировано в V8. Однако не весь Chromium написан на JavaScript — большая часть браузера и его движка рендеринга Blink, где встроен V8, написаны на C++. JavaScript используется для взаимодействия с DOM, который затем обрабатывается рендерингом.
Существует постоянная борьба между памятью и производительностью. Как пользователи, мы хотим, чтобы программы работали быстро и потребляли как можно меньше памяти. К сожалению, обычно улучшение производительности приводит к увеличению расхода памяти (и наоборот).
В конце 2018 года мы начали проект под названием V8 Lite, целью которого было значительно уменьшить использование памяти V8. Изначально этот проект был задуман как отдельный легкий режим V8, специально предназначенный для мобильных устройств с низким объемом памяти или сценариев использования, где важнее снижение использования памяти, чем скорость выполнения. Однако в процессе этой работы мы поняли, что многие из сделанных нами оптимизаций памяти для этого легкого режима можно перенести в обычный V8, тем самым улучшив его для всех пользователей.
Этот пост описывает технику сборки мусора, называемую параллельной маркировкой. Оптимизация позволяет JavaScript-приложению продолжать выполнение, пока сборщик мусора сканирует кучу для нахождения и маркировки живых объектов. Наши тесты показывают, что параллельная маркировка сокращает время, затрачиваемое на маркировку в главном потоке, на 60%–70%. Параллельная маркировка является последним элементом проекта Orinoco — проекта по постепенной замене старого сборщика мусора новым, в основном параллельным и многопоточным сборщиком мусора. Параллельная маркировка включена по умолчанию в Chrome 64 и Node.js v10.
Отладка утечек памяти в Chrome 66 стала намного проще. В инструментах разработчика Chrome теперь можно трассировать и создавать снимки C++ DOM объектов, а также отображать все достижимые DOM объекты из JavaScript с их ссылками. Эта функция является одним из преимуществ нового механизма трассировки C++ сборщика мусора V8.
Объекты JavaScript в V8 размещаются в куче, управляемой сборщиком мусора V8. В предыдущих публикациях в блоге мы уже обсуждали, как мы уменьшаем время пауз при сборке мусора (неоднократно) и потребление памяти. В этом посте мы представляем параллельный Scavenger, одну из последних функций Orinoco, преимущественно параллельного сборщика мусора V8, и обсуждаем принятые проектные решения и альтернативные подходы, которые мы реализовали в процессе.
Потребление памяти является важным аспектом в пространстве компромиссов производительности виртуальной машины JavaScript. За последние несколько месяцев команда V8 проанализировала и значительно уменьшила объем потребляемой памяти на нескольких веб-сайтах, которые были определены как представители современных шаблонов веб-разработки. В этом блоге мы представляем используемые рабочие нагрузки и инструменты анализа, описываем оптимизации памяти в сборщике мусора и показываем, как мы сократили потребление памяти парсером и компиляторами V8.
Лаги, или, другими словами, заметные задержки, могут быть обнаружены, когда Chrome не удаётся отобразить кадр за 16.66 мс (нарушая движение в 60 кадров в секунду). На сегодняшний день большая часть работы V8 по сборке мусора выполняется в основном потоке рендеринга, см. Рисунок 1, что часто приводит к лагам, когда необходимо обрабатывать слишком много объектов. Устранение лагов всегда было важным приоритетом для команды V8 (1, 2, 3). В этой статье обсуждаются некоторые оптимизации, которые были реализованы между Chrome 41 и Chrome 46 и значительно сокращают паузы при сборке мусора, обеспечивая более качественный пользовательский опыт.