一種面向ＴＴＣＮ－３測試系統的共享內存管理框架

摘要：為了提高TTCN－3測試組件間通信的性能，在基于TTCN－3的基礎測試平臺上設計并實現了一套支持動態切換內存管理策略的共享內存管理框架，并在該框架下實現了三套不同的共享內存分配和自動回收策略。框架能夠根據系統運行時刻的共享內存統計特征在這些策略中選擇性能預期最好的一套，并動態地將當前內存管理策略切換為該套方案。在基礎測試平臺上運行一系列并發測試用例表明，該框架能提升內存管理以及整個系統的平均性能。

關鍵詞：測試和測試控制標記(第三版);測試系統;共享內存管理;算法動態切換

中圖分類號：TP301文獻標志碼：A

文章編號：1001－3695(2007)07－0157－05

0引言

TTCN－3(Testing and Test Control Notation Version 3)[1]是一種標準化測試語言，主要用于各種反應式系統的一致性測試。TTCN－3支持動態定義測試配置。測試配置由一組測試組件和一個系統組件構成。測試組件是一個執行實體，負責具體的測試行為。測試組件間通過端口進行通信，包括數據通信和相互間的同步等來完成一個具體的測試目的。

目前已有的基于TTCN－3的測試系統均采用多線程技術實現，這種實現方式比較簡單，能滿足大部分黑盒測試的需要。但操作系統對線程技術存在堆棧空間大小等約束，并且當線程數量達到一定規模時，會導致系統的執行效率急劇下降。這些限制導致了采用多線程技術實現的TTCN－3運行環境無法應用于大規模的壓力測試。

基于TTCN－3，本文實現了一個支持并發環境下的黑盒測試的基礎測試平臺（簡稱基礎測試平臺）。該平臺采用多進程技術實現，將每個測試組件映射為一個進程，避免了線程技術的局限，然而也無法利用線程間快捷的通信機制。為了實現測試組件間通信，基礎測試平臺使用了多種進程間通信技術，包括事件、消息和共享內存等。測試組件間要進行大量的數據通信，所以共享內存這種方式使用得最為普遍，它的性能對測試系統的運行效率影響也最大。

共享內存的性能包括應用在共享內存上的內存分配策略、內存回收策略和同步策略等的執行效率。國際上對于內存回收算法效率與可用內存空間大小的關系研究比較多[2~4]。這些研究的目的是尋找普適的高性能內存回收算法。然而文獻[5]指出，系統運行時刻的內存統計特征（數據塊大小分布、拓撲結構、生命期分布、局部性和可用空間大小等）對內存管理算法的性能影響很大。在基礎測試平臺上運行的測試應用多種多樣，不能保證運行時刻系統內存特征的相似性，單一的內存分配或回收策略難以在該系統上保持始終的高性能。

也有少量文獻提出了動態調整的策略。文獻[6]根據運行時可用堆空間大小動態切換內存垃圾回收算法；文獻[7]則針對成熟的垃圾回收算法動態調整堆空間大小以減少換頁開銷。這些調整策略依據的數據只有內存空間大小，并且只關注內存回收部分，沒有考慮對內存分配策略的調整。實際上，不同的內存分配策略本身的性能相差很大，而且能夠影響到內存布局，從而對內存回收的性能也產生影響。如果能夠在分配時刻考慮到換頁開銷而將內存布局作有意識的部置，將會大大改善程序的數據局部性[5]。

綜合考慮運行時刻系統的多個內存統計特征（數據塊大小分布、數據塊生命期分布和可用空間大小）及進程間同步要求，提出并在基礎測試平臺上實現了一套支持動態切換策略的共享內存管理框架，在此框架下實現了三套基于成熟的內存垃圾自動回收算法的共享內存分配和自動回收策略：基于標記—清掃垃圾回收算法的策略（簡稱標記—清掃策略）、基于節點復制垃圾回收算法的策略（簡稱節點復制策略）和基于分代式垃圾回收算法（分代內采用標記—清掃算法）的策略（簡稱分代策略）。

框架能夠根據內存特征，在這些策略中選擇性能預期最好的一套，并動態地將當前內存管理策略切換為該套方案。在基礎測試平臺上運行一系列并發測試用例表明，與使用單一策略相比，該框架能顯著提升共享內存管理子系統和整個基礎測試平臺的平均性能。

1共享內存管理框架的設計和實現

本文設計的支持切換的共享內存管理框架的總體結構如圖1所示。

ShmManager對外提供內存操作接口；ShmManager使用統計工具來記錄單次事件，包括內存的分配、回收和策略的切換等；具體的內存操作由SharedMemory類實現。SharedMemory實際上是一個接口類，與各種內存管理策略的具體實現構成Strategy設計模式[8]，支持策略的切換，這部分的具體實現在下文介紹。切換工具依據切換時機定義、切換規則和統計工具的統計結果操控StrategyManager類，進行實際的切換過程。

1．1統計工具

影響共享內存管理器性能的因素不僅包括運行時刻系統的內存統計特征，還包含處理器、高速緩存和虛存等的性能。在相同的硬件環境上，分析一個共享內存管理系統的過去、當前和未來的行為中的關鍵影響因素。

(1)過去的行為包括分配內存和回收內存，重要的統計特征包括已分配數據單元大小分布、已分配數據單元內存空間連通性和已使用的管理器的性能等；

(2)當前的主要特征有可用內存空間大小和已分配空間大小等；

(3)未來的行為也包括分配和回收內存，主要特征有現有數據塊的生命期（多久后會被回收）的分布等。

通過從以上三個角度來考察一個運行時刻系統，能夠較全面地掌握影響共享內存管理性能的主要因素。理想的共享內存管理器應該統計幾乎所有的影響其性能的數據，但這往往以過高的開銷為代價。選取其中相對重要但性能開銷較小的四個因素作為統計指標：

{已分配數據單元大小分布，可用空間比例，單元生命期預測，已使用的管理器性能}

為了統計這四項指標，在共享內存管理系統中實現了一套動態統計工具。為了降低開銷，統計工具不作為獨立線程或者進程運行，而是實現為提供API的靜態庫（基礎測試平臺在Linux環境下運行，用C++實現，因而在理論上，使用ELF格式的靜態庫函數生成的代碼可以比使用共享函數庫或動態函數庫的程序運行速度上快一些）。圖2給出了記錄數據和取得統計結果的接口及它們與系統其他部分的數據流關系。

ShmManager是共享內存管理子系統，負責對共享內存的實際管理，向上提供共享內存操作接口（分配和回收內存）。切換工具負責策略的切換。在每次共享內存事件（分配內存、回收內存和切換管理策略）發生前，ShmManager將調用ShmLog相應的接口函數（如LogAllocateShm）來記錄一次事件的開始；在該次事件完成之后，ShmManager將調用ShmLog相應的表征操作完成的接口函數（如LogAllocateShmOk），表示操作的完成。參數opIdx用來區分不同的事件，因為它們在并發的環境里可能交錯出現，即一個事件還沒有完成，另一個事件就開始了。ShmLog的SetSize接口是共享內存初始化或改變總大小時調用，以后被用來計算空閑空間比例。

ShmLog將事件序列化，并加上Timer子系統提供的時間戳，形成完整的日志信息，傳遞給Log子系統。Log子系統負責真正的事件記錄，目前使用文件實現。Log子系統實際上還為系統的其他部分提供日志記錄和讀取操作，只不過使用了不同的日志文件。

切換工具在特定時機需要內存統計特征來作決策時，就調用ShmStat的若干接口函數。FreeRatio函數將返回目前共享內存中空閑空間的比例。Distribution是一個表征數據分布的數據結構，接收一組浮點數，包含該組數據的平均值和方差。BlockSize函數返回的是以前分配的數據塊的大小分布；LifeCycle返回的是以前分配的數據塊的生命周期分布；AllocTimePerMega函數和DeallocTimePerMega函數分別返回上次策略切換之后分配和回收1M內存所需時間的分布，它們表征的是當前內存管理器的性能。ShmStat的原始數據從Log子系統獲得。

1．2切換時機和切換規則

有了統計數據，切換共享內存管理策略就有了依據。

（1）已使用的管理器性能

切換本身具備一定開銷，如果在某種情形下，某套特定的共享內存管理策略的性能一直表現良好，那么切換就沒有必要發生。只有當內存管理器的分配內存和回收內存速度下降到某個閾值時，才會調用切換過程。

（2）已分配數據單元大小分布

已分配數據的單元大小方差如果小于某個閾值，說明在該應用中數據單元的大小比較接近，從而切換時可以考慮其均值；如果均值在某個閾值之上，說明主要是大數據塊，那么數據復制式的內存管理器性能就會較差。

（3）可用空間比例

如果可用空間比較大，可以考慮將空間分為兩個半區，進行節點復制等；同時也可以考慮延遲回收內存垃圾，以降低消耗。如果可用空間較小，那么應該及時地回收垃圾，且沒法使用半區等策略。

（4）單元生命期預測

數據單元的生命期方差表征數據塊生存期長度的一致性，而均值反映數據塊生命周期長短。如果生命期一致較長，可以考慮減少內存垃圾回收的頻率，加速分配過程；如果生命期一致較短，則可以考慮分代回收，使得大量內存可以迅速回收。

實現的共享內存管理框架在切換時機和切換方案的選擇上綜合考慮了上述各項因素，根據經驗數據指定了這些指標的一系列閾值，保存為一個配置文件shm.conf。系統在啟動時將該文件加載到內存，保存在一個靜態的conf對象中。

首先是切換的觸發。ShmManager采取輪詢方式來調用ShmStat的接口函數，并判斷其是否滿足配置文件指定的范圍。首次查詢的時間和輪詢的時間間隔在shm.conf中定義。之所以設置首次查詢時間，是為了防止程序剛剛啟動時數據太少，統計結果不可靠。判斷的邏輯目前以靜態的C++編碼實現，在以下三種情形下會調用切換過程：

(1）ShmStat.AllocTimePerMega().average > conf.MAX_ALLOC_TIME 

|| ShmStat.DeallocTimePerMega().average > conf.MAX_DEALLOC_TIME 

即平均的分配時間或者回收時間過長，則應該切換。

(2）ShmStat.AllocTimePerMega().average + ShmStat.DeallocTimePerMega().average>2*conf.MAX_AVR_TIME 

綜合考慮分配和回收的平均性能，如果總性能過低，應該切換。

(3）(ShmStat.AllocTimePerMega().sqrError > conf.MAX_ALLOC_SQR_ERR 

|| ShmStat.DeallocTimePerMega().sqrError > conf.MAX_DEALLOC_SQR_ERR) 

(ShmStat.AllocTimePerMega().average + ShmStat.DeallocTimePerMega().average>2 * conf.IMPROPER_AVR_TIME) 

如果內存管理器性能很不穩定，且分配和回收的平均耗時超過一個閾值IMPROPER_AVR_TIME，則可以切換。這里IMPROPER_AVR_TIME是低于MAX_AVR_TIME的一個值。

其次是方案的選擇。目前三套方案的選擇過程以C++編碼實現，邏輯比較簡單。

（1）ShmStat.LifeCycle().sqrError < conf.GEN_LIFE_CYCLE_SQR_ERR 

ShmStat.LifeCycle().average < conf.GEN_LIFE_CYCLE

則切換到分代式策略；否則轉到（2）。

(2）ShmStat.BlockSize().average < conf.COPY_BLKSZ 

ShmStat.BlockSize().sqrError < conf.COPY_BLKSZ_SQR_ERR 

ShmStat.FreeRatio() > conf.MIN_COPY_FREE_RATIO 

則切換到節點復制策略；否則切換到標記—清掃策略。

切換時如果當前策略就是待切換策略，則不調用切換過程。其中的閾值也同樣保存在shm.conf文件中。

1．3元數據結構

SharedMemory類同StrategyManager類構成Strategy設計模式，支持內存管理策略的切換；SharedMemory類包含支持所有具體策略的元數據結構，使得某些策略的切換只需直接改變StrategyManager中所包含的當前策略對象即可，降低了切換的性能開銷。

圖3給出了上述兩個類的主要數據結構和輔助數據類型。

Map類的兩個數據成員from和to均表示共享內存地址。這里采用了兩個設計原則：

（1）int類型。因為在單進程的虛擬地址空間中，一塊內存的絕對地址（物理地址）的值是唯一的，可以用void*來表示；在多進程的共享內存應用中，共享內存被映射到各個內存的地址空間，可能產生不同的引用地址，因而在實現共享內存地址管理時，采用int類型的偏移量而不是地址值。

（2）Map記錄了數據塊的轉移。這個轉移無論在內存管理策略的切換過程中還是在某些策略的自動垃圾回收過程中均是必要的。from字段表示邏輯地址，即提供給應用層進程的訪問地址，而to表示實際地址，即可能的遷移之后的數據塊的地址。因而from和to可能是一致的，當它們不一致時，用戶的內存訪問會經過一個映射過程。

ShmObject類包含了一個Map類對象addr、一個age數據成員和一個整型的size屬性。age是指數據塊的年齡。該年齡的實現理論上可以采用絕對時鐘，不過更高效的卻是記錄從系統啟動到該對象生成的時刻共享內存分配的內存塊數量。這就是SharedMemory類的allocCount數據成員的作用。不過age值越小，說明對象的年齡越大。size是指數據塊的大小。

在SharedMemory中除了作為偽時鐘使用的allocCount，就是關鍵的objs成員，其類型是ShmObject*，實際上是ShmObject類型的數組。它是共享內存內所有使用中的對象集合，給需要掃描的內存管理策略提供簡便的支持，而實現的三種管理策略均需要掃描，它們共享objs數組。

objs數組的維護包括添加、修改和刪除。當應用層進程調用ShmManager的分配內存接口時，ShmManager調用SharedMemory的Allocate()函數，如果分配成功，則將新分配的地址偏移量添加到objs中去；在GC()函數中，也就是垃圾回收時，以及在切換策略時，如果需要移動對象，那么必須更新objs中對應的ShmObject；應用層進程調用ShmManager的內存回收接口時，內存是否實際回收由GC()函數決定，但一定要從objs中刪除對應該地址的ShmObject對象。

Allocate()函數是分配內存函數，接收兩個參數size和key，返回void*類型。如果分配成功，返回值是實際地址；size參數是指應用層進程請求的內存塊大小，而key則是用來在多進程之間共享對象的標志，目前以整數實現，保存在keys數據成員中。在SharedMemory類中，該函數沒有實現，需要具體的內存管理策略繼承的時候去實現。

keys數據成員將key映射為地址，是Map類型的數組。

GC()函數也需要具體的內存管理策略去實現。當應用層進程請求回收內存和分配內存時，該函數均會被調用，但實際的垃圾回收過程是否需要執行由該函數來判斷。

SharedMemory對象全局唯一，保存在共享內存的起始部分。

StrategyManager對象也保存在共享內存的起始部分，負責實際的策略切換，保存SharedMemory對象的指針（實際實現時是以偏移量保存）作為當前策略（strategy數據成員）。Change－Strategy()函數就是切換函數，接收SharedMemory*類型的參數，即新的策略。

該方案存在兩個缺點：

（1）冗余性，某些元數據在一些具體策略中沒有用；

（2）必須維護這些元數據。

其優點有：

（1）切換過程方便快速，各種策略需要的原始數據均可輕易獲取。

（2）可擴展性得到增強。

（3）容易加鎖。共享內存中的數據需要考慮同步問題，因而需要對共享內存加鎖；考慮到性能，全局的鎖是不合適的。

上述策略將邏輯上的數據塊獨立處理，維護一個objs列表，使得加鎖的粒度可以縮小到對象級，這對于支持多進程間通信的共享內存而言，提高了性能。

1．4可擴展性

基于上述元數據結構，建立新的共享內存管理策略只需以下幾個步驟：

（1）繼承SharedMemory類，實現其中的Allocate()和GC()方法；

（2）Allocate()方法需要維護objs、allocCount和keys數據成員；

（3）GC()方法判斷是否調用實際的垃圾回收過程，并負責維護objs和key數據成員；

（4）修改切換時機和切換規則描述，包括shm.conf和切換工具中的C++代碼；

（5）如果有必要，在統計工具中加入對新的指標的統計支持（這一步往往不需要，因為目前統計的數據對于共享內存管理而言已經比較充分）；

（6）實現StrategyManager的ChangeStrategy中的切換代碼（如果已經存在N種策略，則需要實現2×N種切換過程）。

1．5內存操作API

在系統中，共享內存的實際回收使用自動回收技術，但是提供給外層的接口包含了內存回收操作，這是因為共享內存中的對象被多個進程使用，只有應用邏輯知道什么時候對象沒有任何進程需要使用。因此，對象的引用計數結合加鎖機制獨立于共享內存管理器外，由應用層實現；另一方面，考察共享內存內數據對象的生存期時，應該使用邏輯生存期，也就是說，當應用層進程聲明回收某個對象時，該對象的邏輯生存期就應該結束了，而不必等到GC()函數實際回收該對象的內存。



綜合考慮這些因素，從應用的需要出發。目前的ShmManager對外提供了三層內存操作接口，如圖4所示。

首先是底層的C風格的內存操作接口，包括Allocate和Deallocate，只是可以指定key參數。這一層還包括GetObject函數，實際操作的是SharedMemory的keys數組，支持對共享對象的按key直接讀取。中間一層是C++風格的new和delete操作。需要保存在共享內存中的對象只需要繼承一個公共的SharedMemoryObject類，并且只用new操作來生成實例，則生成的實例均在共享內存中。這里的new操作也接收key參數。SharedMemoryObject重載了C++默認的new和delete操作符，使其不再使用進程空間的堆作為內存來源，而是使用共享內存提供的C風格的接口。

最高一層是對中間層的封裝。出于實際應用的需要，實現了若干STL風格的容器，其內存操作使用中間層提供的接口。這些容器及其數據元素都繼承自SharedMemoryObject，從而均保存在共享內存中。

2內存管理策略

本文實現了三套基于成熟的內存垃圾回收算法的共享內存管理策略：標記—清掃策略、節點復制策略和分代策略。這些算法及其改進在大量文獻中均有介紹，例如文獻[5， 9， 10]，這里主要介紹實現針對三種策略的經典版本[5]作的改進。

標記—清掃策略使用一個位圖bitmap來輔助內存管理，位圖的一個bit表示64bytes的實際內存，若其值為1，表示該塊內存被占用；否則表示該塊內存沒有被占用。回收內存時掃描objs數組，重新標記bitmap；分配內存時，則從bitmap中尋找值為0的位。為了提高數據局部性，該策略還使用一個輔助的數據成員來記錄上一次分配內存返回的地址lastAddr（初始值為0）。在尋找空閑塊時，從lastAddr出發，向前后兩個方向交替查找，這樣使得分配時間接近的數據對象的地址比較接近，有利于提高數據局部性。如果經過了若干步驟后合適大小的空閑內存塊還沒有找到，一個局部縮并過程會被調用，將少量對象移動以制造足夠大的空間。

節點復制策略使用一個特有的指向空閑區域起始地址的指針（以偏移量實現）。回收內存時同樣掃描objs數組，但是在掃描的過程中直接進行移動，將數據塊復制到另一個半區，同時維護地址映射關系，最后修改的只是上述指向空閑空間的指針；分配內存時，只需要移動該指針即可。該策略的數據局部性比較良好，它遵循的是減少內存碎塊的原則。

分代策略目前實現為在分代內采取標記—清掃策略，并且只維持兩個分代newGen和oldGen，其中較老的分代oldGen保存生存周期大于conf.GEN_LIFE_CYCLE_BOUND（在shm.conf文件中定義）的數據單元。newGen和oldGen實際上是兩個輔助數組，包含指向objs數組內數據成員的指針（用objs的索引實現）。在構造分代時，掃描objs，將較老的數據移動到共享內存的高地址端，將較新的數據移動到共享內存的低地址端，并記錄較老分區的起始地址作為兩個分區的物理界限。分代內的回收使用標記—清掃策略，過程同上文介紹的標記—清掃策略類似，區別在于掃描的對象不是objs而是newGen或oldGen。newGen的回收頻率較高，目前是GC()函數直接調用；分配內存時，首先在newGen的位圖中尋找，只有在newGen中找不到了，才調用oldGen的回收過程和縮并過程，并且移動分區界限。每次分配內存時，newGen和oldGen中的數據的age均會被刷新，其中newGen的數據age被刷新后如果超過了conf.GEN_LIFE_CYCLE_BOUND則會被移動到oldGen，分區界限相應移動。在分配內存時，同樣采取了類似于前述標記—清掃策略的局部性考慮。

針對以上三套策略，StrategyManager實現了六種切換邏輯：

（1）標記—清掃策略到節點復制策略。按地址順序掃描bitmap，將空閑塊逐步后移，使得所有的空閑塊聚集在高地址端，所有的占用塊聚集在另一端；設置空閑地址偏移指針。性能為O(M)，M指空閑塊的數量級（內存碎片）。

（2）節點復制策略到標記—清掃策略。將bitmap對應于空閑地址指針的一位的空閑一側全部置0，另一側全部置1。性能為O(1)。

（3）標記—清掃策略到分代策略。按地址順序掃描bit－map，將年輕的數據塊逐步前移，年老的數據塊逐步后移。性能為O(N)，N指分配的內存塊的數量級。

（4）分代策略到標記—清掃策略。掃描objs，重新標記bitmap。性能為O(N)。

（5）節點復制策略到分代策略。如果目前空閑塊在高地址，則掃描objs，將年老的數據塊移動到高地址的空閑區域，最后縮并低地址區域；否則將年輕的數據塊移動到低地址的空閑區域，最后縮并高地址區域。性能為O(N)。

（6）分代策略到節點復制策略。縮并newGen，將oldGen移動到低地址，緊跟在newGen之后；設置空閑地址偏移指針。性能為O(N)。

這些切換邏輯通常只需要一遍掃描就可以完成切換過程，一般均在O(N)或者O(M)步之內完成。其中節點復制策略到標記—清掃策略只需要常數步驟即可完成。

3結束語

在基礎測試平臺上實現了一個支持動態切換內存管理策略的共享內存管理框架，并在框架內基于三種成熟的內存垃圾自動回收算法實現了三套可供切換的共享內存管理策略。切換的規則綜合考慮了運行時刻系統的多項內存統計特征，能夠及時地選擇并切換到可能最為合適的策略。

在基礎測試平臺上運行了一系列需要組件間大量通信的并發測試并記錄共享內存操作的總時間。結果表明，與單一的共享內存管理策略相比，能動態切換管理策略的共享內存管理框架的性能有了明顯的改善。 

目前支持切換的元數據結構的實現還比較簡單（多數結構用數組實現），性能有待提高。其次，三套策略的實現也需要改進，目前的實現基于三種比較樸素的成熟算法，下一步將考慮實現一些更為先進的內存管理策略。

參考文獻：

［1］

ETSI ES 201 873－1， v2.2.1.The testing and test control notation version 3: TTCN－3 core language[S].[S.l.]:[s.n.].

[2]STEPHEN M B， RICHARD J， KATHRYN S，et al.Beltway:getting around garbage collection gridlock:proc. of the ACM SIGPLAN 2002 Conference on Programming Language Design and Implementation[C]. Berlin:[s.n.]，2002：153－164.

[3]DAVID F B， CLEMENT R A，HAN B L，et al.Java without the coffee breaks: a nonintrusive multiprocessor garbage collector:proc. of the ACM SIGPLAN 2001 Conference on Programming Language Design and Implementation[C].Snowbird，USA[s.n.]，2001:92－103.

[4]STEPHEN M B， SINGHAI S，HERTZ M，et al.Pretenuring for Java:proc. of the 16th ACM SIGPLAN Conference on Object－Oriented Programming， Systems， Languages， and Applications[C].Tampa Bay，USA:[s.n.]，2001:342－352.

[5]JONES R，LINS R.Garbage collection:algorithms for automatic dynamic memory management[M].[S.l.]:John Wiley Sons， 1996.

[6]SOMAN S，KRINTZ C，BACON D.Dynamic selection of application－specific garbage collectors:proc. of the 4th International Symposium on Memory Management[C].Vancouver，Canada[s.n.]，2004:49－60.

[7]YANG T，HERTZ M，EMERY D B，et al.Automatic heap sizing: ta－king real memory into account:proc. of the 4th International Symposium on Memory Management[C].Vancouver，Canada[s.n.]，2004:61－72.

[8]GAMMA E，HELM R，JOHNSON R，et al.Design patterns:elements of reusable object－oriented software[M].[S.l.]:Addison－Wesley Professional，1995.

[9]AZATCHI H，LEVANONI Y，PAZ H，et al.An on－the－fly mark and sweep garbage collector based on sliding view:proc. of the 18th Annual ACM SIGPLAN Conference on Object－Oriented Programming， Systems， Languages， and Applications[C].Anaheim，USA:[s.n.]，2003:269－281.

[10]CHEN Yongcher，ANTHONY L H，VIJAYKUMAR T N.Software prefetching for mark－sweep garbage collection: Hardware analysis and software redesign:proc. of the 11th International Conference on Architectural Support for Programming Languages and Operating Systems[C].Boston，USA:[s.n.]，2004:199－210.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”