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