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

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

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

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

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

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

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

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

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

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

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

Кстати, вы не инициализировали элементы массива (в этом случае 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.

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

mr (15.05.2006 16:23:38)

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

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

#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);
}

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

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

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

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

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

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

mr (15.05.2006 17:47:14)

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

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

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

mr (15.05.2006 17:55:26)

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

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

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

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

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

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

mr (15.05.2006 18:21:31)

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

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

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

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

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

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

mr (15.05.2006 18:38:26)

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

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

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

mr (15.05.2006 18:40:33)

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

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

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

mr (15.05.2006 18:47:39)

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

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

mr (15.05.2006 18:55:14)

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

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

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

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

mr (15.05.2006 19:21:39)

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

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

mr (15.05.2006 20:08:53)

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

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

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

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

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

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

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

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

Да вот, я подумал может какие другие способы есть. Нашёлся же 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)

mr (15.05.2006 20:35:28)

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

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

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

mr (15.05.2006 21:04:53)

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

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

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

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

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

mr (15.05.2006 21:29:51)

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

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

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

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

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

annoynimous (15.05.2006 21:40:58)

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

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

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

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

Да.

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

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

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

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

annoynimous (15.05.2006 22:08:45)

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

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

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

mr (15.05.2006 22:16:01)

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

+1

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

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

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

annoynimous (16.05.2006 10:41:51)

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

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