【譯】CLR類型加載器設計

類型加載器設計

作者: Ladi Prosek – 2007
翻譯：幾秋 (//home.cnblogs.com/u/netry/)

介紹

在一個基於類的（class-based）的面向對象系統中，類型（type）是一個模板，它描述了單個實例將包含的數據、將提供的功能。如果不首先定義對象的類型，就不可能創建對象1。如果兩個對象是同一個類型的實例，就可以說它們是同一個類型；事實上（即使）兩個對象定義了完全相同的成員，它們可能也沒有任何關聯。

上面一段可以用來描述一個典型的C++系統。CLR必不可少的一個附加功能是完整的運行時類型信息的可用性。為了「管理」託管代碼並提供類型安全的環境，運行時必須在任何時候都要能知道任意對象的類型。這種類型信息必須是不用大量計算就可以很容易地得到，因為類型標識查詢被認為是相當頻繁的（例如，任何類型轉換都涉及到查詢對象的類型標識，以驗證轉換是安全並且可以執行的）。

此性能要求排除了所有的字典查找方法，我們只剩下以下架構
圖一
圖一 抽象宏觀的對象設計

除了實際的實例數據之外，每個對象還包含一個類型id的指針, 指向表示該類型的結構。這個概念和C++虛表（v-table）指針相似，但是這個結構（我們現在稱為類型，後文會更精確地定義它），它包含的不僅僅是一個虛表，對於實例，它必須包含關於層次結構的信息（即繼承關係），以便能夠回答「is-a」的包含問題。

1C# 3.0引入的匿名類型，允許你不用顯示引用一個類型就可以定義對象 – 只需直接列出其字段即可，不要讓這愚弄你，實際上編譯器在幕後為你創建了一個類型。

1.1 相關閱讀

[1] Martin Abadi, Luca Cardelli, A Theory of Objects, ISBN
978-0387947754

[2] Andrew Kennedy (@andrewjkennedy), Don Syme (@dsyme), [Design and Implementation of Generics for the .NET Common Language Runtime][generics-design]
[generics-design]: //research.microsoft.com/apps/pubs/default.aspx?id=64031

[3] ECMA Standard for the Common Language Infrastructure (CLI)

1.2 設計目標

類型加載器（type loader）有時也稱為類加載器（class loader，常見於各種Java八股文），這種說法嚴格來說是不正確的，因為類（class）只是類型（type）的子集 – 即引用類型，類型加載器也會加載值類型，它的最終目的是構建表示要求它加載的類型的數據結構。以下是加載器應具有的屬性：

  • 快速類型查找 (通過[module, token] 或者 [assembly, name] 查找).
  • 優化的內存布局已實現良好的工作集大小、緩存命中率和 JIT編譯後的代碼性能。
  • 類型安全 – 不加載格式錯誤的類型，並拋出一個 TypeLoadException 異常。
  • 並發性 – 在多線程環境中具有良好的可擴展性。

2 類型加載器架構

加載器的入口點（entry-points，可以理解為公開的方法）數量相對較少。儘管每個入口點的簽名略有不同，但是它們都有相同的語義。它們採用以元數據 token或者name字符串為形式的類型/成員名稱，token的作用域（模塊或者程序集），以及一些附加信息如標誌；然後以句柄（handle）的形式返回已加載的實體。

在JIT過程中，通常會有調用很多次類型加載器。思考下面的代碼：

object CreateClass()
{
    return new MyClass();
}

在它IL代碼里，MyClass被一個元數據token所引用。為了生成一個對 JIT_New（它是真正完成實例化的函數） 幫助方法的調用指令，JIT會要求類型加載器去加載這個類型並返回一個句柄。然後這個句柄將作為一個立即數（immediate value）直接嵌入到JIT編譯後的代碼中。類型和成員通常是在JIT過程中被解析和加載的，而不是在運行時階段，它還解釋了像這樣的代碼有時容易引起混淆的行為：

object CreateClass()
{
    try {
        return new MyClass();
    } catch (TypeLoadException) {
        return null;
    }
}

如果MyClass加載失敗，例如，因為它應該在另一個程序集中定義，並且在最新的版本中被意外刪除了，所以此代碼仍將拋出TypeLoadException。這裡異常不會被捕獲的原因是這段代碼根本沒有執行！這個異常發生在JIT的過程中，只能在調用了CreateClass並使它JIT完成的方法里被捕獲。此外，由於內聯（inlining）的存在，觸發JIT的時機有時並不是那麼明顯，因此用戶不應該期待和依賴於這種不確定的行為。

關鍵數據結構

CLR中最通用的類型名稱是TypeHandle，它是一個的抽象實體，封裝了指向一個MethodTable（表示「普通的」類型像System.Object 或者 List<string>）或者一個TypeDesc（表示 byref、指針、函數指針、數組，以及泛型變量）的指針。它構成了一個類型的標識，因為當且僅當兩個句柄表示同一類型時，它們才是相等的。為了節省空間， TypeHandle通過設置指針的第二低位為 1（即 (ptr|2)）來表示它指向的TypeDesc，而不是用額外的標誌。TypeDesc是「抽象的」，並且有如下的繼承體系：

圖2

圖2 TypeDesc體系

TypeDesc

抽象類型描述符。具體的描述符類型由標誌確定。

TypeVarTypeDesc

表示一個類型變量，即 List<T>或者Array.Sort<T>中的T（參見下文關於泛型的部分）。類型變量不會在多個類型或者方法間共享，因此每個變量有且只有一個所有者。

FnPtrTypeDesc

表示一個函數指針,實質上是一個引用返回類型和參數的變長type handle列表，這個描述符不太常見，因為C#不支持函數指針。然後託管C++會使用它們。

ParamTypeDesc

這個描述符表示一個byref和指針類型，byref是ref 和 out這兩個C#關鍵字應用到方法參數3的結果，而指針類型是非託管的指針，指向unsafe C#和託管C++中使用的數據。

ArrayTypeDesc

表示數組類型. 派生自ParamTypeDesc，因為數組也由單個參數（其元素的類型）參數化。這與參數數量可變的泛型實例化相反。

MethodTable

這是目前為止運行時的最重要的數據結構，它表示所有不屬於上述類別的類型（它包括基本類型，開放（open）或閉合（closed）的泛型類型）。它包含了所有關於類型需要快速查找的信息，像它的父類型，實現的接口，和虛表。

EEClass

為了提高工作集和緩存利用率，MethodTable 的數據被分為「熱」和「冷」兩種結構。MethodTable 本身只存儲程序在穩定狀態（steady state）下所需的「熱」數據；而EEClass存儲通常只在類型加載、JIT 編譯或者反射中需要的「冷」數據。每個MethodTable 指向一個 EEClass.

此外，EEClass是被泛型共享的，多個泛型MethodTable可以指向同一個EEClass。這種共享對可以存儲在 EEClass 上的數據增加了額外的約束。

MethodDesc

顧名思義，此結構用來描述方法。它實際上有幾種變體，它們有相應的 MethodDesc子類型，但是大多數都超出了本文的討論範圍。這裡只需說其中一個叫做InstantiatedMethodDesc的子類型，它在泛型中扮演了重要角色。更多信息請參考Method Descriptor Design

FieldDesc

和MethodDesc相似 , 此結構用來描述字段。除了某些 COM 互操作場景，EE（EEClass中的EE，即Execution Engine，執行引擎）根本不在乎屬性和事件，因為它們最終歸結為方法和字段，只有編譯器和反射才能生成和理解它們，以便提供語法糖之類的體驗。

2這對調試很有用，如果一個TypeHandle的值是以2, 6, A, 或者E結尾，那麼它就是不是MethodTable，為了成功地觀察到TypeDesc，必須清除額外的位。

3注意ref和out之間的區別僅在於參數屬性，就類型系統而言，它們都是相同的類型。

2.1 加載級別

當類型加載器被要求加載一個指定的類型時，例如通過一個typedef/typeref/typespec的token和一個Module，它不會一次性做完所有的工作，而是分階段完成加載；這是因為一個類型經常會依賴其它的類型，如果在能被其它類型引用之前就完全加載，將導致無限遞歸和死鎖，思考下面的代碼：

class A<T> : C<B<T>>
{ }

class B<T> : C<A<T>>
{ }

class C<T>
{ }

上面的類型都是有效的，顯然 A與B相互依賴。

加載器首先會創建表示這個類型的一些結構，然後使用無需加載其它類型就可得到的數據來初始化它們。當「沒有依賴」的工作完成，這些結構就可以被其它地方所引用，通常是通過將指向它們的指針粘貼到其它結構中。之後，加載器以增量步驟進行，用越來越多的信息填充這些結構，直到類型完全加載完成。在上面的例子中，首先A 和 B的基類會近似於不包括其它類型，然後才會被真正的類型所替代。

所謂的加載加載級別，就是用來描述這些半加載狀態（ half-loaded），從 CLASS_LOAD_BEGIN開始，到CLASS_LOADED結束，中間還有一些中間級別。在 classloadlevel.h源文件里，每個級別都有豐富且有用的注釋。注意，雖然類型可以保存到NGEN鏡像中，但表示的結構不能簡單地映射或者寫入內存，然後不做額外「恢復」工作就使用。一個類型是來自於NGEN鏡像並且需要「恢復」，這一信息它的加載級別也可以感知到。

更多關於加載級別的解釋請看Design and Implementation of Generics for the .NET Common Language Runtime

2.2 泛型

在沒有泛型的世界裏，一切都很美好，每個人都很開心，因為每一個普通類型(不是由 TypeDesc 所表示的類型)都有一個 MethodTable指向他關聯的EEClass，這個EEClass又指回它的MethodTable，該類型的所有實例都包含一個指向MethodTable，作為偏移量為0處的第一個字段，即在被視為參考值的地址上。為了節省空間，由該類型聲明的MethodDesc表示方法，被組織在EEClass指向的塊鏈表中4。

圖3

圖3 具有非泛型方法的非泛型類型

4當然，當託管代碼運行時，它不會通過在這些塊中查找方法來調用它們，調用一個方法是很「熱」的操作，正常只需要訪問MethodTable中的信息。

2.2.1 術語

泛型形式參數（Generic Parameter）

一個能被其它類型替換的佔位符；如 List<T>中的T。有時也稱作形式類型參數（formal type parameter）。一個泛型形式參數有一個名字和一個可選的泛型約束。

泛型實際參數（Generic Argument）

一個替換泛型形式參數的具體類型；如List<int>中的int。注意，一個泛型形式參數也可以被用作泛型實際參數。思考下面的代碼：

List<T> GetList<T>()
{
    return new List<T>();
}

這個方法有一個泛型形式參數T，被用作泛型列表的泛型實際參數。

泛型約束

泛型形式參數對其潛在的泛型實際參數的可選要求。不滿足要求的類型不能替換形式參數，這是類型加載器強制的。有下面三種泛型約束：

  1. 特殊約束

    • 引用類型約束 —— 泛型實際參數必須是一個引用類型（相對應的是一個值類型）。在C#里，用class表示這個約束。
    public class A<T> where T : class
    • 值類型約束 —— 泛型實際參數必須是一個除System.Nullable<T>之外的值類型。C#里使用struct這個關鍵字。
    public class A<T> where T : struct
    • 默認構造函數約束 —— 泛型實際參數必須有個公開的無參構造函數。C#里用new()表示。
    public class A<T> where T : new()

  2. 基類約束 —— 泛型實際參數必須派生自（或者直接就是）給定的非接口類型。顯然最多只能有一個引用類型作為基類約束。

     public class A<T> where T : EventArgs

  3. 接口實現約束 —— 泛型實際參數必須實現（或者直接就是）給定的接口類型。可以同時有多個接口約束。

     public class A<T> where T : ICloneable, IComparable<T>

上面的約束可以被一個顯式AND組合起來，即一個泛型形式參數可以約束要派生自一個給定的類，實現幾個接口，並且還要有默認的構造函數。聲明類型的所有泛型參數都可以用來表示約束，從而在參數之間引入相互依賴關係，例如：

public class A<S, T, U>
	where S : T
	where T : IList<U> {
    void f<V>(V v) where V : S {}
}

實例（Instantiation）

一組泛型實際參數，用來替換泛型類型或者方法中的泛型形式參數。每一個加載的泛型和方法都有它的實例。

典型實例（Typical Instantiation）

一個實例僅僅包含類型或者方法自己的類型參數，且和聲明參數一樣的順序。每個泛型類型和方法只存在一個典型實例。通常當我們提到開放泛型類型（Open generic type）時，就是指它的典型實例，例如：

public class A<S, T, U> {}

C#會把typeof(A<,,>)編譯為一個ldtoken A\'3，讓運行時加載S , T , U實例化的 A`3。

規範實例（Canonical Instantiation）

一個所有泛型實際參數都是System.__Canon的實例。System.__Canon是一個定義在mscorlib中的內部類型，其任務只是為了作為規範，並且與其它可能用作泛型實際參數的類型不同。帶有規範實例的類型/方法被用作所有實例的代表，並攜帶所有實例共享的信息。由於System.__Canon顯然不能滿足泛型形參上可能攜帶的任何約束，因此約束檢查對於System.__Canon是特例，會忽略了這些行為。

2.2.2 共享

隨着泛型的出現，運行時加載的類型數量變得更多了，雖然不同實例的泛型(如List<string> and List<object>)是不同的類型，它們都有自己的MethodTable，事實證明，他們有大量信息可以共享。這種共享對內存足跡（memory footprint）有積極的影響，因此也會提高性能。

圖4
圖4 帶有非泛型方法的泛型類型 – 共享EEClass

當前所有包含引用類型的實例都共享同一個EEClass 和 它的 MethodDesc。這是可行的，因為所有的引用類型大小都一樣 —— 4或者8個位元組。因此所有這些類型的布局都是相同的。上圖為List<object>和List<string>闡明了這點。規範的 MethodTable在第一個引用類型實例被加載之前就自動創建，它包含了熱數據，但不是特定於像非虛的方法槽（non-virtual slots）或者RemotableMethodInfo實例。僅包含值類型的實例是不共享的，並且每個這種實例化的類型都有自己的未共享EEClass。

目前為止已加載泛型類型的MethodTable，會被緩存到一個屬於它們加載器模塊（loader module）的哈希表中5。在一個新的實例構造之前，首先會查詢這個哈希表，確保不會有兩個多種多個 MethodTable實例表示同一個類型。

更多關於泛型共享的信息請看Design and Implementation of Generics for the .NET Common Language Runtime

5從NGEN鏡像加載的類型，事情會變得有點複雜。

後記

本文翻譯自BotR中的一篇，原文鏈接 Type Loader Design ，可以幫助我們了解CLR的類型加載機制（注意是Type類型，而不是Class類），文中涉及到術語或者容易混淆的地方，我有在隨後的括號里列出原文和解釋。如有翻譯不正確的地方，歡迎指正。
文章內容偏底層，有很多瑣碎的概念，後面有機會我會一一寫文章介紹。

Tags:

VirMach 便宜 VPS

QNews

QNews