В ночных сборках Firefox появилась
поддержка многопроцессного выполнения, подразумевающего вынос в разные
процессы средств формирования интерфейса и обработчиков контента.
Процесс, отвечающий за интерфейс, во многом напоминает базовый
однопроцессный вариант Firefox, он формирует окружение браузера на
основе XUL, выполняет дополнения, инициирует управление вкладками и
обеспечивает вывод окна. Отличие состоит в том, что обработка
содержимого вкладки выносится из данного базового процесса в отдельный
внешний процесс.
Результат компоновки интерфейса и обработки контента формируется в виде слоёв, которые определяют содержимое окна. Например, панели, меню и результат обработки контента определяются в отдельных слоях. Из разных процессов слои передаются в систему отрисовки, которая занимается сведением (композитингом) серии слоёв в единое изображение, определяющее итоговое содержимое окна браузера.
Разделение компонентов для обработки контента и формирования интерфейса в разные процессы позволяет заметно ускорить работу браузера на многоядерных системах за счёт организации параллельного выполнения не блокирующих друг друга операций. Потребление памяти в многопроцессном режиме мало отличается от обычного однопроцессного режима, разница составляет около 10 Мб, при этом планируемые оптимизации позволят снизить этот показатель.
Проект по переводу Fierfox на многопроцессную архитектуру, развиваемый под кодовым именем Electrolysis, стартовал в 2009 году, но в 2011 году был приостановлен из-за наличия более простых путей повышения отзывчивости интерфейса, не требующих значительной переработки архитектуры браузера (например, оптимизация работы сборщика мусора, дробление длительно выполняемых операций или их выделение в отдельный поток, использования асинхронного ввода/вывода и вынос выполнения плагинов в отдельные процессы). Спустя два года, когда более простые варианты оптимизаций уже воплощены в жизнь, разработчики вернулись к идее обработки контента и пользовательского интерфейса в разных процессах.
Новый режим уже доступен в ночных сборках
Firefox и может быть активирован через установку переменной
browser.tabs.remote в настройках about:config. Разработка пока носит
экспериментальный характер и не позволяет использовать некоторые
возможности браузера, такие как средства для web-разработчиков, вывод на
печать и сохранение страниц. Дополнения в новом режиме ведут себя
по-разному, некоторые работают нормально, а с некоторыми возникают
проблемы. В случае краха процесса, обрабатывающего содержимое вкладок,
процесс, отвечающий за формирование интерфейса, продолжает работу и
выводит предупреждение о крахе.
Раздельная обработка вкладок в разных процессах пока не
поддерживается, в текущий момент возможна работа только одного процесса
обработки контента. В будущем планируется обеспечение поддержки работы
нескольких процессов обработки контента (отдельные обработчики для
каждой вкладки).
Основные преимущества перехода к многопроцессной обработке:
source1
source2
Результат компоновки интерфейса и обработки контента формируется в виде слоёв, которые определяют содержимое окна. Например, панели, меню и результат обработки контента определяются в отдельных слоях. Из разных процессов слои передаются в систему отрисовки, которая занимается сведением (композитингом) серии слоёв в единое изображение, определяющее итоговое содержимое окна браузера.
Разделение компонентов для обработки контента и формирования интерфейса в разные процессы позволяет заметно ускорить работу браузера на многоядерных системах за счёт организации параллельного выполнения не блокирующих друг друга операций. Потребление памяти в многопроцессном режиме мало отличается от обычного однопроцессного режима, разница составляет около 10 Мб, при этом планируемые оптимизации позволят снизить этот показатель.
Проект по переводу Fierfox на многопроцессную архитектуру, развиваемый под кодовым именем Electrolysis, стартовал в 2009 году, но в 2011 году был приостановлен из-за наличия более простых путей повышения отзывчивости интерфейса, не требующих значительной переработки архитектуры браузера (например, оптимизация работы сборщика мусора, дробление длительно выполняемых операций или их выделение в отдельный поток, использования асинхронного ввода/вывода и вынос выполнения плагинов в отдельные процессы). Спустя два года, когда более простые варианты оптимизаций уже воплощены в жизнь, разработчики вернулись к идее обработки контента и пользовательского интерфейса в разных процессах.
Основные преимущества перехода к многопроцессной обработке:
- Оптимизация для многоядерных процессоров. В текущем виде для обработки всех страниц и интерфейса пользователя используется только одно ядро CPU, все остальные ядра простаивают и не участвуют в обеспечении работы браузера (за исключением ситуаций с выполнением плагинов). Несмотря на попытки использования многопоточности и вынос за пределы основного цикла обработки событий выполнения таких операций, как декодирование изображений, видео и звука, осуществление сетевых операций и ввода/вывода, по прежнему остаются однопоточными подсистема DOM (Document Object Model), функции формирования содержимого окна, парсинг HTML и выполнение JavaScript, т.е. для обработки контента может быть задействовано только одно ядро CPU.
- Предсказуемое потребление памяти. В длительно выполняемых процессах, при постоянном выделении и освобождении памяти разного размера со временем растет фрагментация и остается все больше небольших "дыр" от ранее освобожденных объектов, которые располагаются вперемешку с занятыми блоками памяти. В ситуации запроса памяти для размещения нового объекта, часто приходится запрашивать новые блоки у операционной системы, несмотря на наличие достаточно большого числа свободных областей во внутренней "куче", размер которых по отдельности меньше запрошенного блока. В случае обработки web-страниц разными процессами занятые процессом блоки памяти после завершения процесса полностью отдаются обратно операционной системе, а не остаются в "резерве", закрепленными за одним процессом в надежде, что эта память понадобится в будущем. Таким образом, обработка каждой вкладки отдельным процессом может привести к заметной экономии памяти (общие данные между процессами не дублируются, через мапинг используется только одна копия) и избавлению от проблемы с постоянным ростом размера процесса.
- Защита от сбоев. В случае выхода за пределы допустимой границы буфера или при возникновении другой нештатной ситуации при использовании однопроцессной модели обработки, крах процесса приведет к закрытию всех окон и вкладок. При обработке каждой страницы отдельным процессом, в случае сбоя закроется лишь одна вкладка, не повлияв на работоспособность браузера в целом. Кроме того, такой подход даст возможность упростить диагностику причины краха и позволит точно видеть какой сайт и какая операция привела к проблеме.
- Повышение безопасности. Обработка каждого сайта отдельным процессом позволяет изолировать связанный с ним код от обработчиков других сайтов и кода, обеспечивающего работу интерфейса, которые в случае выполнения разными процессами не могут пересекаться. Современные операционные системы позволяют перевести процесс в "режим пониженных прав", при котором блокируется доступ к большому числу системных ресурсов. В случае эксплуатации уязвимости в таком процессе, код злоумышленника будет ограничен в своих возможностях и не сможет выйти за пределы "песочницы". Для совершения атаки в подобных ситуациях требуется эксплуатация еще одной уязвимости в более привилегированном управляющем процессе.
source1
source2
