В Firefox запланировано включение по умолчанию многопроцессного режима

Аса Доцлер (Asa Dotzler), координатор сообщества разработчиков Firefox, сообщил о скором переходе Firefox на многопроцессный режим (e10s, electrolysis). Отмечается, что многопроцессный режим доведён до полной функциональной готовности и отвечает всем критериям качества, стабильности, потребления памяти и производительности, предъявляемым к функциональности, включаемой в стабильные выпуски.

Новый режим будет включён в состав Firefox 48 и активирован по умолчанию для тестирования у примерно 1% пользователей, не использующих дополнения. В зависимости от хода тестирования процент охвата будет меняться, например, в случае отсутствия проблем охват аудитории может быть увеличен, а при непредвиденных проблемах тестирование может быть прервано. В сентябрьском выпуске Firefox 49 планируется включить многопроцессный режим для всех пользователей, которые не используют дополнения (по оценке Mozilla около 40% от всех пользователей) и в течение 30 дней не включали средства для людей с ограниченными возможностями.

Напомним, что проект e10s стартовал в 2009 году, после чего несколько раз приостанавливался и возвращался в строй. В ноябре 2014 года наработки e10s были включен в ночные сборки Firefox, в мае 2015 года вошли в состав Firefox Developer Edition, а в апреле 2016 года по умолчанию предложены 50% пользователей бета-версии Firefox 47. В Firefox 48 Beta будет произведено включение e10s для всех пользователей.

Ключевым отличием нового режима является вынос обработки содержимого вкладок в отдельный процесс, который функционирует отдельно от процесса, занимающегося формированием интерфейса, что позволяет увеличить безопасность, повысить отзывчивость интерфейса, минимизировать подвисания во время сборки мусора и заметно ускорить работу браузера на многоядерных системах за счёт организации параллельного выполнения неблокирующих друг друга операций. Обратной стороной медали является несовместимость с достаточно большим числом дополнений, например, c новым режимом несовместимы около 20% из протестированных дополнений, включая NoScript, Ghostery, Flash Video Downloader, Adblock Edge, Web of Trust и Disconnect.

Основное отличие текущей реализации от многопроцессной модели Chrome состоит в том, что вся обработка контента вынесена в один внешний процесс, без разбиения обработчиков отдельных вкладок на процессы. Процесс, отвечающий за интерфейс, во многом напоминает базовый однопроцессный вариант Firefox, он формирует окружение браузера на основе XUL, выполняет дополнения, инициирует управление вкладками и обеспечивает вывод окна. Результат компоновки интерфейса и обработки контента формируется в виде слоёв, которые определяют содержимое окна. Содержимое передаются в систему отрисовки, которая занимается сведением (композитингом) серии слоёв в единое изображение, определяющее итоговое содержимое окна браузера. В будущем запланирован второй этап развития e10s, на котором планируется обеспечить работу нескольких процессов обработки контента (например, можно будет разделить обработчики для каждого дополнения и каждой вкладки).

Основные цели перехода к многопроцессной обработке:

• Оптимизация для многоядерных процессоров. В текущем виде для обработки всех страниц и интерфейса пользователя используется только одно ядро CPU, все остальные ядра простаивают и не участвуют в обеспечении работы браузера (за исключением ситуаций с выполнением плагинов). Несмотря на попытки использования многопоточности и вынос за пределы основного цикла обработки событий выполнения таких операций, как декодирование изображений, видео и звука, осуществление сетевых операций и ввода/вывода, по-прежнему остаются однопоточными подсистема DOM (Document Object Model), функции формирования содержимого окна, парсинг HTML и выполнение JavaScript, т.е. для обработки может быть задействовано только одно ядро CPU.

• Предсказуемое потребление памяти. В длительно выполняемых процессах, при постоянном выделении и освобождении памяти разного размера со временем растет фрагментация и остается все больше небольших "дыр" от ранее освобожденных объектов, которые располагаются вперемешку с занятыми блоками памяти. В ситуации запроса памяти для размещения нового объекта, часто приходится запрашивать новые блоки у операционной системы, несмотря на наличие достаточно большого числа свободных областей во внутренней "куче", размер которых по отдельности меньше запрошенного блока. В случае разделения обработчиков на процессы фрагментация заметно снижается, а при отдельной обработке web-страниц разными процессами занятые процессом блоки памяти после завершения процесса полностью отдаются обратно операционной системе, а не остаются в "резерве", закрепленными за одним процессом в надежде, что эта память понадобится в будущем. Таким образом, обработка каждой вкладки отдельным процессом может привести к заметной экономии памяти (общие данные между процессами не дублируются, через мапинг используется только одна копия) и избавлению от проблемы с постоянным ростом размера процесса.

• Защита от сбоев. В случае выхода за пределы допустимой границы буфера или при возникновении другой нештатной ситуации при использовании однопроцессной модели обработки, крах процесса приведет к закрытию всех окон и вкладок. При обработке каждой страницы отдельным процессом, в случае сбоя закроется лишь одна вкладка, не повлияв на работоспособность браузера в целом. Кроме того, такой подход даст возможность упростить диагностику причины краха и позволит точно видеть какой сайт и какая операция привела к проблеме.
• Повышение безопасности. Обработка каждого сайта отдельным процессом позволяет изолировать связанный с ним код от обработчиков других сайтов и кода, обеспечивающего работу интерфейса, которые в случае выполнения разными процессами не могут пересекаться. Современные операционные системы позволяют перевести процесс в "режим пониженных прав", при котором блокируется доступ к большому числу системных ресурсов. В случае эксплуатации уязвимости в таком процессе, код злоумышленника будет ограничен в своих возможностях и не сможет выйти за пределы "песочницы". Для совершения атаки в подобных ситуациях требуется эксплуатация еще одной уязвимости в более привилегированном управляющем процессе.