LINUX.ORG.RU

Навеяло сегодняшней ибм-овской статьёй


0

0

Наверное никогда не дождусь когда опубликуют чонить о взаимодействии аллокатора памяти и системы.

Меня вот что в частности интересует. Например гугл предложил свою реализацию менеджера кучи с разделением по размерам аллоцируемых кусков, естественно есть и другие модели - у каждого юникса почитай своя собственная. Вроде бы аллок-маллок может работать в юзерспейсе, обращаясь к ядру только за виртуальной памятью, т.е. менеджер кучи - это скорее атрибут прикладной программы, чем операционной системы. Так ли это?

anonymous

Это скорее атрибут библиотеки (glibc в Linux), так как обычно в программе используют библиотечную реализацию аллокатора, а не пишут свой собственный. А библиотека работает в user-space и "знает" какими syscall'ами просить у ядра виртуальную память.

P.S. Статью не читал.

mky ★★★★★
()

Да. Линуксовый dlmalloc занимает где-то 7-10k, можно его статически слинковать или использовать свой - если хочется прогнозированным образом работать с памятью (в некоторых случаях это может дать прирост скорости в разы).

anonymous
()
Ответ на: комментарий от anonymous

Спасибо ответившим.. Я вот чего спрашивал-то. Сомнение закралось. ZЯ вот смотрю под HP-UX программа аллоцирующая/деаллоцирующая память никогда не уменьшается в размере. Можно попросить несколько гигов из хипа, VMSIZE проги увеличится, а если потом вернуть - то VMSIZE так никогда и не уменьшится. С другой стороны не верится что бы страницы виртуальной памяти под всем этим пространством не освобождались.. Не может тут быть какого-нить более тесного взаимодействия между менеджером кучи и менеджером виртуальной памяти?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.