понедельник, 15 марта 2010 г.

Опровержение безобразия :)

В последнем посте я был неправ. Горькая правда в том, что странички кончиться не могут, ибо тут техника copy-on-write в действии. После успешного mmap() в адресное пространство подключается N раз одна единственная пустая страница с запрещённой записью. При обращении на запись ядро ловит protection fault, и делает копию пустой страницы. Таким образом, процесс очистки памяти получается ленивым.

Без реальной популяции замапленного региона (флагом MAP_POPULATE, либо прохождением с записью по страницам вручную) на моём проце (C2D T9600) munmap/mmap "ест" 1500-1600 тактов на область любого размера. Конечно, при первой записи в страницу (каждую) будет protection fault, который, как оказалось на практике, отнимает в районе 5000 тактов.

В сумме накладные расходы при размере страницы 4096 байт получаются 6500 тактов вместо 2000 при "честной" очистке, но ведь есть доказанный хирургический факт, что все свежеочищенные страницы в пуле памяти не будут нужны сию же минуту и все сразу. Поэтому с gc снимается часть нагрузки и размазывается по времени, уменьшая время ступора, в котором проводят треды при работающем gc. Отличное инженерное решение!

Наверное, честная очистка памяти средствами gc имеет смысл только при параллельном сборщике, работающем на выделенном ядре в smp-системе.

Комментариев нет:

Отправить комментарий

Архив блога