PHP的內存管理, 分為倆大部分, 第一部分是PHP自身的內存管理, 這部分主要的內容就是引用計數, 寫時復制, 等等面向應用的層面的管理. 而第二部分就是今天我要介紹的, zend_alloc中描寫的關於PHP自身的內存管理, 包括它是如何管理可用內存, 如何分配內存等.
另外, 為什麼要寫這個呢, 因為之前並沒有任何資料來介紹PHP內存管理中使用的策略, 數據結構, 或者算法. 而在我們平時開發擴展, 修復PHP的bug的時候, 卻對這一部分的知識需要有一個良好的理解. PHP開發組內的很多朋友也對這塊不是很清楚, 所以我覺得有必要專門寫一下.
一些基本的概念, 我就不贅述了, 因為看代碼很容易能看懂, 我這裡就主要介紹幾個看代碼沒那麼容易看懂的點, 為什麼這麼說呢, 呵呵, 我在寫文章之前, 查找了下已有的資料, 已避免重復功, 其中看到了TIPI項目對這部分的描述, 發現其中錯誤很多. 所以, 我想這部分就是看代碼也沒那麼容易看懂的點
目前, 英文版的介紹也在撰寫中: Zend MM
Zend Memory Manager, 以下簡稱Zend MM, 是PHP中內存管理的邏輯. 其中有一個關鍵數據結構: zend_mm_heap:
Zend MM把內存非為小塊內存和大塊內存倆種, 區別對待, 對於小塊內存, 這部分是最最常用的, 所以追求高性能. 而對於大塊內存, 則追求的是穩妥, 盡量避免內存浪費.
所以, 對於小塊內存, PHP還引入了cache機制:
Zend MM 希望通過cache盡量做到, 一次定位就能查找分配.
而一個不容易看懂的點是free_buckets的申明:
Q: 為什麼free_buckets數組的長度是ZEND_MM_NUMBER_BUCKET個?
A: 這是因為, PHP在這處使用了一個技巧, 用一個定長的數組來存儲ZEND_MM_NUMBER_BUCKET個zend_mm_free_block, 如上圖中紅色框所示. 對於一個沒有被使用的free_buckets的元素, 唯一有用的數據結構就是next_free_block和prev_free_block, 所以, 為了節省內存, PHP並沒有分配ZEND_MM_NUMBER_BUCKET * sizeof(zend_mm_free_block)大小的內存, 而只是用了ZEND_MM_NUMBER_BUCKET * (sizeof(*next_free_block) + sizeof(*prev_free_block))大小的內存..
我們來看ZEND_MM_SMALL_FREE_BUCKET宏的定義:
- #define ZEND_MM_SMALL_FREE_BUCKET(heap, index)
- (zend_mm_free_block*) ((char*)&heap->free_buckets[index * 2] +
- sizeof(zend_mm_free_block*) * 2 -
- sizeof(zend_mm_small_free_block))
之後, Zend MM 保證只會使用prev和next倆個指針, 所以不會造成內存讀錯..
那麼, 第二個不容易看懂的點, 就是PHP對large_free_buckets的管理, 先介紹分配(TIPI項目組對此部分的描述有些含糊不清):
- static zend_mm_free_block *zend_mm_search_large_block(zend_mm_heap *heap, size_t true_size)
large_free_buckets可以說是一個建樹和雙向列表的結合:
large_free_buckets使用一個宏來決定某個大小的內存, 落在什麼index上:
- #define ZEND_MM_LARGE_BUCKET_INDEX(S) zend_mm_high_bit(S)
zend_mm_high_bit獲取true_size中最高位1的序號(zend_mm_high_bit), 對應的匯編指令是bsr(此處, TIPI項目錯誤的說明為: “這個hash函數用來計算size的位數，返回值為size二進碼中1的個數-1″).
也就是說, 每一個在large_free_buckets中的元素, 都保持著指向一個大小為在對應index處為1的size的內存塊的指針. 诶, 有點繞口, 舉個例子:
比如對於large_free_buckets[2], 就只會保存, 大小在0b1000到0b1111大小的內存. 再比如: large_free_buckets[6], 就保存著大小為0b10000000到0b11111111大小的內存的指針.
這樣, 再分配內存的時候, Zend MM就可以快速定位到最可能適合的區域來查找. 提高性能.
而, 每一個元素又同時是一個雙向列表, 保持著同樣size的內存塊, 而左右孩子(child[0]和child[1])分別代表著鍵值0和1, 這個鍵值是指什麼呢?
我們來舉個例子, 比如我向PHP申請一個true_size為0b11010大小的內存, 經過一番步驟以後, 沒有找到合適的內存, PHP進入了zend_mm_search_large_block的邏輯來在large_free_buckets中尋找合適的內存:
1. 首先, 計算true_size對應的index, 計算方法如之前描述的ZEND_MM_LARGE_BUCKET_INDEX
2. 然後在一個位圖結構中, 判斷是否存在一個大於true_size的可用內存已經存在於large_free_buckets, 如果不存在就返回:
- size_t bitmap = heap->large_free_bitmap >> index;
- if (bitmap == 0) {
- return NULL;
- }
3. 判斷, free_buckets[index]是否存在可用的內存:
- if (UNEXPECTED((bitmap & 1) != 0))
4. 如果存在, 則從free_buckets[index]開始, 尋找最合適的內存, 步驟如下:
4.1. 從free_buckets[index]開始, 如果free_buckets[index]當前的內存大小和true_size相等, 則尋找結束, 成功返回.
4.2. 查看true_size對應index後(true_size << (ZEND_MM_NUM_BUCKETS - index))的當前最高位, 如果為1. 則在free_buckets[index]->child[1]下面繼續尋找, 如果free_buckets[index]->child[1]不存在, 則跳出. 如果true_size的當前最高位為0, 則在free_buckets[index]->child[0]下面繼續尋找, 如果free_buckets[index]->child[0]不存在, 則在free_buckets[index]->child[1]下面尋找最小內存(因為此時可以保證, 在free_buckets[index]->child[1]下面的內存都是大於true_size的)
4.3. 出發點變更為2中所述的child, 左移一位ture_size.
5. 如果上述邏輯並沒有找到合適的內存, 則尋找最小的”大塊內存”:
- /* Search for smallest "large" free block */
- best_fit = p = heap->large_free_buckets[index + zend_mm_low_bit(bitmap)];
- while ((p = p->child[p->child[0] != NULL])) {
- if (ZEND_MM_FREE_BLOCK_SIZE(p) < ZEND_MM_FREE_BLOCK_SIZE(best_fit)) {
- best_fit = p;
- }
- }
注意上面的邏輯, (p = p->child[p->child[0] != NULL]), PHP在盡量尋找最小的內存.
為什麼說, large_free_buckets是個鍵樹呢, 從上面的邏輯我們可以看出, PHP把一個size, 按照二進制的0,1做鍵, 把內存大小信息反應到了鍵樹上, 方便了快速查找.
另外, 還有一個rest_buckets, 這個結構是個雙向列表, 用來保存一些PHP分配後剩下的內存, 避免無意義的把剩余內存插入free_buckets帶來的性能問題(此處, TIPI項目錯誤的描述為: “這是一個只有兩個元素的數組。 而我們常用的插入和查找操作是針對第一個元素，即heap->rest_buckets[0]“).
作者: Laruence( ) 原文地址:
