Firefox, OpenBSD allocator

У меня меняется - файрфокс начинает часто падать.

в about:config откючи browser.cache.memory.enable.
Если интересно, то у меня есть пара сравнительных тестов про фф - с этим аллокатором и с glibc.
nka at users.mns.ru

Кстати, а у тебя архитектура какая?

> У меня меняется - файрфокс начинает часто падать.

Аналогично.

> скачиваю, компилю и запускаю как по инструкции, результат нулевой, абсолютно ничего не меняется

В LD_PRELOAD=/path/to/lib.so надо указать _полный_ путь, иначе библиотека не подгрузится, и загрузчик прикрутит *alloc(), free() из glibc.

memory cache отключать не обязательно.

Падений mozilla-1.7.13, seamonkey-1.0.*, firefox-1.0.*, firefox-2.* из-за этой библиотеки не помню. Сборки с mozilla.org и свои с --enable-default-toolkit=gtk1 и --enable-optimize=...

Дистрибутивы Scientific Linux CERN 3.0.*, ALT Master 2.4, Slackware 10.2.

Могу привести .mozconfig'и.

Кроме того, на slackware 10.2 без сбоев работает LD_PRELOAD=.... startx c запуском KDE.

Падучесть видел на ALT Sysiphus новее ALM 3.0

Вот такой мой чайницкий опыт за полгода.

^^^ везде i586/i686 ! не x86_64!

всё так и делаю, memory cache тоже пробовал отключать, пробовал иксы с PRELOAD запускать - ни-фи-га

Давай по порядку: uname -a, дистрибутив, версия Firefox, строчка с компиляцией *.so, строчка с запуском, как смотрел размер памяти.

Чтобы знать. что *alloc, free действительно слинковались при загрузке, вставь в malloc/free/realloc сообщения: http://wwwppds.ihep.su/~zenin_o/patch.

$ gcc -fPIC -shared -o libdbg.so исходник_библиотеки.c

$ LD_PRELOAD=`pwd`/libdbg.so program

Если program слинковалась с *alloc, free из libdbg.so, на stderr будут строки вида

malloc: 7 ret: 0x401c3340

free: 0x401f8000 ok.

форум шуткует c URL.

http://wwwppds.ihep.su/~zenin_o/patch.dbg

>Давай по порядку: uname -a, дистрибутив, версия Firefox, строчка с компиляцией *.so, строчка с запуском, как смотрел размер памяти.

2.6.18-3-k7, debian testing, firefox 2.0.0.1 c mozilla.org, gcc -shared -fPIC -O2 OpenBSD_malloc_Linux.c -o malloc.so, LD_PRELOAD=/path/to/malloc.so firefox, ps aux

Проверь сначала, действительно ли firefox линкуется при загрузке с нужными *alloc, free. См. сообщение выше.

Не знаю, k7 -- i386 или x86_64? Тестировал только на 32-х разрядах.

Смотреть на память лучше так:

$ while true ; do ps -eo pid,vsz,rss,sz,cmd | grep -E -- "firefox-bin|RSS" ; sleep 3s; done

Смотри на изменение колонок VSZ (вирт. память процесса) и RSS (занятая физич, память). С LD_PRELOAD=... цифры в них _заметно_ уменьшаются, когда, например закрываешь вкладки. Без LD_PRELOAD=... VSZ никогда не уменьшается заметно.

Открой и закрой ~70 вкладок из троллевского примера: http://polar.ihep.su:8002/tab.html

c LD_PRELOAD RSS должно быть ~60M после закрытия вкладок, без LD_PRELOAD ~150M

>Смотреть на память лучше так:
>$ while true ; do ps -eo pid,vsz,rss,sz,cmd | grep -E -- "firefox-bin|RSS" ; sleep 3s; done

да, действительно, получается!

открывал под сотню табов с картинками и текстом, правда в основном локально, вот что вышло:

VSZ RSS
105256 25536 - открытие с пустой страницы
145976 63156 - после загрузки
126100 46116 - после закрытия всех табов

ради интереса попробовал подобное в opera:

VSZ RSS
36384 20968
152844 131776
62352 41292

ну а если просто в firefox:

VSZ RSS
103060 23540
143028 61900
141200 60832

Количество и качество табов не очень совпадает, но всё таки заметно что opera откушала побольше.
И всё таки тут видно что далеко не вся память возвращается, куда остальное то девается? (20 метров не лишне)

>Не знаю, k7 -- i386 или x86_64? Тестировал только на 32-х разрядах.

AMD k7 это 32
AMD x86_64 это уже k8

> Количество и качество табов не очень совпадает, но всё таки заметно что opera откушала побольше.

Зависит от открываемых страниц. На открытии страниц из Talks opera кушает меньше ff.

> И всё таки тут видно что далеко не вся память возвращается, куда остальное то девается?

Фрагментация памяти.

На пальцах так:

когда открывали табы, набор отmmapленных страниц (обозначаем их как [-----], размер страницы 4096 байт по умолчанию) в результате вызовов malloc() заполнен данными, например, так:

[######-] [######] [###---] ... -- '#' обозначает занятый диапазон адресов а странице, '-' -- свободный.

После закрытия табов в результате вызовов free() получаем, например, такую картинку:

[--#----] [#-----] [------]

Пустую (3-ю) страницу можно munmapить, т,е, 4096 байт вернутся ядру. В первой и второй странице остались занятые куски, а отmunmapить можно только страницу целиком. Из таких частично освобожденных страниц складывается "лишняя" память. При последуюших вызовах malloc/realloc она будет использоваться, но если вызван malloc(size) c size > самой большой дыры в страницах, то будет mmapлена следующая страница. Если и она будет потом освобождена не полностью, то размер VM процесса будет в среднем расти, хоть он и заметно уменьшается каждый раз, когда закрываем много табов.

этот баг я так понимаю с libc связан, не знаешь отправлен ли он его разработчикам?

Это не баг, а фича. (c) Менять алгоритм malloc в glibc из-за нескольких криво работающих с памятью программ на с++ не стОит, имхо. Почему стандартный алгоритм в glibc оптимален для большинства существующих программ: google ptmalloc, dlmalloc, doug lea.