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