В Firefox 36 ожидается переход на многопроцессную архитектуру
План перевода основной ветки Firefox на многопроцессную архитектуру включает следующие этапы:
- 18 июля - доведение режима многопроцессной работы до готовности использования типовым пользователем ветки Nightly, но не включение такого режима по умолчанию;
- 21 июля - шесть недель с момента начала цикла разработки Firefox 34 будут выделены на тестирование режима многопроцессной работы и оценки его совместимости с дополнениями;
- 1 сентября - после старта цикла разработки Firefox 35 ожидается включение многопроцессного режима по умолчанию в ветке Nightly для прохождения второго этапа тестирования;
- 13 октября - начало разработки ветки Firefox 36, в которую будет интегрирована поддержка многопроцессного режима. Выпуск Firefox 36 ожидается 16 февраля следующего года.
Наиболее значительные препятствия на пути внедрения многопроцессной архитектуры возникают из-за проблем с совместимостью с дополнениями. В текущем виде совместимость с дополнениями оставляет желать лучшего, например, пока не работает большинство популярных дополнений, включая Adblock Plus, Tab Mix Plus, HTTPS-Everywhere, LastPass, Video DownloadHelper, Greasemonkey. Из работающих дополнений можно отметить Web Developer, Test Pilot и Flagfox. В общем виде, из 27 протестированных дополнений сразу заработали только 2 дополнения и ещё 4 удалось запустить после внесения изменений.
Основные преимущества перехода к многопроцессной обработке:
- Оптимизация для многоядерных процессоров. В текущем виде для обработки всех страниц и интерфейса пользователя используется только одно ядро CPU, все остальные ядра простаивают и не участвуют в обеспечении работы браузера (за исключением ситуаций с выполнением плагинов). Несмотря на попытки использования многопоточности и вынос за пределы основного цикла обработки событий выполнения таких операций, как декодирование изображений, видео и звука, осуществление сетевых операций и ввода/вывода, по-прежнему остаются однопоточными подсистема DOM (Document Object Model), функции формирования содержимого окна, парсинг HTML и выполнение JavaScript, т.е. для обработки контента может быть задействовано только одно ядро CPU.
- Предсказуемое потребление памяти. В длительно выполняемых процессах, при постоянном выделении и освобождении памяти разного размера со временем растёт фрагментация и остаётся все больше небольших "дыр" от ранее освобождённых объектов, которые располагаются вперемешку с занятыми блоками памяти. В ситуации запроса памяти для размещения нового объекта, часто приходится запрашивать новые блоки у операционной системы, несмотря на наличие достаточно большого числа свободных областей во внутренней "куче", размер которых по отдельности меньше запрошенного блока. В случае обработки web-страниц разными процессами занятые процессом блоки памяти после завершения процесса полностью отдаются обратно операционной системе, а не остаются в "резерве", закрепленными за одним процессом в надежде, что эта память понадобится в будущем. Таким образом, обработка каждой вкладки отдельным процессом может привести к заметной экономии памяти (общие данные между процессами не дублируются, через мапинг используется только одна копия) и избавлению от проблемы с постоянным ростом размера процесса.
- Защита от сбоев. В случае выхода за пределы допустимой границы буфера или при возникновении другой нештатной ситуации при использовании однопроцессной модели обработки, крах процесса приведет к закрытию всех окон и вкладок. При обработке каждой страницы отдельным процессом, в случае сбоя закроется лишь одна вкладка, не повлияв на работоспособность браузера в целом. Кроме того, такой подход даст возможность упростить диагностику причины краха и позволит точно видеть какой сайт и какая операция привела к проблеме.
- Повышение безопасности. Обработка каждого сайта отдельным процессом позволяет изолировать связанный с ним код от обработчиков других сайтов и кода, обеспечивающего работу интерфейса, которые в случае выполнения разными процессами не могут пересекаться. Современные операционные системы позволяют перевести процесс в "режим пониженных прав", при котором блокируется доступ к большому числу системных ресурсов. В случае эксплуатации уязвимости в таком процессе, код злоумышленника будет ограничен в своих возможностях и не сможет выйти за пределы "песочницы". Для совершения атаки в подобных ситуациях требуется эксплуатация еще одной уязвимости в более привилегированном управляющем процессе.
Источник: http://www.opennet.ru/opennews/art.shtml?num=40193
|
0 | Tweet | Нравится |
|