Bon Echo Alpha 2 - на пути к Firefox 2.0

>Скажем так - память, выделенная приложению, практически никогда не уменьшается. Если в какой-то момент приложение схавало под свои нужды 200 Мб, то выделенная ему память меньше за данный сеанс уже не станет, сколько бы приложение ни делало free. Просто эти участки памяти будут помечаться как пустые, а при следующей попытке выделения памяти именно эти куски приложению и будут выдаваться. Я, правда, не знаю, что станет, если приложения таким сакаром выжрут всю доступную системе память. glibc таки начнёт урезать выделенную им память или просто приступит к убиению наиболее прожорливых?

Вы любезный видимо как говорят на лоре жабабыдлокодер? Очень точно описано поведение java. Тут товарисч привел программешку - вам в пику. Возьмите 'pmap -d' в зубья и просвещайтесь до опупеоза.

>Нажимайте ENTER и смотрите, сколько ест программа. Тем же top'ом :)

Топом не смотрите, а смотрите 'pmap -d' в данном случае writable/private.

> даже пресловутый IE в седьмой версии стал больше похож на браузер

в очередной раз убеждаюсь что йоперщики, фарщики и зебатщики - латентные и натуральные вантузятники

Кстати, вы не инициализировали элементы массива (в этом случае top показывает только ~300K), это надо сделать так:
  for(i=0;i<16*1024;i++)
  {
    M[i*1024]='c';
  }
  for(i=0;i<1024;i++)
  {
    M1[i*1024]='c';
  }

Я повторяю анонимусам: вы ошибаетесь. Да, эта программа будет освобождать память. 
Но только потому, что выделяется огромный массив: >128K, в этом случае glibc malloc использует mmap.
Если вы попробуете выделять память большим количеством маленьких кусков, то ничего не получится.
А именно так и происходит в firefox.

Пример дать или сами напишите?

Да. К сожалению, именно так и получается... :(

#include <stdio.h>
#include <stdlib.h>

int main(int argc,char* argv[])
{
  typedef char* pchar;
  
  pchar M[1024];
  char InBuf[128];
  unsigned int i,j;

  printf("Application just started; ENTER to continue\n");
  gets(InBuf);
  for (i=0;i<1024;i++) {
    M[i]=(char *)malloc(16*1024*sizeof(char));
    for (j=0;j<16;j++) M[i][j*1024]='c';
  }
  printf("Allocated 16 MBytes; ENTER to continue\n");
  gets(InBuf);
  for (i=0;i<1023;i++) free(M[i]);
  printf("15 MBytes freed; ENTER to continue\n");
  gets(InBuf);
  free(M[1023]);
  printf("1 MByte freed; ENTER to exit\n");
  gets(InBuf);
}

Кстати, в данном конкретном случае кусков по 16K поможет MALLOC_MMAP_THRESHOLD_=4096 ./test

Но для firefox это не подойдёт, так как там очень маленькими кусками память выделяется (~20 байт).

В предке glibc malloc, dlmalloc, есть возможность использовать только mmap (gcc -DHAVEMORECORE=0).
Но эта возможность, к сожалению, не подкреплена правильными для mmap алгоритмами размещения кусков.

В общем, надо переносить из OpenBSD mmap'нутую реализацию malloc (или писать свою).

Кстати, ни у кого из вас нет знакомых программистов/студентов-программистов,
которые могли бы сделать такую работу?

Конечно, аллокатор из OpenBSD libc 3.8/3.9 это не панацея, но всё же значительно превосходит аллокатор glibc по части фрагментации памяти.

Люди! Ищите людей!

btw, в bugzilla.mozilla.org на эту тему пока все стихло.

People, у кого mozilla|firefox|seamonkey на linux , проголосуйте за ентот баг, plz:

https://bugzilla.mozilla.org/show_bug.cgi?id=324081

Может, опять тему в талкс создать? :) Создавать до полного просветления, ещё и ещё, пока все не проголосуют!

А смысл? Этим всё равно. Лемминги ничего подобного не замечают, они привыкли приложения перезапускать по многу раз на день. И потом, у них просто: если компьютер тормозит - то обычно винда виновата, так что все шишки всё равно полетят в MS :)

Если уж пинать, то авторов glibc.

Авторы glibc, по-моему, такие же непробиваемые, как и авторы firefox :)

http://live.gnome.org/MemoryReduction/ Кстати, никто не знает что такое g_slice?

http://mail.gnome.org/archives/gtk-devel-list/2005-December/msg00031.html

Что-то любопытное...

http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slices.html

Что это такое??? Хочу попробовать.

Уже качнул :) ftp://ftp.gtk.org/pub/gtk/v2.9/glib-2.9.6.tar.bz2

Не нашел ничего про mmap в описании реализации.

Наверно, это что-то типа smart-pointer или как это назывется...

Что-то не заметно, чтобы этот g_slice освобождал память :(

> Что-то не заметно, чтобы этот g_slice освобождал память :(

А сейчас, видимо, никто этим не заморачивается. Память дешёвая, чего её освобождать? :)

Дык mmap() значицца мало юзает :)

В смысле g_slice не использует mmap().

Да вот, я подумал может какие другие способы есть. Нашёлся же madvise. Нет, сегодня это не пройдёт.

Одного только не могу понять, к чему относятся слова на том гнумовском сайте:

Note that the following discussions have been obsoleted by the development of the new g_slice API in GLib, which uses ideas from the slab allocator (MatthiasClasen)

Получается, что g_slice это просто извращённая обёртка над обычным malloc.

Итак, надо ковырять всё-таки OpenBSD malloc...

абыдна. Возможно, g_slice под скорость заточен, а не под минимум размера кучи.

Возможно, у него также как-то улучшен алгоритм размещения кусков дополнительно к glibc malloc... По исходнику сложно что-то понять. В любом случае, нам он вряд ли поможет.

Эх, где бы найти человека с достаточной квалификацией и свободным временем...

> Может, опять тему в талкс создать? :) Создавать до полного просветления, ещё и ещё, пока все не проголосуют!

А кто не проголосует, тому отключим свет и газ (c)

А что, firefox на с++ писан, что ли, раз такая проблема с памятью? Похоже, не аллокатор нужно писать, а сборщик мусора/уплотнитель памяти.

Это начало агонии FF

> что, firefox на с++ писан,

Да.

> Похоже, не аллокатор нужно писать, а сборщик мусора/уплотнитель памяти.

Под windows 2000 проблемы нет, код firefox тот-же самый, но: под wine firefox-win32 не отдает память, так же как и родной ==> проблема в libc.

я не ошибся: программе нужен сборщик мусора, ибо бездумно полагаться на системную библиотеку при виделении/освобождении памяти все же не стоит. Как я понимаю смысл проблемы - куча сильно фрагментируется - есть много свободной памяти в виде мелких "дырок", которые системная библиотека не считает нужным/возможным возвратить системе. Достаточно соорудить сборщик, который дефрагментирует/уплотнит память и все будет ОК.

По-моему, это невозможно--программа работает с самими указателями и значит указатели не могут меняться в процессе работы.

Для этого нужна лишняя прослойка в виде smart-pointers (или как там оно называется), т.е. существенное переписывание всего кода firefox.

+1

Да это понятно, что надо писать правильно...

Тут даже не smart-pointers, а что-то типа master-pointers. Интересно, может правда проще переписать реализацию allocator'а, чем править кривой код?

Проще. На OpenBSD память ядру возвращается в ожидаемых кол-вах, аллокатор там не использует sbrk(), создает много куч mmap()ом. При free() делается munmap() / mremap().