Разработчики Firefox обозначили цели перехода на новую многопроцессную архитектуру

19 июля 2011 года

Один из разработчиков 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 показывает, что за всю историю существования проекта было обнаружено лишь несколько уязвимостей, позволяющих обойти многоуровневую защиту.

Источники

править


 
 
Creative Commons
Эта статья содержит материалы из статьи «Разработчики Firefox обозначили цели перехода на новую многопроцессную архитектуру», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию.
 
Эта статья загружена автоматически ботом NewsBots в архив и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.