heap VS memoria anon nel risultato di pmap

Question

Quanto segue è il risultato dopo l'esecuzione su solaris, mostra che ci sono due heap, ma a mio avviso, per un processo, c'è solo un heap che è una grande memoria continua che può essere gestito da brk per espandere o ridurre le dimensioni. E per la memoria anon, un processo può avere molte memorie anon che possono essere gestite da mmap/munmap. La mia comprensione è corretta? o leggo male il risultato della pmap?

sol9 # pmap -sX pgrep testprog

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

00400000 131072 131072 131072 - 4M rwx-- [mucchio]

... FF390000 8 8 - - 8K libc_psr.so.1 rx--

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

...

---

totale Kb 135968 135944 135.112 -

Answer 1

Siete entrambi corretta e fraintendendo l'uscita pmap. Se avessi fatto pmap -x i risultati sarebbero probabilmente meno confusi, mostrando l'heap solo una volta, ma da quando hai aggiunto il flag -s, esso scompone l'heap in segmenti con mappature di pagina differenti.

Gli indirizzi che iniziano a 0x0022000 non sono allineati correttamente per essere mappati su una pagina 4Mb, quindi usano 3960kb di pagine 8k. 0x0022000 + (3960 * 1024) = 0x00400000

A 0x00400000 l'indirizzo è allineato correttamente per le pagine 4Mb, quindi l'heap passa a utilizzare le pagine più grandi con meno voci della tabella di pagina.

Se si desidera assicurarsi che l'heap sia stato avviato con l'allineamento corretto per utilizzare 4Mb pagine per l'intera operazione anziché iniziare con 8k finché non ha raggiunto un limite di allineamento, è necessario collegare il programma con -M /usr/lib/ld/map.bssalign per farlo.

Una spiegazione leggermente più approfondita può essere trovata nello Page Size and Memory Layout blog post da Solaris Application Programming autore Darryl Gove.