Разработчики Firefox обозначили цели перехода на новую многопроцессную архитектуру
Один из разработчиков Mozilla сообщил о возобновлении работ, связанных с проектом Electrolysis, в рамках которого запланирован перевод Firefox на многопроцессную архитектуру, при которой пользовательский интерфейс и обработка контента будут обрабатываться разными процессами. Кроме того, рассматривается возможность использования многопроцессной модели для обеспечения полной изоляции отдельных вкладок, виджетов, групп вкладок и страниц одного домена.Часть наработок проекта уже интегрирована в Firefox 4 и используется для выполнения плагинов в отдельных процессах. Кроме того, в Mobile Firefox 4.0 для платформы Android уже задействован механизм обработки вкладок разными процессами. Отмечается, что процесс перехода на многопроцессную модель достаточно сложен и длителен, новая архитектура будет внедряться постепенно. Конкретные сроки не указаны, но с учетом 16-недельного цикла подготовки релизов, новые наработки можно будет увидеть не раньше, чем в версии Firefox 8. По заявлению разработчиков Mozilla, каждый новый релиз Firefox будет быстрее и стабильнее, интерфейс станет более отзывчивым.
В качестве основных факторов, рассматриваемых при планировании перехода к многопроцессной архитектуре, называются:
- Производительность. Ключевым достоинством разделения подсистем обработки контента и формирования интерфейса пользователя является повышение отзывчивости бразуера, т.е. повышение скорости реакции на действия пользователя и исключение "подвисаний". В настоящее время разработчики стараются обеспечить в основном цикле обработки событий однопроцессной модели вызов обработчика пользовательского интерфейса не реже, чем раз в 50 мс. Но несмотря на это пользователи все равно сталкиваются с проблемами с интерактивностью, так как однопроцессная архитектура подразумевает использование общей кучи и сборщика мусора, т.е. используется одно хранилище для данных пользовательского интерфейса и всех обрабатываемых страниц.
В конечном итоге наблюдается увеличение фрагментации хранилища и время поиска сборщиком мусора неиспользуемых объектов. Во время работы сборщика мусора основной цикл обработки событий приостанавливается и наблюдается замедление реакции на действия пользователя, вплоть до секундных подвисаний. В Firefox 4 предпринято несколько попыток улучшения интерактивности, например, для разных классов объектов в хранилище задействованы отдельные методы сборки мусора, а также уменьшен интервал активации сборщика мусора. Тем не менее, все проблемы не решены, а лишь найдены временные обходные пути для определенных ситуаций. Например, проблемы с интерактивностью продолжают наблюдаться при очистке памяти после работы больших web-приложений.
- Оптимизация для многоядерных процессоров. В текущем виде для обработки всех страниц и интерфейса пользователя используется только одно ядро CPU, все остальные ядра простаивают и не участвуют в обеспечении работы браузера (за исключением ситуаций с выполнением плагинов). Несмотря на попытки использования многопоточности и вынос за пределы основного цикла обработки событий выполнения таких операций, как декодирование изображений, видео и звука, осуществление сетевых операций и ввода/вывода, по прежнему остаются однопоточными подсистема DOM (Document Object Model), функции формирования содержимого окна, парсинг HTML и выполнение JavaScript, т.е. для обработки контента может быть задействовано только одно ядро CPU.
Самым простым выходом из сложившейся ситуации является реализация возможности запуска нескольких DOM-обработчиков в виде отдельных процессов, которые смогут работать параллельно не мешая друг другу. Одновременно развивается альтернативный проект, поддержка многопоточной работы DOM-подсистемы в котором будет обеспечена путем переписывания кода на языке Rust, напоминающем C++, но поддерживающем автоматическое управление памятью и выполнение задач в виде легковесных сопрограмм.
- Предсказуемое потребление памяти. Значительными проблемами в Firefox остаются: большая фрагментация памяти, трудности с перераспределением памяти, невозможность отдачи уже полученной от ОС памяти и утечки памяти. Данные проблемы не являются специфичными для Firefox и неизбежно возникают у любого длительно работающего процесса, интенсивно манипулирующего блоками памяти. В случае выделения памяти разного размера со временем растет фрагментация и остается все больше небольших "дыр" от ранее освобожденных объектов, которые располагаются вперемешку с занятыми блоками памяти. В ситуации запроса памяти для размещения нового объекта, часто приходится запрашивать новые блоки у операционной системы, несмотря на наличие достаточно большого числа свободных областей во внутренней "куче", размер которых по отдельности меньше запрошенного блока.
В случае обработки web-страниц разными процессами занятые процессом блоки памяти после завершения процесса полностью отдаются обратно операционной системе, а не остаются в "резерве", закрепленными за одним процессом в надежде, что эта память понадобится в будущем. Таким образом, обработка каждой вкладки отдельным процессом может привести к заметной экономии памяти (общие данные между процессами не дублируются, через мапинг используется только одна копия) и избавлению от проблемы с постоянным ростом размера процесса.
- Защита от сбоев. Очевидно, что в случае выхода за пределы допустимой границы буфера или при возникновении другой внештатной ситуации при использовании однопроцессной модели обработки, крах процесса приведет к закрытию всех окон и вкладок. При обработке каждой страницы отдельным процессом, в случае сбоя закроется лишь одна вкладка, не повлияв на работоспособность браузера в целом. Кроме того, такой подход даст возможность упростить диагностику причины краха и позволит точно видеть какой сайт и какая операция привела к проблеме. В частности, уже реализованная технология выноса плагинов в отдельные процессы позволила заметно увеличить надежность работы, например, крах Flash-плагина больше не отражается на работе браузера.
- Повышение безопасности. Обработка каждого сайта отдельным процессом позволяет изолировать связанный с ним код от обработчиков других сайтов и кода, обеспечивающего работу интерфейса, которые в случае выполнения разными процессами не могут пересекаться. Современные операционные системы позволяют перевести процесс в "режим пониженных прав", при котором блокируется доступ к большому числу системных ресурсов. В случае эксплуатации уязвимости в таком процессе, код злоумышленника будет ограничен в своих возможностях и не сможет выйти за пределы "песочницы". Для совершения атаки в подобных ситуациях требуется эксплуатация еще одной уязвимости в более привилегированном управляющем процессе. Практика браузера Chrome показывает, что за всю историю существования проекта было обнаружено лишь несколько уязвимостей, позволяющих обойти многоуровневую защиту.
Полный текст статьи читайте на OpenNet
