Möchten Sie verstehen, wie die CLR Laufzeitobjekte erstellt?

Ursprüngliche Adresse:
Ursprüngliches Veröffentlichungsdatum: 19.09.2005
Der Originalartikel wurde von Microsoft gelöscht. Während des Erfassungsprozesses wurde festgestellt, dass viele Artikel keine vollständigen Bilder enthielten. Das liegt daran, dass der Originaltext keine vollständigen Bilder enthielt. Daher wird hier der vollständige Text zusammengestellt.

Inhaltsverzeichnis

• Vorwort

• Domain erstellt durch CLR-Launcher (Bootstrap)

• Systemdomäne

• Gemeinsame Domäne

• Standarddomäne

• Loader Heaps

• Typprinzip

• Objektinstanz

• Methodentabelle

• Basisinstanzgröße

• Methodensteckplatztabelle

• MethodDesc

• Schnittstellen-Vtable Karte und Schnittstellenkarte

• Virtual Dispatch

• Statische Variablen

• EEClass

• Fazit

Vorwort

• SystemDomain, SharedDomain und DefaultDomain.

• Objektlayout und Speicherdetails.

• Methodentabellenlayout.

• Methodenversand.

Da die Common Language Runtime (CLR) im Begriff ist, zur Hauptinfrastruktur für die Erstellung von Anwendungen unter Windows zu werden, können Sie durch den Erwerb tiefergehender Kenntnisse über die CLR ein effizientes, industrielles Niveau aufbauen Robuste Anwendungen. In diesem Artikel werfen wir einen Blick auf das Innenleben der CLR, einschließlich des Objektinstanzlayouts, des Methodentabellenlayouts, des Methodenversands, des schnittstellenbasierten Versands und verschiedener Datenstrukturen.

Wir Es werden sehr einfache, in C# geschriebene Codebeispiele verwendet, sodass alle impliziten Verweise auf Programmiersprachen auf die C#-Sprache abzielen. Einige der besprochenen Datenstrukturen und Algorithmen werden in den Microsoft® .NET Framework-Änderungen in 2.0 enthalten sein, die meisten Konzepte jedoch Wir werden den Visual Studio® .NET 2003 Debugger und die Debugger-Erweiterung Son of Strike (SOS) verwenden, um einen Blick auf einige Datenstrukturen innerhalb der CLR zu werfen wird Klassen besprechen, die relevante Implementierungen in der Shared Source CLI (SSCLI) haben, die Sie von herunterladen können.

Diagramm 1 hilft bei der Suche nach einigen Strukturen.

ITEM	SSCLI PATH
AppDomain	sscliclrsrcvmappdomain.hpp
AppDomainStringLiteralMap	sscliclrsrcvmstringliteralmap.h
BaseDomain	sscliclrsrcvmappdomain.hpp
ClassLoader	sscliclrsrcvmclsload.hpp
EEClass	sscliclrsrcvmclass.h
FieldDescs	sscliclrsrcvmfield.h
GCHeap	sscliclrsrcvmgc.h
GlobalStringLiteralMap	sscliclrsrcvmstringliteralmap.h
HandleTable	sscliclrsrcvmhandletable.h
InterfaceVTableMapMgr	sscliclrsrcvmappdomain.hpp
Large Object Heap	sscliclrsrcvmgc.h
LayoutKind	sscliclrsrcbclsystemruntimeinteropserviceslayoutkind.cs
LoaderHeaps	sscliclrsrcincutilcode.h
MethodDescs	sscliclrsrcvmmethod.hpp
MethodTables	sscliclrsrcvmclass.h
OBJECTREF	sscliclrsrcvmtypehandle.h
SecurityContext	sscliclrsrcvmsecurity.h
SecurityDescriptor	sscliclrsrcvmsecurity.h
SharedDomain	sscliclrsrcvmappdomain.hpp
StructLayoutAttribute	sscliclrsrcbclsystemruntimeinteropservicesattributes.cs
SyncTableEntry	sscliclrsrcvmsyncblk.h
System namespace	sscliclrsrcbclsystem
SystemDomain	sscliclrsrcvmappdomain.hpp
TypeHandle	sscliclrsrcvmtypehandle.h

Bevor wir beginnen, beachten Sie bitte: Die in diesem Artikel bereitgestellten Informationen gelten nur für .NET Framework 1.1, das auf den Ausnahmen ausgeführt wird. Für .NET Framework 2.0 wird es Änderungen geben. Verlassen Sie sich daher bitte nicht auf deren Invarianz Interne Strukturen beim Erstellen von Software.

Vom CLR-Bootstrap erstellte Domänen

Bevor die CLR die erste Zeile des verwalteten Codes ausführt, werden drei Anwendungsdomänen erstellt. Zwei davon sind für verwalteten Code und sogar CLR-Hosts unsichtbar. Sie können nur durch den CLR-Startprozess erstellt werden, und die Shims, die den CLR-Startprozess bereitstellen, sind mscoree.dll und mscorwks.dll (mscorsvr.dll auf Multiprozessorsystemen). Wie in Abbildung 2 dargestellt, handelt es sich bei diesen Domänen um die Systemdomäne und die gemeinsam genutzte Domäne, die beide den Singleton-Modus verwenden. Die dritte Domäne ist die Standardanwendungsdomäne (Default AppDomain), die eine Instanz von AppDomain und die einzige benannte Domäne ist. Bei einfachen CLR-Hostprogrammen wie Konsolenprogrammen besteht der Standarddomänenname aus dem Namen der ausführbaren Imagedatei. Andere Domänen können in verwaltetem Code mithilfe der AppDomain.CreateDomain-Methode oder in nicht verwaltetem Code mithilfe der ICORRuntimeHost-Schnittstelle erstellt werden. Komplexe Hosts wie ASP.NET erstellen mehrere Domänen basierend auf der Anzahl der Anwendungen für eine bestimmte Website.

Abbildung 2Domäne, die vom CLR-Launcher erstellt wurde ↓

Systemdomäne (Systemdomäne)

Systemdomänen sind Verantwortlich für die Erstellung und Initialisierung gemeinsam genutzter Domänen und Standardanwendungsdomänen. Es lädt die Systembibliothek mscorlib.dll in die gemeinsam genutzte Domäne und verwaltet implizite oder explizite Zeichenfolgensymbole, die im Prozessbereich verwendet werden.

String-Internierung ist eine Optimierungsfunktion in .NET Framework 1.1. Die Art und Weise, wie sie gehandhabt wird, ist etwas umständlich, da die CLR der Assembly keine Chance gibt, diese Funktion auszuwählen. Diese Funktion kann jedoch Speicherplatz sparen, indem in allen Anwendungsdomänen nur eine Zeichenfolge gespeichert wird, die einem bestimmten Symbol entspricht.

Die Systemdomäne ist auch für die Generierung der prozessweiten Schnittstellen-ID und der Schnittstelle verantwortlich, die zum Erstellen der virtuellen Schnittstellentabellenzuordnung (InterfaceVtableMaps) jeder Anwendungsdomäne verwendet wird. Die Systemdomäne verfolgt alle Domänen im Prozess und implementiert die Funktionalität zum Laden und Entladen von Anwendungsdomänen.

Shared Domain

Der gesamte Code, der keiner bestimmten Domäne angehört, wird in die Systembibliothek SharedDomain.Mscorlib geladen, die für Benutzercode in allen Anwendungsdomänen erforderlich ist. Es wird automatisch in die freigegebene Domäne geladen. Die Grundtypen des System-Namespace, wie Object, ValueType, Array, Enum, String und Delegate usw., werden während des CLR-Startvorgangs vorab in diese Domäne geladen. Benutzercode kann auch in diese Domäne geladen werden, indem das LoaderOptimization-Attribut verwendet wird, das vom CLR-Hostprogramm beim Aufruf von CorBindToRuntimeEx angegeben wird. Ein Konsolenprogramm kann auch Code in eine gemeinsam genutzte Domäne laden, indem es die Main-Methode mithilfe des System.LoaderOptimizationAttribute-Attributs deklariert. Die gemeinsam genutzte Domäne verwaltet auch eine anhand der Basisadresse indizierte Assembly-Zuordnung, die als Nachschlagetabelle zum Verwalten von Abhängigkeiten von gemeinsam genutzten Assemblys fungiert, die in die DefaultDomain und andere in der verwalteten Code-Programmdomäne erstellte Anwendungen geladen werden. Nicht gemeinsam genutzter Benutzercode wird in die Standarddomäne geladen.

Standarddomäne

Die Standarddomäne ist eine Instanz der Anwendungsdomäne (AppDomain), in der allgemeiner Anwendungscode ausgeführt wird. Obwohl einige Anwendungen die Erstellung zusätzlicher Anwendungsdomänen zur Laufzeit erfordern (z. B. solche, die Plugins, Plug-Ins oder Frameworks verwenden oder eine erhebliche Laufzeitcodegenerierung durchführen), erstellen die meisten Anwendungen nur eine zur Laufzeit. Der gesamte in dieser Domäne ausgeführte Code ist auf Domänenebene kontextsensitiv. Wenn eine Anwendung über mehrere Anwendungsdomänen verfügt, erfolgt der domänenübergreifende Zugriff über den .NET Remoting-Proxy. Zusätzliche domäneninterne Kontextbegrenzungsinformationen können mithilfe von Typen erstellt werden, die von System.ContextBoundObject abgeleitet sind. Jede Anwendungsdomäne verfügt über einen eigenen Sicherheitsdeskriptor (SecurityDescriptor), Sicherheitskontext (SecurityContext) und Standardkontext (DefaultContext) sowie einen eigenen Loader-Heap (Hochfrequenz-Heap, Niederfrequenz-Heap und Proxy-Heap), Handle-Tabelle und virtuelle Schnittstellentabelle Manager und Assembly-Cache.

Loader-Heaps

Die Rolle des Loader-Heaps besteht darin, verschiedene Laufzeit-CLR-Komponenten zu laden und Komponenten zu optimieren, die während der gesamten Lebensdauer der Domäne vorhanden sind. Diese Heaps wachsen in vorhersehbaren Blöcken, wodurch die Fragmentierung minimiert wird. Der Loader-Heap unterscheidet sich vom Garbage-Collected-Heap (oder mehreren Heaps auf einem symmetrischen Multiprozessor) darin, dass der Garbage-Collected-Heap Objektinstanzen enthält, während der Loader-Heap auch das Typsystem enthält. Komponenten, auf die häufig zugegriffen wird, wie Methodentabellen, Methodenbeschreibungen, Domänenbeschreibungen und Schnittstellendiagramme, werden auf dem Heap mit hoher Frequenz zugewiesen, während Datenstrukturen, auf die weniger häufig zugegriffen wird, wie EEClass und Klassenlader und deren Nachschlagetabellen, auf dem Heap mit niedriger Frequenz zugewiesen werden. Der Proxy-Heap enthält Proxy-Komponenten, die für Code Access Security (CAS) verwendet werden, wie z. B. COM-Wrapper-Aufrufe und Plattformaufrufe (P/Invoke).

Nachdem wir die Domänen auf hoher Ebene verstanden haben, sind wir bereit, ihre physischen Details im Kontext einer einfachen Anwendung zu betrachten, siehe Abbildung 3. Wir stoppen bei mc.Method1(), während das Programm läuft, und verwenden dann den SOS-Debugger-Erweiterungsbefehl DumpDomain, um Domäneninformationen auszugeben. (Informationen zum SOS-Laden finden Sie unter Son of Strike). Hier ist die bearbeitete Ausgabe:

Abbildung 3Sample1.exe

!DumpDomain
System Domain: 793e9d58, LowFrequencyHeap: 793e9dbc,
HighFrequencyHeap: 793e9e14, StubHeap: 793e9e6c,
Assembly: 0015aa68 [mscorlib], ClassLoader: 0015ab40

Shared Domain: 793eb278, LowFrequencyHeap: 793eb2dc,
HighFrequencyHeap: 793eb334, StubHeap: 793eb38c,
Assembly: 0015aa68 [mscorlib], ClassLoader: 0015ab40

Domain 1: 149100, LowFrequencyHeap: 00149164,
HighFrequencyHeap: 001491bc, StubHeap: 00149214,
Name: Sample1.exe, Assembly: 00164938 [Sample1],
ClassLoader: 00164a78

using System;public interface MyInterface1
{void Method1();void Method2();
}public interface MyInterface2
{void Method2();void Method3();
}class MyClass : MyInterface1, MyInterface2
{public static string str = "MyString";public static uint   ui = 0xAAAAAAAA;public void Method1() { Console.WriteLine("Method1"); }public void Method2() { Console.WriteLine("Method2"); }public virtual void Method3() { Console.WriteLine("Method3"); }
}class Program
{static void Main()
    {
        MyClass mc = new MyClass();
        MyInterface1 mi1 = mc;
        MyInterface2 mi2 = mc;int i = MyClass.str.Length;uint j = MyClass.ui;

        mc.Method1();
        mi1.Method1();
        mi1.Method2();
        mi2.Method2();
        mi2.Method3();
        mc.Method3();
    }
}

Unser Konsolenprogramm, Sample1 exe, ist in eine Anwendungsdomäne mit dem Namen „Sample1.exe“ geladen. Mscorlib.dll wird in die gemeinsam genutzte Domäne geladen, aber da es sich um eine Kernsystembibliothek handelt, wird sie auch in der Systemdomäne aufgeführt. Jeder Domäne wird ein Hochfrequenz-Heap, ein Niederfrequenz-Heap und ein Proxy-Heap zugewiesen. Die Systemdomäne und die gemeinsam genutzte Domäne verwenden denselben Klassenlader, während die Standardanwendung ihren eigenen Klassenlader verwendet.

Die Ausgabe zeigt nicht die reservierten und festgeschriebenen Größen des Loader-Heaps. Die anfängliche Größe des Hochfrequenz-Heaps beträgt 32 KB und jeder Commit beträgt 4 KB. Die Ausgabe von SOS zeigt auch nicht den virtuellen Tabellenheap der Schnittstelle (InterfaceVtableMap). Jede Domäne verfügt über einen virtuellen Schnittstellentabellen-Heap (als IVMap bezeichnet), der während der Domäneninitialisierungsphase von einem eigenen Loader-Heap erstellt wird. Die reservierte IVMap-Größe beträgt 4 KB und schreibt zunächst 4 KB fest. Wir werden die Bedeutung von IVMap in den folgenden Abschnitten bei der Untersuchung des Typlayouts diskutieren.

Abbildung 2 zeigt den Standard-Prozess-Heap, den JIT-Code-Heap, den GC-Heap (für kleine Objekte) und den großen Objekt-Heap (für Objekte mit einer Größe von mindestens 85.000 Bytes). veranschaulicht die semantischen Unterschiede zwischen diesen Heaps und dem Loader-Heap. Der Just-in-Time-Compiler (JIT) generiert x86-Anweisungen und speichert sie im JIT-Code-Heap. Der GC-Heap und der Large-Object-Heap sind Garbage-Collected-Heaps, die für die Instanziierung verwalteter Objekte verwendet werden.

Typprinzip

Typ ist die Grundeinheit in der .NET-Programmierung. In C# können Typen mit den Schlüsselwörtern class, struct und interface deklariert werden. Die meisten Typen werden explizit vom Programmierer erstellt. In speziellen Interop-Situationen und Remote-Objektaufrufen (.NET Remoting) generiert die .NET-CLR jedoch implizit Typen, die aufrufbare COM- und Runtime-Wrapper sowie transparente Proxys umfassen.

Wir beginnen unser Studium der .NET-Typprinzipien mit einem Stapel, der Objektreferenzen enthält (normalerweise ist der Stapel der Ort, an dem eine Objektinstanz ihren Lebenszyklus beginnt). Der in Abbildung 4 gezeigte Code enthält ein einfaches Programm, das einen Einstiegspunkt zur Konsole hat und eine statische Methode aufruft. Methode 1 erstellt eine SmallClass-Typinstanz, die ein Byte-Array enthält, um zu veranschaulichen, wie Objekte auf dem großen Objektheap erstellt werden. Obwohl dies ein langweiliger Code ist, kann er unserer Diskussion helfen.

Abbildung 4Große Objekte und kleine Objekte

using System;class SmallClass
{private byte[] _largeObj;public SmallClass(int size)
    {
        _largeObj = new byte[size];
        _largeObj[0] = 0xAA;
        _largeObj[1] = 0xBB;
        _largeObj[2] = 0xCC;
    }public byte[] LargeObj
    {get { return this._largeObj; }
    }
}class SimpleProgram
{static void Main(string[] args)
    {
        SmallClass smallObj = SimpleProgram.Create(84930,10,15,20,25);return;
    }static SmallClass Create(int size1, int size2, int size3,int size4, int size5)
    {int objSize = size1 + size2 + size3 + size4 + size5;
        SmallClass smallObj = new SmallClass(objSize);return smallObj;
    }
}

图5 显示了停止在Create方法"return smallObj;" 代码行断点时的fastcall栈结构（fastcall时.NET的调用规范，它说明在可能的情况下将函数参数通过寄存器传递，而其它参数按照从右到左的顺序入栈，然后由被调用函数完成出栈操作）。本地值类型变量objSize内含在栈结构中。引用类型变量如smallObj以固定大小（4字节DWORD）保存在栈中，包含了在一般GC堆中分配的对象的地址。对于传统C++，这是对象的指针；在托管世界中，它是对象的引用。不管怎样，它包含了一个对象实例的地址，我们将使用术语对象实例（ObjectInstance）描述对象引用指向地址位置的数据结构。

图5 SimpleProgram的栈结构和堆

一般GC堆上的smallObj对象实例包含一个名为 _largeObj 的字节数组（注意，图中显示的大小为85016字节，是实际的存贮大小）。CLR对大于或等于85000字节的对象的处理和小对象不同。大对象在大对象堆（LOH）上分配，而小对象在一般GC堆上创建，这样可以优化对象的分配和回收。LOH不会压缩，而GC堆在GC回收时进行压缩。还有，LOH只会在完全GC回收时被回收。

smallObj的对象实例包含类型句柄（TypeHandle），指向对应类型的方法表。每个声明的类型有一个方法表，而同一类型的所有对象实例都指向同一个方法表。它包含了类型的特性信息（接口，抽象类，具体类，COM封装和代理），实现的接口数目，用于接口分派的接口图，方法表的槽（slot）数目，指向相应实现的槽表。

方法表指向一个名为EEClass的重要数据结构。在方法表创建前，CLR类加载器从元数据中创建EEClass。 图4中，SmallClass的方法表指向它的EEClass。这些结构指向它们的模块和程序集。方法表和EEClass一般分配在共享域的加载器堆。加载器堆和应用程序域关联，这里提到的数据结构一旦被加载到其中，就直到应用程序域卸载时才会消失。而且，默认的应用程序域不会被卸载，所以这些代码的生存期是直到CLR关闭为止。

对象实例

正如我们说过的，所有值类型的实例或者包含在线程栈上，或者包含在 GC 堆上。所有的引用类型在 GC 堆或者 LOH 上创建。图 6 显示了一个典型的对象布局。一个对象可以通过以下途径被引用：基于栈的局部变量，在交互操作或者平台调用情况下的句柄表，寄存器（执行方法时的 this 指针和方法参数），拥有终结器（ finalizer ）方法的对象的终结器队列。 OBJECTREF 不是指向对象实例的开始位置，而是有一个 DWORD 的偏移量（ 4 字节）。此 DWORD 称为对象头，保存一个指向 SyncTableEntry 表的索引（从 1 开始计数的 syncblk 编号。因为通过索引进行连接，所以在需要增加表的大小时， CLR 可以在内存中移动这个表。 SyncTableEntry 维护一个反向的弱引用，以便 CLR 可以跟踪 SyncBlock 的所有权。弱引用让 GC 可以在没有其它强引用存在时回收对象。 SyncTableEntry 还保存了一个指向 SyncBlock 的指针，包含了很少需要被一个对象的所有实例使用的有用的信息。这些信息包括对象锁，哈希编码，任何转换层 (thunking) 数据和应用程序域的索引。对于大多数的对象实例，不会为实际的 SyncBlock 分配内存，而且 syncblk 编号为 0 。这一点在执行线程遇到如 lock(obj) 或者 obj.GetHashCode 的语句时会发生变化，如下所示：

SmallClass obj = new SmallClass()
// Do some work here
lock(obj) { /* Do some synchronized work here */ }
obj.GetHashCode();

图 6 对象实例布局

在以上代码中， smallObj 会使用 0 作为它的起始的 syncblk 编号。 lock 语句使得 CLR 创建一个 syncblk 入口并使用相应的数值更新对象头。因为 C# 的 lock 关键字会扩展为 try-finally 语句并使用 Monitor 类，一个用作同步的 Monitor 对象在 syncblk 上创建。堆 GetHashCode 的调用会使用对象的哈希编码增加 syncblk 。
在 SyncBlock 中有其它的域，它们在 COM 交互操作和封送委托（ marshaling delegates ）到非托管代码时使用，不过这和典型的对象用处无关。
类型句柄紧跟在对象实例中的 syncblk 编号后。为了保持连续性，我会在说明实例变量后讨论类型句柄。实例域（ Instance field ）的变量列表紧跟在类型句柄后。默认情况下，实例域会以内存最有效使用的方式排列，这样只需要最少的用作对齐的填充字节。图 7 的代码显示了 SimpleClass 包含有一些不同大小的实例变量。

图 7 SimpleClass with Instance Variables

class SimpleClass
{
    private byte b1 = 1;                // 1 byte
    private byte b2 = 2;                // 1 byte
    private byte b3 = 3;                // 1 byte
    private byte b4 = 4;                // 1 byte
    private char c1 = 'A';              // 2 bytes
    private char c2 = 'B';              // 2 bytes
    private short s1 = 11;              // 2 bytes
    private short s2 = 12;              // 2 bytes
    private int i1 = 21;                // 4 bytes
    private long l1 = 31;               // 8 bytes
    private string str = "MyString"; // 4 bytes (only OBJECTREF)

    //Total instance variable size = 28 bytes 

    static void Main()
    {
        SimpleClass simpleObj = new SimpleClass();
        return;
    }
}

图 8 显示了在 Visual Studio 调试器的内存窗口中的一个 SimpleClass 对象实例。我们在图 7 的 return 语句处设置了断点，然后使用 ECX 寄存器保存的 simpleObj 地址在内存窗口显示对象实例。前 4 个字节是 syncblk 编号。因为我们没有用任何同步代码使用此实例（也没有访问它的哈希编码）， syncblk 编号为 0 。保存在栈变量的对象实例，指向起始位置的 4 个字节的偏移处。字节变量 b1,b2,b3 和 b4 被一个接一个的排列在一起。两个 short 类型变量 s1 和 s2 也被排列在一起。字符串变量 str 是一个 4 字节的 OBJECTREF ，指向 GC 堆中分配的实际的字符串实例。字符串是一个特别的类型，因为所有包含同样文字符号的字符串，会在程序集加载到进程时指向一个全局字符串表的同一实例。这个过程称为字符串驻留（ string interning ），设计目的是优化内存的使用。我们之前已经提过，在 NET Framework 1.1 中，程序集不能选择是否使用这个过程，尽管未来版本的 CLR 可能会提供这样的能力。

图 8 Debugger Memory Window for Object Instance

所以默认情况下，成员变量在源代码中的词典顺序没有在内存中保持。在交互操作的情况下，词典顺序必须被保存到内存中，这时可以使用 StructLayoutAttribute 特性，它有一个 LayoutKind 的枚举类型作为参数。 LayoutKind.Sequential 可以为被封送（ marshaled ）数据保持词典顺序，尽管在 .NET Framework 1.1 中，它没有影响托管的布局（但是 .NET Framework 2.0 可能会这么做）。在交互操作的情况下，如果你确实需要额外的填充字节和显示的控制域的顺序， LayoutKind.Explicit 可以和域层次的 FieldOffset 特性一起使用。

看完底层的内存内容后，我们使用 SOS 看看对象实例。一个有用的命令是 DumpHeap ，它可以列出所有的堆内容和一个特别类型的所有实例。无需依赖寄存器， DumpHeap 可以显示我们创建的唯一一个实例的地址。

!DumpHeap -type SimpleClass
Loaded Son of Strike data table version 5 from
"C:WINDOWSMicrosoft.NETFrameworkv1.1.4322mscorwks.dll"
 Address       MT     Size
00a8197c 00955124       36
Last good object: 00a819a0
total 1 objects
Statistics:
      MT    Count TotalSize Class Name
  955124        1        36 SimpleClass

对象的总大小是 36 字节，不管字符串多大， SimpleClass 的实例只包含一个 DWORD 的对象引用。 SimpleClass 的实例变量只占用 28 字节，其它 8 个字节包括类型句柄（ 4 字节）和 syncblk 编号（ 4 字节）。找到 simpleObj 实例的地址后，我们可以使用 DumpObj 命令输出它的内容，如下所示：

!DumpObj 0x00a8197c
Name: SimpleClass
MethodTable 0x00955124
EEClass 0x02ca33b0
Size 36(0x24) bytes
FieldDesc*: 00955064
      MT    Field   Offset                 Type       Attr    Value Name
00955124  400000a        4         System.Int64   instance      31 l1
00955124  400000b        c                CLASS   instance 00a819a0 str
    << some fields omitted from the display for brevity >>
00955124  4000003       1e          System.Byte   instance        3 b3
00955124  4000004       1f          System.Byte   instance        4 b4

正如之前说过， C# 编译器对于类的默认布局使用 LayoutType.Auto （对于结构使用 LayoutType.Sequential ）；因此类加载器重新排列实例域以最小化填充字节。我们可以使用 ObjSize 来输出包含被 str 实例占用的空间，如下所示：

!ObjSize 0x00a8197c
sizeof(00a8197c) =       72 (    0x48) bytes (SimpleClass)

如果你从对象图的全局大小（ 72 字节）减去 SimpleClass 的大小（ 36 字节），就可以得到 str 的大小，即 36 字节。让我们输出 str 实例来验证这个结果：

!DumpObj 0x00a819a0
Name: System.String
MethodTable 0x009742d8
EEClass 0x02c4c6c4
Size 36(0x24) bytes

如果你将字符串实例的大小（36字节）加上SimpleClass实例的大小（36字节），就可以得到ObjSize命令报告的总大小72字节。

请注意ObjSize不包含syncblk结构占用的内存。而且，在.NET Framework 1.1中，CLR不知道非托管资源占用的内存，如GDI对象，COM对象，文件句柄等等；因此它们不会被这个命令报告。

指向方法表的类型句柄在syncblk编号后分配。在对象实例创建前，CLR查看加载类型，如果没有找到，则进行加载，获得方法表地址，创建对象实例，然后把类型句柄值追加到对象实例中。JIT编译器产生的代码在进行方法分派时使用类型句柄来定位方法表。CLR在需要史可以通过方法表反向访问加载类型时使用类型句柄。

Son of Strike
SOS调试器扩展程序用于本文化的显示CLR数据结构的内容，它是 .NET Framework 安装程序的一部分，位于 %windir%\Microsoft.NET\Framework\v1.1.4322。SOS加载到进程之前,在 Visual Studio 中启用托管代码调试。 添加 SOS.dll 所在的文件夹到PATH环境变量中。 加载 SOS.dll, 然后设置一个断点， 打开 Debug|Windows|Immediate。然后在 Immediate 窗口中执行 .load sos.dll。使用 !help 获取调试相关的一些命令，关于SOS更多信息，参考这里。

方法表

每个类和实例在加载到应用程序域时，会在内存中通过方法表来表示。这是在对象的第一个实例创建前的类加载活动的结果。对象实例表示的是状态，而方法表表示了行为。通过EEClass，方法表把对象实例绑定到被语言编译器产生的映射到内存的元数据结构（metadata structures）。方法表包含的信息和外挂的信息可以通过System.Type访问。指向方法表的指针在托管代码中可以通过Type.RuntimeTypeHandle属性获得。对象实例包含的类型句柄指向方法表开始位置的偏移处，偏移量默认情况下是12字节，包含了GC信息。我们不打算在这里对其进行讨论。

图 9 显示了方法表的典型布局。我们会说明类型句柄的一些重要的域，但是对于完全的列表，请参看此图。让我们从基实例大小（Base Instance Size）开始，因为它直接关系到运行时的内存状态。

图 9 方法表布局

基实例大小

基实例大小是由类加载器计算的对象的大小，基于代码中声明的域。之前已经讨论过，当前GC的实现需要一个最少12字节的对象实例。如果一个类没有定义任何实例域，它至少包含额外的4个字节。其它的8个字节被对象头（可能包含syncblk编号）和类型句柄占用。再说一次，对象的大小会受到StructLayoutAttribute的影响。

看看图3中显示的MyClass（有两个接口）的方法表的内存快照（Visual Studio .NET 2003内存窗口），将它和SOS的输出进行比较。在图9中，对象大小位于4字节的偏移处，值为12（0x0000000C）字节。以下是SOS的DumpHeap命令的输出：

!DumpHeap -type MyClass
 Address       MT     Size
00a819ac 009552a0       12
total 1 objects
Statistics:
    MT  Count TotalSize Class Name
9552a0      1        12    MyClass

方法槽表（Method Slot Table）

在方法表中包含了一个槽表，指向各个方法的描述（MethodDesc），提供了类型的行为能力。方法槽表是基于方法实现的线性链表，按照如下顺序排列：继承的虚方法，引入的虚方法，实例方法，静态方法。

类加载器在当前类，父类和接口的元数据中遍历，然后创建方法表。在排列过程中，它替换所有的被覆盖的虚方法和被隐藏的父类方法，创建新的槽，在需要时复制槽。槽复制是必需的，它可以让每个接口有自己的最小的vtable。但是被复制的槽指向相同的物理实现。MyClass包含接口方法，一个类构造函数（.cctor）和对象构造函数（.ctor）。对象构造函数由C#编译器为所有没有显式定义构造函数的对象自动生成。因为我们定义并初始化了一个静态变量，编译器会生成一个类构造函数。图10显示了MyClass的方法表的布局。布局显示了10个方法，因为Method2槽为接口IVMap进行了复制，下面我们会进行讨论。图11显示了MyClass的方法表的SOS的输出。

图10 MyClass MethodTable Layout

图11 SOS Dump of MyClass Method Table

!DumpMT -MD 0x9552a0
  Entry  MethodDesc  Return Type       Name
0097203b 00972040    String            System.Object.ToString()
009720fb 00972100    Boolean           System.Object.Equals(Object)
00972113 00972118    I4                System.Object.GetHashCode()
0097207b 00972080    Void              System.Object.Finalize()
00955253 00955258    Void              MyClass.Method1()
00955263 00955268    Void              MyClass.Method2()
00955263 00955268    Void              MyClass.Method2()
00955273 00955278    Void              MyClass.Method3()
00955283 00955288    Void              MyClass..cctor()
00955293 00955298    Void              MyClass..ctor()

任何类型的开始4个方法总是ToString, Equals, GetHashCode, and Finalize。这些是从System.Object继承的虚方法。Method2槽被进行了复制，但是都指向相同的方法描述。代码显示定义的.cctor和.ctor会分别和静态方法和实例方法分在一组。

方法描述（MethodDesc）

方法描述（MethodDesc）是CLR知道的方法实现的一个封装。有几种类型的方法描述，除了用于托管实现，分别用于不同的交互操作实现的调用。在本文中，我们只考察图3代码中的托管方法描述。方法描述在类加载过程中产生，初始化为指向IL。每个方法描述带有一个预编译代理（PreJitStub），负责触发JIT编译。图12显示了一个典型的布局，方法表的槽实际上指向代理，而不是实际的方法描述数据结构。对于实际的方法描述，这是-5字节的偏移，是每个方法的8个附加字节的一部分。这5个字节包含了调用预编译代理程序的指令。5字节的偏移可以从SOS的DumpMT输出从看到，因为方法描述总是方法槽表指向的位置后面的5个字节。在第一次调用时，会调用JIT编译程序。在编译完成后，包含调用指令的5个字节会被跳转到JIT编译后的x86代码的无条件跳转指令覆盖。

图 12方法描述

对图12的方法表槽指向的代码进行反汇编，显示了对预编译代理的调用。以下是在 Method2 被JIT编译前的反汇编的简化显示。

Method2：

!u 0x00955263
Unmanaged code
00955263 call        003C3538        ;call to the jitted Method2()
00955268 add         eax,68040000h   ;ignore this and the rest
                                     ;as !u thinks it as code

现在我们执行此方法，然后反汇编相同的地址：

!u 0x00955263
Unmanaged code
00955263 jmp     02C633E8        ;call to the jitted Method2()
00955268 add     eax,0E8040000h  ;ignore this and the rest
                                 ;as !u thinks it as code

在此地址，只有开始5个字节是代码，剩余字节包含了Method2的方法描述的数据。“!u”命令不知道这一点，所以生成的是错乱的代码，你可以忽略5个字节后的所有东西。

CodeOrIL在JIT编译前包含IL中方法实现的相对虚地址（Relative Virtual Address ，RVA）。此域用作标志，表示是否IL。在按要求编译后，CLR使用编译后的代码地址更新此域。让我们从列出的函数中选择一个，然后用DumpMT命令分别输出在JIT编译前后的方法描述的内容：

!DumpMD 0x00955268
Method Name : [DEFAULT] [hasThis] Void MyClass.Method2()
MethodTable 9552a0
Module: 164008
mdToken: 06000006
Flags : 400
IL RVA : 00002068

编译后，方法描述的内容如下：

!DumpMD 0x00955268
Method Name : [DEFAULT] [hasThis] Void MyClass.Method2()
MethodTable 9552a0
Module: 164008
mdToken: 06000006
Flags : 400
Method VA : 02c633e8

方法的这个标志域的编码包含了方法的类型，例如静态，实例，接口方法或者COM实现。让我们看方法表另外一个复杂的方面：接口实现。它封装了布局过程所有的复杂性，让托管环境觉得这一点看起来简单。然后，我们将说明接口如何进行布局和基于接口的方法分派的确切工作方式。

接口虚表图和接口图（Interface Vtable Map and Interface Map）

在方法表的第12字节偏移处是一个重要的指针，接口虚表（IVMap）。如图9所示，接口虚表指向一个应用程序域层次的映射表，该表以进程层次的接口ID作为索引。接口ID在接口类型第一次加载时创建。每个接口的实现都在接口虚表中有一个记录。如果MyInterface1被两个类实现，在接口虚表表中就有两个记录。该记录会反向指向MyClass方法表内含的子表的开始位置，如图9所示。这是接口方法分派发生时使用的引用。接口虚表是基于方法表内含的接口图信息创建，接口图在方法表布局过程中基于类的元数据创建。一旦类型加载完成，只有接口虚表用于方法分派。

第28字节位置的接口图会指向内含在方法表中的接口信息记录。在这种情况下，对MyClass实现的两个接口中的每一个都有两条记录。第一条接口信息记录的开始4个字节指向MyInterface1的类型句柄（见图9和图10）。接着的WORD（2字节）被一个标志占用（0表示从父类派生，1表示由当前类实现）。在标志后的WORD是一个开始槽（Start Slot），被类加载器用来布局接口实现的子表。对于MyInterface2，开始槽的值为4（从0开始编号），所以槽5和6指向实现；对于MyInterface2，开始槽的值为6，所以槽7和8指向实现。类加载器会在需要时复制槽来产生这样的效果：每个接口有自己的实现，然而物理映射到同样的方法描述。在MyClass中，MyInterface1.Method2和MyInterface2.Method2会指向相同的实现。

基于接口的方法分派通过接口虚表进行，而直接的方法分派通过保存在各个槽的方法描述地址进行。如之前提及，.NET框架使用fastcall的调用约定，最先2个参数在可能的时候一般通过ECX和EDX寄存器传递。实例方法的第一个参数总是this指针，所以通过ECX寄存器传送，可以在“mov ecx,esi”语句看到这一点：

mi1.Method1();
mov    ecx,edi                 ;move "this" pointer into ecx
mov    eax,dword ptr [ecx]     ;move "TypeHandle" into eax
mov    eax,dword ptr [eax+0Ch] ;move IVMap address into eax at offset 12
mov    eax,dword ptr [eax+30h] ;move the ifc impl start slot into eax
call   dword ptr [eax]         ;call Method1

mc.Method1();
mov    ecx,esi                 ;move "this" pointer into ecx
cmp    dword ptr [ecx],ecx     ;compare and set flags
call   dword ptr ds:[009552D8h];directly call Method1

这些反汇编显示了直接调用MyClass的实例方法没有使用偏移。JIT编译器把方法描述的地址直接写到代码中。基于接口的分派通过接口虚表发生，和直接分派相比需要一些额外的指令。一个指令用来获得接口虚表的地址，另一个获取方法槽表中的接口实现的开始槽。而且，把一个对象实例转换为接口只需要拷贝this指针到目标的变量。在图2中，语句“mi1=mc”使用一个指令把mc的对象引用拷贝到mi1。

虚分派（Virtual Dispatch）

现在我们看看虚分派，并且和基于接口的分派进行比较。以下是图3中MyClass.Method3的虚函数调用的反汇编代码：

mc.Method3();
Mov    ecx,esi               ;move "this" pointer into ecx
Mov    eax,dword ptr [ecx]   ;acquire the MethodTable address
Call   dword ptr [eax+44h]   ;dispatch to the method at offset 0x44

虚分派总是通过一个固定的槽编号发生，和方法表指针在特定的类（类型）实现层次无关。在方法表布局时，类加载器用覆盖的子类的实现代替父类的实现。结果，对父对象的方法调用被分派到子对象的实现。反汇编显示了分派通过8号槽发生，可以在调试器的内存窗口（如图10所示）和DumpMT的输出看到这一点。

静态变量（Static Variables）

静态变量是方法表数据结构的重要组成部分。作为方法表的一部分，它们分配在方法表的槽数组后。所有的原始静态类型是内联的，而对于结构和引用的类型的静态值对象，通在句柄表中创建的对象引用来指向。方法表中的对象引用指向应用程序域的句柄表的对象引用，它引用了堆上创建的对象实例。一旦创建后，句柄表内的对象引用会使堆上的对象实例保持生存，直到应用程序域被卸载。在图9 中，静态字符串变量str指向句柄表的对象引用，后者指向GC堆上的MyString。

EEClass

EEClass在方法表创建前开始生存，它和方法表结合起来，是类型声明的CLR版本。实际上，EEClass和方法表逻辑上是一个数据结构（它们一起表示一个类型），只不过因为使用频度的不同而被分开。经常使用的域放在方法表，而不经常使用的域在EEClass中。这样，需要被JIT编译函数使用的信息（如名字，域和偏移）在EEClass中，但是运行时需要的信息（如虚表槽和GC信息）在方法表中。

对每一个类型会加载一个EEClass到应用程序域中，包括接口，类，抽象类，数组和结构。每个EEClass是一个被执行引擎跟踪的树的节点。CLR使用这个网络在EEClass结构中浏览，其目的包括类加载，方法表布局，类型验证和类型转换。EEClass的子-父关系基于继承层次建立，而父-子关系基于接口层次和类加载顺序的结合。在执行托管代码的过程中，新的EEClass节点被加入，节点的关系被补充，新的关系被建立。在网络中，相邻的EEClass还有一个水平的关系。EEClass有三个域用于管理被加载类型的节点关系：父类（Parent Class），相邻链（sibling chain）和子链（children chain）。关于图4中的MyClass上下文中的EEClass的语义，请参考图13。

图13只显示了和这个讨论相关的一些域。因为我们忽略了布局中的一些域，我们没有在图中确切显示偏移。EEClass有一个间接的对于方法表的引用。EEClass也指向在默认应用程序域的高频堆分配的方法描述块。在方法表创建时，对进程堆上分配的域描述列表的一个引用提供了域的布局信息。EEClass在应用程序域的低频堆分配，这样操作系统可以更好的进行内存分页管理，因此减少了工作集。

图13 EEClass 布局

图13中的其它域在MyClass（图3）的上下文的意义不言自明。我们现在看看使用SOS输出的EEClass的真正的物理内存。在mc.Method1代码行设置断点后，运行图3的程序。首先使用命令Name2EE获得MyClass的EEClass的地址。

!Name2EE C:WorkingtestClrInternalsSample1.exe MyClass

MethodTable: 009552a0
EEClass: 02ca3508
Name: MyClass

Name2EE的第一个参数时模块名，可以从DumpDomain命令得到。现在我们得到了EEClass的地址，我们输出EEClass：

!DumpClass 02ca3508
Class Name : MyClass, mdToken : 02000004, Parent Class : 02c4c3e4
ClassLoader : 00163ad8, Method Table : 009552a0, Vtable Slots : 8
Total Method Slots : a, NumInstanceFields: 0,
NumStaticFields: 2,FieldDesc*: 00955224

      MT    Field   Offset  Type           Attr    Value    Name
009552a0  4000001   2c      CLASS          static 00a8198c  str
009552a0  4000002   30      System.UInt32  static aaaaaaaa  ui

图13和DumpClass的输出看起来完全一样。元数据令牌（metadata token，mdToken）表示了在模块PE文件中映射到内存的元数据表的MyClass索引，父类指向System.Object。从相邻链指向名为Program的EEClass，可以知道图13显示的是加载Program时的结果。

MyClass verfügt über 8 virtuelle Tabellenplätze (Methoden, die virtuell verteilt werden können). Obwohl Methode1 und Methode2 keine virtuellen Methoden sind, können sie als virtuell betrachtet und der Liste hinzugefügt werden, wenn sie über die Schnittstelle gesendet werden. Fügen Sie .cctor und .ctor zur Liste hinzu und Sie erhalten insgesamt 10 Methoden. Als letztes sind die beiden statischen Felder der Klasse aufgeführt. MyClass hat kein Instanzfeld. Die anderen Felder sind selbsterklärend.

Fazit

Unsere Reise zur Erkundung einiger der wichtigsten Interna der CLR ist endlich vorbei. Natürlich gibt es noch viele weitere Themen, die tiefergehend behandelt und besprochen werden müssen, aber wir hoffen, dass dies Ihnen hilft, zu verstehen, wie die Dinge funktionieren. Viele der hier bereitgestellten Informationen können sich in späteren Versionen von .NET Framework und CLR ändern. Obwohl sich die in diesem Artikel erwähnten CLR-Datenstrukturen ändern können, sollten die Konzepte gleich bleiben.

Das obige ist der detaillierte Inhalt vonMöchten Sie verstehen, wie die CLR Laufzeitobjekte erstellt?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!