куча VS анон памяти в результате pmap

Ниже приведен результат после запуска на Solaris, он показывает, что есть две кучи, но, насколько я понимаю, для процесса есть только одна куча, которая представляет собой большую непрерывную память, которой можно управлять с помощью brk для увеличения или уменьшения размера. А что касается дополнительной памяти, у процесса может быть много дополнительной памяти, которой можно управлять с помощью mmap/munmap. Правильно ли я понимаю? или я неправильно прочитал результат pmap?

sol9# pmap -sx pgrep testprog

... 00022000 3960 3960 3960 - 8K rwx-- [ куча ]

00400000 131072 131072 131072 - 4M rwx-- [ куча ]

... FF390000 8 8 - - 8K r-x-- libc_psr.so.1

FF3B0000 8 8 8 - 8K rwx-- [ анонимно ]

...

всего Кб 135968 135944 135112 -


heap solaris
person Daniel    schedule 28.01.2010    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Вы оба правы и неправильно читаете вывод pmap. Если бы вы сделали pmap -x, результаты, вероятно, были бы менее запутанными, отображая кучу только один раз, но поскольку вы добавили флаг -s, он разбивает кучу на сегменты с разными сопоставлениями страниц.

Адреса, начинающиеся с 0x0022000, не выровнены должным образом для сопоставления со страницей размером 4 МБ, поэтому они используют 3960 КБ страниц по 8 КБ. 0x0022000+(3960*1024) = 0x00400000

По адресу 0x00400000 адрес правильно выровнен для 4-мегабайтных страниц, поэтому куча переключается на использование больших страниц с меньшим количеством записей в таблице страниц.

Если вы хотите убедиться, что ваша куча начинается с правильного выравнивания, чтобы использовать страницы размером 4 МБ для всего этого, а не начинать с 8 КБ, пока не достигнет границы выравнивания, вы должны связать свою программу с -M /usr/lib/ld/map.bssalign для этого.

Немного более подробное объяснение можно найти в записи блога Размер страницы и расположение памяти из Программирование приложений для Solaris автор Дэррил Гоув.

person alanc    schedule 14.08.2011