开发者

heap VS anon memory in the result of pmap

开发者 https://www.devze.com 2022-12-18 12:02 出处:网络
The following is the result after run on solaris, it shows there are two heaps, but in my understanding, for a process, there is only one heap which is a large continuous memory which can be managed b

The following is the result after run on solaris, it shows there are two heaps, but in my understanding, for a process, there is only one heap which is a large continuous memory which can be managed by brk to expand or shrink the size. And for anon memory, a process can have many anon memory which can be managed by mmap/munmap. Is my understanding correct? or I read the result of the pmap wrongly?

sol9# pmap -sx pgrep testprog

... 00022000 3960 3960 3960 - 8K rwx-- [ heap ]

00400000 131072 131072 13开发者_JAVA技巧1072 - 4M rwx-- [ heap ]

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

FF3B0000 8 8 8 - 8K rwx-- [ anon ]

...


total Kb 135968 135944 135112 -


You are both correct and misreading the pmap output. If you had done pmap -x the results would probably be less confusing, showing the heap just once, but since you added the -s flag, it breaks down the heap into segments with different page mappings.

The addresses starting at 0x0022000 are not aligned properly to be mapped to a 4Mb page, so they use 3960kb of 8k pages. 0x0022000+(3960*1024) = 0x00400000

At 0x00400000 the address is properly aligned for 4Mb pages, so the heap switches to using the larger pages with fewer page table entries.

If you wanted to ensure that your heap started at the proper alignment to use 4Mb pages for the whole thing instead of starting with 8k until it reached an alignment boundary, then you would link your program with -M /usr/lib/ld/map.bssalign to do that.

A slightly more in-depth explanation can be found in the Page Size and Memory Layout blog post from Solaris Application Programming author Darryl Gove.

0

精彩评论

暂无评论...
验证码 换一张
取 消