前言 在上一篇文章CLR類型系統概述里提到,當運行時掛起時, 垃圾回收會執行堆棧遍歷器(stack walker)去拿到堆棧上值類型的大小和堆棧根。這裡我們來翻譯BotR里一篇專門介紹Stackwalking的文章,希望能加深理解。 順便說一句,StackWalker在中文里似乎還沒有統一的翻譯,J ...
前言
在上一篇文章CLR類型系統概述里提到,當運行時掛起時, 垃圾回收會執行堆棧遍歷器(stack walker)去拿到堆棧上值類型的大小和堆棧根。這裡我們來翻譯BotR里一篇專門介紹Stackwalking的文章,希望能加深理解。
順便說一句,StackWalker
在中文里似乎還沒有統一的翻譯,Java里有把它翻譯成堆棧步行器
,微軟有的(機翻)文檔把它翻譯為堆棧查看器
,我這裡暫且將它翻譯為堆棧遍歷器
,如有更合適的翻譯,歡迎評論區指出。
.NET運行時之書(Book of the Runtime,簡稱BotR)是一系列描述.NET運行時的文檔,2007年左右在微軟內部創建,最初目的是為了幫助其新員工快速上手.NET運行時;隨著.NET開源,BotR也被公開了出來,如果想深入理解CLR,這系列文章不可錯過。
BotR系列目錄:
[1] CLR類型載入器設計(Type Loader Design)
[2] CLR類型系統概述(Type System Overview)
[3] CLR堆棧遍歷(Stackwalking in CLR)
CLR堆棧遍歷(Stackwalking in CLR)
原文:https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/stackwalking.md
作者: Rudi Martin - 2008
翻譯:幾秋 (https://www.cnblogs.com/netry/)
CLR大量使用了一種稱為堆棧遍歷(或者也叫stack crawling)的技術,這涉及迭代特定線程的調用幀(call frames)序列,從最近的調用幀(線程的當前函數)後退到堆棧的底部。
運行時出於多種目的使用堆棧遍歷:
- 在垃圾回收期間,運行時遍歷所有線程的堆棧尋找托管根(局部變數在托管方法的幀中擁有對象的引用,需要被報告給GC,以保持對象活躍和跟蹤,並且如果GC決定壓縮堆,則可能跟蹤它們的動向)。
- 在一些平臺上,異常處理的過程中,會使用堆棧遍歷器(第一遍尋找句柄,第二遍展開堆棧(unwinding the stack))。
- 各種各樣的方法,通常是那些靠近某些公共托管API的方法,執行堆棧遍歷以獲取有關其調用者的信息(例如調用者的方法、類或者程式集)。
堆棧模型
在這裡,我們定義了一些常用術語並描述了線程堆棧的典型佈局。
邏輯上,一個堆棧被拆分成若幹個幀(frame),每一幀代表若幹函數(托管或非托管),這些函數要麼是當前正在執行的,要麼是已經調用了其它函數,正在等待返回。幀包含了其關聯函數的特定調用所需的狀態。通常包括局部變數的空間、調用另一個函數的推送參數、保存的調用者寄存器等。
幀的具體定義因平臺而異,在很多平臺上,並沒有一個所有函數都嚴格遵守的幀格式定義(x86平臺就是其中一個例子)。相反,編譯器通常可以自由優化幀的具體格式,在這樣的系統上,無法保證堆棧遍歷返回100正確或者完整的結果(出於調試目的,會使用像pdb文件這樣的符號表來填補空白,以便調試器可以生成更準確的堆棧跟蹤)。
然而這對CLR來說不是一個問題,因為我們不需要完全廣義(fully generalized)的的堆棧遍歷,相反我們只對來自以下情況的幀感興趣:
- 被托管的方法
- 在某種程度上,來自用於實現運行時本身的非托管代碼
特別是不保證第三方非托管幀的保真度(fidelity),除非知道到這些幀在何處轉換到運行時本身或從運行時本身轉換出來(也就是我們感興趣的一種幀)。
因為我們控制我們感興趣幀的格式(我們稍後再詳細討論這個問題),我們可以確保這些幀可抓取(crawlable),且具有100%的保真度。唯一的額外要求是一種將不相交的運行時幀(disjoint groups of runtime frames)鏈接在一起的機制,這樣我們就可以跳過任何干預的非托管幀(和不可抓取的)。
下圖說明瞭包含所有幀類型的堆棧(請註意,本文檔使用了一種慣例,即堆棧向葉(page)頂部增長):
使幀可抓取
托管幀
因為運行時擁有和控制JIT(Just-in-Time編譯器),它可以安排托管方法始終留下可以抓取的幀。這裡的一種解決方案是對所有方法使用嚴格的(rigid)幀格式。然而在實踐中,這可能低效,尤其是對於小葉子(small leaf)方法(例如典型的屬性訪問器)。
因為方法的調用次數通常多於其幀被抓取的次數(抓取堆棧在運行時中是相對較少的,至少就通常調用方法的速率而言),用方法調用性能換取一些額外的抓取時間是有合理的。因此,JIT會為其編譯的每個方法生成額外的元數據,其中包括足夠的信息,供堆棧爬蟲解碼屬於該方法的堆棧幀。
這些元數據可以通過以方法中某處的指令指針(instruction pointer)作為鍵,查找哈希表得到。JIT使用壓縮技術來最小化這種額外的每方法元數據的影響。
給定幾個重要寄存器的初始值(例如,基於 x86 的系統上的 EIP、ESP 和 EBP),堆棧爬蟲可以定位托管方法和其關聯的JIT元數據,並使用這些信息將寄存器值回滾到方法調用者中的當前值。用這種方式,可以從最近的調用者到最老的調用者,遍歷一系列托管方法幀,此操作有時稱為虛擬展開(virtual unwind)(虛擬的是因為我們實際上並沒有更新ESP等的真實值,堆棧保持不變)。
運行時非托管幀
運行時(有)部分是以非托管代碼實現的(例如coreclr.dll). 大多數這些代碼的特殊之處在於,它是作為手動托管的代碼運行,也就是說,它遵守托管代碼的許多規則和協議,但以顯式控制的方式。例如,此類代碼可以顯式地啟用或禁用GC搶占模式(pre-emptive mode),並且需要相應地管理其對象引用的使用。
與托管代碼進行這種謹慎交互的另一個區域是在堆棧遍歷過程中。由於大多數運行時的非托管代碼是用C++編寫的,因此我們對方法幀格式的控制不如托管代碼。同時,在很多情況下,運行時非托管幀包含了堆棧遍歷期間非常重要的信息,這包括非托管函數在局部變數中保存對象引用(必須在垃圾回收期間報告)和異常處理的情況。
非托管函數不是試圖使每個非托管幀變得抓取,而是將有趣的數據報告到堆棧爬蟲,
與其試圖使每個非托管幀可抓取,帶有有趣信息的非托管函數,堆棧爬取將信息捆綁到數據結構中,將信息捆綁到稱為Frame的數據結構中,這個名稱非常有歧義,因此本文檔總是將該數據結構變數稱為大寫的Frame。
Frame實際上是整個Frame類型層次結構的抽象基類。 Frame被子類型化,以表達堆棧遍歷可能感興趣的不同類型的信息。但是堆棧遍歷器如何找到這些Frame,並且它們與托管方法使用的幀有何關係?
每個Frame都是單鏈表的一部分,單鏈表有一個next指針,指向這個線程的堆棧上下一個更老的Frame(或者是null,如果這個Frame以及是最老的了)。CLR Thread結構持有一個指向最新Frame的指針。非托管運行時代碼可以根據需要通過操作線程(Thread)結構和Frame列表來推送(push)或彈出(pop)Frame。
按照這種方式,堆棧遍歷器可以按照最新到最舊的順序迭代非托管Frames, 但是托管和非托管的方法可以被交叉使用,並且處理後面跟著非托管Frames的所有托管幀將會出錯,反之亦然,因為它不能準確地表示真正的調用序列。
為瞭解決這個問題,Frame被進一步限制,它們必須被分配到堆棧上的方法幀中,該方法幀將它們推送到Frame列表中。由於堆棧遍歷器知道每個托管幀的堆棧邊界,因此它可以執行簡單的指針比較,以判斷給定Frame是否比給定托管幀舊或新。
本質上,堆棧遍歷器在解碼當前幀後,對於下一個(更老的)幀總是有兩種可能選擇:通過寄存器集(register set)的虛擬展開(virtual unwind)確定下一個托管幀,或者線程Frame列表上的下一個更老的Frame。這可以通過判斷哪個占用更靠近棧頂的棧空間來決定哪個合適。所涉及的(involved)實際計算是平臺相關的,但通常轉移(devolves)到一個或兩個指針比較上。
當托管代碼調用非托管運行時時,非托管目標方法通常會推送數種形式的轉換Frame中的一種,這被下麵兩種情況需要:
- 記錄調用托管方法的寄存器狀態(以便堆棧遍歷器在完成枚舉(enumerating)非托管Frames後可以恢復托管幀的虛擬展開)。
- 許多情況下因為托管對象引用作為參數傳遞給非托管方法,必須在垃圾回收時報告給GC。
可用Frame類型及其用途的完整描述超出了本文檔的範圍,更多的細節可以在frames.h頭文件里找到。
堆棧遍歷器介面
完整的堆棧遍歷介面僅公開給運行時非托管代碼(System.Diagnostics.StackTrace
類是一個對托管代碼可用的簡化子集),典型的入口點是通過運行時 Thread類上的StackWalkFramesEx()
方法,這個方法的調用者要提供下麵三個主要的輸入:
- 一些上下文指示遍歷的起點。 這是一個初始寄存器集(例如,如果你已暫停目標線程並可以在其上調用
GetThreadContext()
)或一個初始Frame(在你知道有問題的代碼是在運行時非托管代碼中的情況下)。 儘管大多數堆棧遍歷都是從堆棧頂部進行的,但如果你可以確定正確的起始上下文,則可以從較低位置開始。 - 一個函數指針和其關聯的上下文。函數是堆棧遍歷器為每個有趣的幀調用提供的函數(按從最新到最舊的順序), 提供的上下文值被傳遞給回調的每次調用,以便它可以在遍歷期間記錄或建立狀態。
- 指示應觸發回調的幀類型的標誌。 這允許調用者指定僅應報告的純托管方法幀。完整的列表請看threads.h (就在
StackWalkFramesEx()
聲明的上方).
StackWalkFramesEx()
返回一個枚舉值,該值指示遍歷是否正常終止(到達堆棧基並用完要報告的方法),是否被某一種回調中止(回調函數將同一類型的枚舉返回到堆棧遍歷)或遇到一些其它錯誤。
除了傳遞給StackWalkFramesEx()
的上下文值之外,堆棧回調函數還傳遞了另一段上下文:CrawlFrame
,這個類定義在 stackwalk.h ,這個類包含了在堆棧遍歷過程中收集的各種上下文。例如,CrawlFrame
為托管幀指示 MethodDesc*
,為非托管Frames指示 Frame*
。它還提供了通過虛擬展開幀推斷出的當前寄存器集到該點。
實現細節
堆棧遍歷實現的更多低級細節目前不在本文檔的範圍內。 如果您瞭解這些知識並願意分享這些知識,請隨時更新此文檔。
作者: 幾秋
出處: https://www.cnblogs.com/netry/p/clr-stack-worker-chinese.html
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文鏈接。