В рамках проекта MemShrink развернута борьба с утечками памяти в Firefox

Несмотря на предпринятые оптимизации, потребление памяти в Firefox 4 оставляет желать лучшего. Осознавая, что проблема с потреблением памяти недооценена и требует срочного решения, в рамках инициативы MemShrink [3] несколько разработчиков решили [4] форсировать [5] процесс выявления и устранения утечек памяти в браузере. Первая встреча участников инициативы MemShrink состоялась [6] 14 июня, на встрече обсуждены находящиеся в процессе устранения известные утечки памяти, рассмотрены дополнительные способы сбора данных о проблемах распределения памяти, утвержден план действий и упомянута необходимость привлечения к работе дополнительных разработчиков. Отныне встречи будут проходить еженедельно, на них будут обсуждаться все новые сообщения о проблемах, так или иначе связанных с потреблением памяти, данные проблемы будут проанализированы и закреплены за разработчиками, ответственными за их устранение.
Кроме устранения известных проблем, работа также будет направлена на создание [7] новых механизмов профилирования и мониторинга потребления памяти, которые помогут выявлять проблемы на ранней стадии и повысить оперативность локализации причин ошибок. Так же рассматриваются [8] варианты задействования эвристических методов перераспределения памяти в сборщике мусора, повышения способов эффективности хранения внутренних структур и оптимизации компонентов, связанных с распределением памяти.
По мнению [5] одного из разработчиков Mozilla, актуальность проблемы косвенно доказывает рост отправляемых пользователями уведомлений о недоработках и проблемах, связанных с потреблением памяти. После выхода Firefox 4 поступает большое число уведомлений, в которых указываются факты заметного увеличения потребления памяти, по сравнению с прошлыми версиями Firefox. При этом расход памяти в процессе работы браузера со временем неуклонно увеличивается, что свидетельствует об утечках памяти. В настоящий момент под наблюдением находится информация [9] о более 80 неустраненных утечках памяти.
В зависимости от важности проблемы, утечки разбиты на три категории: P1 [10] - ошибки, затрагивающие всех пользователей и требующие незамедлительного решения; P2 [11] - приоритет по умолчанию, ошибки средней степени важности; P3 [12] - ошибки, затрагивающие небольшую группу пользователей и проявляющиеся при определенном стечении обстоятельств, например, при сочетании нескольких установленных дополнений.
По своему типу, утечки памяти классифицированы следующим образом:

• Реальные утечки памяти, при которых память теряется навсегда;
• Продолжительное невозвращение памяти, например, когда для освобождения большого блока памяти требуется закрытие вкладки, окна, страницы или процесса;
• Неоптимальное поведение сборщика мусора в некоторых ситуациях;
• Плохие алгоритмы кэширования и неоптимальные настройки параметров кэшей;
• Проблема с фрагментацией памяти.

Отдельный интерес вызывают методы мониторинга изменения потребления памяти в процессе разработки Firefox. В настоящее время уже развернута инфраструктура для периодического автоматизированного тестирования потребления памяти в процессе открытия 100 наиболее популярных сайтов в сети. В случае, если для очередной тестовой сборки Firefox фиксируется заметный рост потребления памяти, то разработчикам направляется соответствующее уведомление. К сожалению, система тестирования не лишена недостатков, например, отсутствует эмуляция реального поведения пользователей, не производится изменение при одновременном открытии нескольких страниц в разных вкладках, не учитывается специфика различных операционных систем. Из других подобных систем мониторинга упоминается ресурс arewefastyet.com [13], на котором ежедневно тестируется производительность Firefox, Google Chrome и Apple Safari.
Из планов на будущее отмечается создание системы автоматизированного тестирования, в которой будут использоваться дополнительные инструменты профилирования памяти, такие как Valgrind и trace-malloc. Рассматривается идея задействования методов статического анализа для автоматического выявления определенных классов утечек памяти. Планируется более широкое внедрение дополнения telemetry [14], позволяющего непрерывно накапливать информацию о потреблении памяти в процессе работы и учитывать в случае выявления проблем специфичные для данного сеанса вещи, такие как список открытых страниц. Также подготовлена встроенная реализация telemetry, не требующая внешнего дополнения и собирающая данные об изменении отраженных в "about:memory" параметров, числе открытых табов и прочей не привязанной к пользователю статистики. Возможно создание дополнительных решений на базе тестового фреймворка Mozmill [15], позволяющего непрерывно измерять параметры работающей копии браузера.