原文標(biāo)題:Anatomy of a Program in Memory
原文地址:http://duartes.org/gustavo/blog/
[注:本人水平有限,只好挑一些國外高手的精彩文章翻譯一下。一來自己復(fù)習(xí),二來與大家分享。]
內(nèi)存管理模塊是操作系統(tǒng)的心臟;它對(duì)應(yīng)用程序和系統(tǒng)管理非常重要。今后的幾篇文章中,我將著眼于實(shí)際的內(nèi)存問題,但也不避諱其中的技術(shù)內(nèi)幕。由于不少概念是通用的,所以文中大部分例子取自32位x86平臺(tái)的Linux和Windows系統(tǒng)。本系列第一篇文章講述應(yīng)用程序的內(nèi)存布局。
在多任務(wù)操作系統(tǒng)中的每一個(gè)進(jìn)程都運(yùn)行在一個(gè)屬于它自己的內(nèi)存沙盤中。這個(gè)沙盤就是虛擬地址空間(virtual address space),在32位模式下它總是一個(gè)4GB的內(nèi)存地址塊。這些虛擬地址通過頁表(page table)映射到物理內(nèi)存,頁表由操作系統(tǒng)維護(hù)并被處理器引用。每一個(gè)進(jìn)程擁有一套屬于它自己的頁表,但是還有一個(gè)隱情。只要虛擬地址被使能,那么它就會(huì)作用于這臺(tái)機(jī)器上運(yùn)行的所有軟件,包括內(nèi)核本身。因此一部分虛擬地址必須保留給內(nèi)核使用:

這并不意味著內(nèi)核使用了那么多的物理內(nèi)存,僅表示它可支配這么大的地址空間,可根據(jù)內(nèi)核需要,將其映射到物理內(nèi)存。內(nèi)核空間在頁表中擁有較高的特權(quán)級(jí)(ring 2或以下),因此只要用戶態(tài)的程序試圖訪問這些頁,就會(huì)導(dǎo)致一個(gè)頁錯(cuò)誤(page fault)。在Linux中,內(nèi)核空間是持續(xù)存在的,并且在所有進(jìn)程中都映射到同樣的物理內(nèi)存。內(nèi)核代碼和數(shù)據(jù)總是可尋址的,隨時(shí)準(zhǔn)備處理中斷和系統(tǒng)調(diào)用。與此相反,用戶模式地址空間的映射隨進(jìn)程切換的發(fā)生而不斷變化:
藍(lán)色區(qū)域表示映射到物理內(nèi)存的虛擬地址,而白色區(qū)域表示未映射的部分。在上面的例子中,Firefox使用了相當(dāng)多的虛擬地址空間,因?yàn)樗莻髡f中的吃內(nèi)存大戶。地址空間中的各個(gè)條帶對(duì)應(yīng)于不同的內(nèi)存段(memory segment),如:堆、棧之類的。記住,這些段只是簡單的內(nèi)存地址范圍,與Intel處理器的段沒有關(guān)系。不管怎樣,下面是一個(gè)Linux進(jìn)程的標(biāo)準(zhǔn)的內(nèi)存段布局:

當(dāng)計(jì)算機(jī)開心、安全、可愛、正常的運(yùn)轉(zhuǎn)時(shí),幾乎每一個(gè)進(jìn)程的各個(gè)段的起始虛擬地址都與上圖完全一致,這也給遠(yuǎn)程發(fā)掘程序安全漏洞打開了方便之門。一個(gè)發(fā)掘過程往往需要引用絕對(duì)內(nèi)存地址:棧地址,庫函數(shù)地址等。遠(yuǎn)程攻擊者必須依賴地址空間布局的一致性,摸索著選擇這些地址。如果讓他們猜個(gè)正著,有人就會(huì)被整了。因此,地址空間的隨機(jī)排布方式逐漸流行起來。Linux通過對(duì)棧、內(nèi)存映射段、堆的起始地址加上隨機(jī)的偏移量來打亂布局。不幸的是,32位地址空間相當(dāng)緊湊,給隨機(jī)化所留下的空當(dāng)不大,削弱了這種技巧的效果。
進(jìn)程地址空間中最頂部的段是棧,大多數(shù)編程語言將之用于存儲(chǔ)局部變量和函數(shù)參數(shù)。調(diào)用一個(gè)方法或函數(shù)會(huì)將一個(gè)新的棧楨(stack frame)壓入棧中。棧楨在函數(shù)返回時(shí)被清理。也許是因?yàn)閿?shù)據(jù)嚴(yán)格的遵從LIFO的順序,這個(gè)簡單的設(shè)計(jì)意味著不必使用復(fù)雜的數(shù)據(jù)結(jié)構(gòu)來追蹤棧的內(nèi)容,只需要一個(gè)簡單的指針指向棧的頂端即可。因此壓棧(pushing)和退棧(popping)過程非常迅速、準(zhǔn)確。另外,持續(xù)的重用棧空間有助于使活躍的棧內(nèi)存保持在CPU緩存中,從而加速訪問。進(jìn)程中的每一個(gè)線程都有屬于自己的棧。
通過不斷向棧中壓入的數(shù)據(jù),超出其容量就有會(huì)耗盡棧所對(duì)應(yīng)的內(nèi)存區(qū)域。這將觸發(fā)一個(gè)頁故障(page fault),并被Linux的expand_stack()處理,它會(huì)調(diào)用acct_stack_growth()來檢查是否還有合適的地方用于棧的增長。如果棧的大小低于RLIMIT_STACK(通常是8MB),那么一般情況下棧會(huì)被加長,程序繼續(xù)愉快的運(yùn)行,感覺不到發(fā)生了什么事情。這是一種將棧擴(kuò)展至所需大小的常規(guī)機(jī)制。然而,如果達(dá)到了最大的棧空間大小,就會(huì)棧溢出(stack overflow),程序收到一個(gè)段錯(cuò)誤(Segmentation Fault)。當(dāng)映射了的棧區(qū)域擴(kuò)展到所需的大小后,它就不會(huì)再收縮回去,即使棧不那么滿了。這就好比聯(lián)邦預(yù)算,它總是在增長的。
動(dòng)態(tài)棧增長是唯一一種訪問未映射內(nèi)存區(qū)域(圖中白色區(qū)域)而被允許的情形。其它任何對(duì)未映射內(nèi)存區(qū)域的訪問都會(huì)觸發(fā)頁故障,從而導(dǎo)致段錯(cuò)誤。一些被映射的區(qū)域是只讀的,因此企圖寫這些區(qū)域也會(huì)導(dǎo)致段錯(cuò)誤。
在棧的下方,是我們的內(nèi)存映射段。此處,內(nèi)核將文件的內(nèi)容直接映射到內(nèi)存。任何應(yīng)用程序都可以通過Linux的mmap()系統(tǒng)調(diào)用(實(shí)現(xiàn))或Windows的CreateFileMapping() / MapViewOfFile()請(qǐng)求這種映射。內(nèi)存映射是一種方便高效的文件I/O方式,所以它被用于加載動(dòng)態(tài)庫。創(chuàng)建一個(gè)不對(duì)應(yīng)于任何文件的匿名內(nèi)存映射也是可能的,此方法用于存放程序的數(shù)據(jù)。在Linux中,如果你通過malloc()請(qǐng)求一大塊內(nèi)存,C運(yùn)行庫將會(huì)創(chuàng)建這樣一個(gè)匿名映射而不是使用堆內(nèi)存。‘大塊’意味著比MMAP_THRESHOLD還大,缺省是128KB,可以通過mallopt()調(diào)整。
說到堆,它是接下來的一塊地址空間。與棧一樣,堆用于運(yùn)行時(shí)內(nèi)存分配;但不同點(diǎn)是,堆用于存儲(chǔ)那些生存期與函數(shù)調(diào)用無關(guān)的數(shù)據(jù)。大部分語言都提供了堆管理功能。因此,滿足內(nèi)存請(qǐng)求就成了語言運(yùn)行時(shí)庫及內(nèi)核共同的任務(wù)。在C語言中,堆分配的接口是malloc()系列函數(shù),而在具有垃圾收集功能的語言(如C#)中,此接口是new關(guān)鍵字。
如果堆中有足夠的空間來滿足內(nèi)存請(qǐng)求,它就可以被語言運(yùn)行時(shí)庫處理而不需要內(nèi)核參與。否則,堆會(huì)被擴(kuò)大,通過brk()系統(tǒng)調(diào)用(實(shí)現(xiàn))來分配請(qǐng)求所需的內(nèi)存塊。堆管理是很復(fù)雜的,需要精細(xì)的算法,應(yīng)付我們程序中雜亂的分配模式,優(yōu)化速度和內(nèi)存使用效率。處理一個(gè)堆請(qǐng)求所需的時(shí)間會(huì)大幅度的變動(dòng)。實(shí)時(shí)系統(tǒng)通過特殊目的分配器來解決這個(gè)問題。堆也可能會(huì)變得零零碎碎,如下圖所示:

最后,我們來看看最底部的內(nèi)存段:BSS,數(shù)據(jù)段,代碼段。在C語言中,BSS和數(shù)據(jù)段保存的都是靜態(tài)(全局)變量的內(nèi)容。區(qū)別在于BSS保存的是未被初始化的靜態(tài)變量內(nèi)容,它們的值不是直接在程序的源代碼中設(shè)定的。BSS內(nèi)存區(qū)域是匿名的:它不映射到任何文件。如果你寫static int cntActiveUsers,則cntActiveUsers的內(nèi)容就會(huì)保存在BSS中。
另一方面,數(shù)據(jù)段保存在源代碼中已經(jīng)初始化了的靜態(tài)變量內(nèi)容。這個(gè)內(nèi)存區(qū)域不是匿名的。它映射了一部分的程序二進(jìn)制鏡像,也就是源代碼中指定了初始值的靜態(tài)變量。所以,如果你寫static int cntWorkerBees = 10,則cntWorkerBees的內(nèi)容就保存在數(shù)據(jù)段中了,而且初始值為10。盡管數(shù)據(jù)段映射了一個(gè)文件,但它是一個(gè)私有內(nèi)存映射,這意味著更改此處的內(nèi)存不會(huì)影響到被映射的文件。也必須如此,否則給全局變量賦值將會(huì)改動(dòng)你硬盤上的二進(jìn)制鏡像,這是不可想象的。
下圖中數(shù)據(jù)段的例子更加復(fù)雜,因?yàn)樗昧艘粋€(gè)指針。在此情況下,指針gonzo(4字節(jié)內(nèi)存地址)本身的值保存在數(shù)據(jù)段中。而它所指向的實(shí)際字符串則不在這里。這個(gè)字符串保存在代碼段中,代碼段是只讀的,保存了你全部的代碼外加零零碎碎的東西,比如字符串字面值。代碼段將你的二進(jìn)制文件也映射到了內(nèi)存中,但對(duì)此區(qū)域的寫操作都會(huì)使你的程序收到段錯(cuò)誤。這有助于防范指針錯(cuò)誤,雖然不像在C語言編程時(shí)就注意防范來得那么有效。下圖展示了這些段以及我們例子中的變量:

你可以通過閱讀文件/proc/pid_of_process/maps來檢驗(yàn)一個(gè)Linux進(jìn)程中的內(nèi)存區(qū)域。記住一個(gè)段可能包含許多區(qū)域。比如,每個(gè)內(nèi)存映射文件在mmap段中都有屬于自己的區(qū)域,動(dòng)態(tài)庫擁有類似BSS和數(shù)據(jù)段的額外區(qū)域。下一篇文章講說明這些“區(qū)域”(area)的真正含義。有時(shí)人們提到“數(shù)據(jù)段”,指的就是全部的數(shù)據(jù)段 + BSS + 堆。
你可以通過nm和objdump命令來察看二進(jìn)制鏡像,打印其中的符號(hào),它們的地址,段等信息。最后需要指出的是,前文描述的虛擬地址布局在Linux中是一種“靈活布局”(flexible layout),而且以此作為默認(rèn)方式已經(jīng)有些年頭了。它假設(shè)我們有值RLIMIT_STACK。當(dāng)情況不是這樣時(shí),Linux退回使用“經(jīng)典布局”(classic layout),如下圖所示:

對(duì)虛擬地址空間的布局就講這些吧。下一篇文章將討論內(nèi)核是如何跟蹤這些內(nèi)存區(qū)域的。我們會(huì)分析內(nèi)存映射,看看文件的讀寫操作是如何與之關(guān)聯(lián)的,以及內(nèi)存使用概況的含義