原文地址:
原文发布日期: 9/19/2005
原文已经被 Microsoft
删除了,收集过程中发现很多文章图都不全,那是因为原文的图都不全,所以特收集完整全文。

本页内容

目录

目录

  • 前言
  • CLR启动程序(Bootstrap)创建的域
  • 系统域(System
    Domain)
  • 共享域(Shared
    Domain)
  • 默认域(Default
    Domain)
  • 加载器堆(Loader
    Heaps)
  • 类型原理
  • 对象实例
  • 方法表
  • 基实例大小
  • 方法槽表(Method Slot
    Table)
  • 方法描述(MethodDesc)
  • 接口虚表图和接口图(Interface Vtable Map and Interface
    Map)
  • 虚分派(Virtual
    Dispatch)
  • 静态变量(Static
    Variables)
  • EEClass
  • 结论

 

一 加载.NET
程序集

前言

  • SystemDomain, SharedDomain, and DefaultDomain。
  • 对象布局和内存细节。
  • 方法表布局。
  • 方法分派(Method dispatching)。

因为公共语言运行时(CLR)即将成为在Windows上创建应用程序的主角级基础架构,
多掌握点关于CLR的深度认识会帮助你构建高效的, 工业级健壮的应用程序.
在这篇文章中, 我们会浏览,调查CLR的内在本质, 包括对象实例布局,
方法表的布局, 方法分派, 基于接口的分派, 和各种各样的数据结构.

我们会使用由C#写成的非常简单的代码示例,
所以任何对编程语言的隐式引用都是以C#语言为目标的.
讨论的一些数据结构和算法会在Microsoft® .NET Framework 2.0中改变,
但是绝大多数的概念是不会变的. 我们会使用Visual Studio® .NET 2003
Debugger和debugger extension Son of Strike (SOS)来窥视一些数据结构.
SOS能够理解CLR内部的数据结构, 能够dump出有用的信息. 通篇,
我们会讨论在Shared Source CLI(SSCLI)中拥有相关实现的类, 你可以从
下载到它们.

图表1 会帮助你在搜索一些结构的时候到SSCLI中的信息.

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

在我们开始前,请注意:本文提供的信息只对在X86平台上运行的.NET Framework
1.1有效(对于Shared Source CLI
1.0也大部分适用,只是在某些交互操作的情况下必须注意例外),对于.NET
Framework
2.0会有改变,所以请不要在构建软件时依赖于这些内部结构的不变性。

图片 1
CLR启动程序(Bootstrap)创建的域


应用程序域

CLR启动程序(Bootstrap)创建的域

在CLR执行托管代码的第一行代码前,会创建三个应用程序域。其中两个对于托管代码甚至CLR宿主程序(CLR
hosts)都是不可见的。它们只能由CLR启动进程创建,而提供CLR启动进程的是shim——mscoree.dll和mscorwks.dll
(在多处理器系统下是mscorsvr.dll)。正如 图2
所示,这些域是系统域(System Domain)和共享域(Shared
Domain),都是使用了单件(Singleton)模式。第三个域是缺省应用程序域(Default
AppDomain),它是一个AppDomain的实例,也是唯一的有命名的域。对于简单的CLR宿主程序,比如控制台程序,默认的域名由可执行映象文件的名字组成。其它的域可以在托管代码中使用AppDomain.CreateDomain方法创建,或者在非托管的代码中使用ICORRuntimeHost接口创建。复杂的宿主程序,比如
ASP.NET,对于特定的网站会基于应用程序的数目创建多个域。

图 2 由CLR启动程序创建的域 ↓

图片 2

图片 3
系统域(System Domain)


解析类型引用

系统域(System Domain)

系统域负责创建和初始化共享域和默认应用程序域。它将系统库mscorlib.dll载入共享域,并且维护进程范围内部使用的隐含或者显式字符串符号。

字符串驻留(string interning)是 .NET Framework
1.1中的一个优化特性,它的处理方法显得有些笨拙,因为CLR没有给程序集机会选择此特性。尽管如此,由于在所有的应用程序域中对一个特定的符号只保存一个对应的字符串,此特性可以节省内存空间。

系统域还负责产生进程范围的接口ID,并用来创建每个应用程序域的接口虚表映射图(InterfaceVtableMaps)的接口。系统域在进程中保持跟踪所有域,并实现加载和卸载应用程序域的功能。

图片 4
共享域(Shared Domain)


类型

共享域(Shared Domain)

所有不属于任何特定域的代码被加载到系统库SharedDomain.Mscorlib,对于所有应用程序域的用户代码都是必需的。它会被自动加载到共享域中。系统命名空间的基本类型,如Object,
ValueType, Array, Enum, String, and
Delegate等等,在CLR启动程序过程中被预先加载到本域中。用户代码也可以被加载到这个域中,方法是在调用CorBindToRuntimeEx时使用由CLR宿主程序指定的LoaderOptimization特性。控制台程序也可以加载代码到共享域中,方法是使用System.LoaderOptimizationAttribute特性声明Main方法。共享域还管理一个使用基地址作为索引的程序集映射图,此映射图作为管理共享程序集依赖关系的查找表,这些程序集被加载到默认域(DefaultDomain)和其它在托管代码中创建的应用程序域。非共享的用户代码被加载到默认域。

图片 5
默认域(Default Domain)


内存分配

默认域(Default Domain)

默认域是应用程序域(AppDomain)的一个实例,一般的应用程序代码在其中运行。尽管有些应用程序需要在运行时创建额外的应用程序域(比如有些使用插件,plug-in,架构或者进行重要的运行时代码生成工作的应用程序),大部分的应用程序在运行期间只创建一个域。所有在此域运行的代码都是在域层次上有上下文限制。如果一个应用程序有多个应用程序域,任何的域间访问会通过.NET
Remoting代理。额外的域内上下文限制信息可以使用System.ContextBoundObject派生的类型创建。每个应用程序域有自己的安全描述符(SecurityDescriptor),安全上下文(SecurityContext)和默认上下文(DefaultContext),还有自己的加载器堆(高频堆,低频堆和代理堆),句柄表,接口虚表管理器和程序集缓存。

图片 6
加载器堆(Loader Heaps)


类型、对象、线程栈、托管堆在运行时的相互联系

加载器堆(Loader Heaps)

加载器堆的作用是加载不同的运行时CLR部件和优化在域的整个生命期内存在的部件。这些堆的增长基于可预测块,这样可以使碎片最小化。加载器堆不同于垃圾回收堆(或者对称多处理器上的多个堆),垃圾回收堆保存对象实例,而加载器堆同时保存类型系统。经常访问的部件如方法表,方法描述,域描述和接口图,分配在高频堆上,而较少访问的数据结构如EEClass和类加载器及其查找表,分配在低频堆。代理堆保存用于代码访问安全性(code
access security, CAS)的代理部件,如COM封装调用和平台调用(P/Invoke)。

从高层次了解域后,我们准备看看它们在一个简单的应用程序的上下文中的物理细节,见
图3。我们在程序运行时停在mc.Method1(),然后使用SOS调试器扩展命令DumpDomain来输出域的信息。(请查看
Son of
Strike
了解SOS的加载信息)。这里是编辑后的输出:

图3 Sample1.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();
    }
}

我们的控制台程序,Sample1.exe,被加载到一个名为”Sample1.exe”的应用程序域。Mscorlib.dll被加载到共享域,不过因为它是核心系统库,所以也在系统域中列出。每个域会分配一个高频堆,低频堆和代理堆。系统域和共享域使用相同的类加载器,而默认应用程序使用自己的类加载器。

输出没有显示加载器堆的保留尺寸和已提交尺寸。高频堆的初始化大小是32KB,每次提交4KB。SOS的输出也没有显示接口虚表堆(InterfaceVtableMap)。每个域有一个接口虚表堆(简称为IVMap),由自己的加载器堆在域初始化阶段创建。IVMap保留大小是4KB,开始时提交4KB。我们将会在后续部分研究类型布局时讨论IVMap的意义。

图2
显示默认的进程堆,JIT代码堆,GC堆(用于小对象)和大对象堆(用于大小等于或者超过85000字节的对象),它说明了这些堆和加载器堆的语义区别。即时(just-in-time,
JIT)编译器产生x86指令并且保存到JIT代码堆中。GC堆和大对象堆是用于托管对象实例化的垃圾回收堆。

图片 7
类型原理

  本文将解释 PE、Windows
加载器、应用程序域、程序集清单、元数据、类型、对象、线程栈、托管堆等,与运行时的相互关系。因此,我首先写了一个简单
Demo 用于调试,其代码如下:

类型原理

类型是.NET编程中的基本单元。在C#中,类型可以使用class,struct和interface关键字进行声明。大多数类型由程序员显式创建,但是,在特别的交互操作(interop)情形和远程对象调用(.NET
Remoting)场合中,.NET
CLR会隐式的产生类型,这些产生的类型包含COM和运行时可调用封装及传输代理(Runtime
Callable Wrappers and Transparent Proxies)。

我们通过一个包含对象引用的栈开始研究.NET类型原理(典型地,栈是一个对象实例开始生命期的地方)。
图4中显示的代码包含一个简单的程序,它有一个控制台的入口点,调用了一个静态方法。Method1创建一个SmallClass的类型实例,该类型包含一个字节数组,用于演示如何在大对象堆创建对象。尽管这是一段无聊的代码,但是可以帮助我们进行讨论。

图4 Large Objects and Small Objects

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的栈结构和堆

图片 8

一般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关闭为止。

图片 9
对象实例

using System;

namespace CLRTest
{
    public class Circle
    {
        public double Radius { get; set; }

        public Circle() { }

        public Circle(double r)
        {
            this.Radius = r;
        }

        public double GetCircumference()
        {
            return 2 * Math.PI * Radius;
        }

        public double GetArea()
        {
            return Math.PI * Math.Pow(this.Radius, 2.0);
        }

        public override string ToString()
        {
            return string.Format("半径:{0}  周长:{1}  面积:{2}", this.Radius, this.GetCircumference(), this.GetArea());
        }
    }
}

using System;

namespace CLRTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Circle circle = new Circle(4.0);
            Console.WriteLine(circle.ToString());
            Console.ReadKey();
        }
    }
}

对象实例

正如我们说过的,所有值类型的实例或者包含在线程栈上,或者包含在 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 对象实例布局
图片 10

在以上代码中, 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
图片 11

所以默认情况下,成员变量在源代码中的词典顺序没有在内存中保持。在交互操作的情况下,词典顺序必须被保存到内存中,这时可以使用
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更多信息,参考这里。

图片 12
方法表

一 加载.NET 程序集

方法表

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

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

图 9 方法表布局

图片 13

图片 14
基实例大小

  在Windows上运行的程序可以通过多种不同的方式进行启动。Windows
负责处理所有的相关工作,包括设置进程地址空间、加载可执行程序,以及指示处理器开始执行等。当处理器开始执行程序指令时,它将一直执行下去,直到进程退出。

基实例大小

基实例大小是由类加载器计算的对象的大小,基于代码中声明的域。之前已经讨论过,当前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

图片 15
方法槽表(Method Slot Table)

  现在扩充我们对 PE 文件的认识,PE
格式是 Windows
可执行程序的文件格式,可执行程序包括:*.exe、*.dll、*.obj、*.sys
等。为了支持.NET,在 PE
文件格式中增加了对程序集的支持,PE文件格式如下:

方法槽表(Method Slot Table)

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

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

图10 MyClass MethodTable Layout
图片 16

图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会分别和静态方法和实例方法分在一组。

图片 17
方法描述(MethodDesc)

图片 18

方法描述(MethodDesc)

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

图 12方法描述

图片 19

图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实现。让我们看方法表另外一个复杂的方面:接口实现。它封装了布局过程所有的复杂性,让托管环境觉得这一点看起来简单。然后,我们将说明接口如何进行布局和基于接口的方法分派的确切工作方式。

图片 20
接口虚表图和接口图

  为了支持PE映像的执行,在PE的头包含了一个域叫做
AddressOfEntryPoint。这个域表示 PE
文件的入口点(EntryPoint)的位置。在.NET程序集中,这个值指向.text
段中的一小段存根(stub)代码(“JMP _CorExeMain”)。当.NET
编译器生成程序集时,它会在 PE
文件中增加一个数据目录项。具体来说,这个数据目录项的索引为
15,其中包含了 CLR 头的位置和大小。然后,根据这个位置在 PE
文件中找到位于.text 段中的 CLR 头。在 CLR 头中包含了一个结构
IMAGE_COR20_HEADER。在这个结构中包含了许多信息,例如托管代码应用程序入口点,目标
CLR
的主版本号和从版本号,以及程序集的强名称签名等。根据这个结构中包含的信息,Windows
可以知道要加载哪个版本的 CLR 以及关于程序集本身的一些信息。在.text
段中还包含了程序集的元数据表,IL以及非托管启动存根码。非托管启动存根码包含了由
Windows 加载器执行以启动 PE 文件执行的代码。

接口虚表图和接口图(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。

图片 21
虚分派(Virtual Dispatch)

  当 Windows 加载一个.NET
程序集时,mscoree.dll
的_CorExeMain(或者是_CorDllMain,取决于加载的是可执行文件还是库)
函数被第一个调用,以启动 CLR。 mscoree.dll 在启动 CLR
时将执行一系列操作:

虚分派(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的输出看到这一点。

图片 22
静态变量

  (1) 通过查看 PE
文件中的元数据(具体来说是 CLR 头中的 MajorRuntimeVersion 和
MinorRuntimeVersion)找出.NET 程序集是基于哪个版本的 CLR 构建的。

静态变量(Static Variables)

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

图片 23
EEClass

  (2) 找出 OS 中正确版本 CLR
的路径。

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 布局

图片 24

图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有8个虚表槽(可以被虚分派的方法)。即使Method1和Method2不是虚方法,它们可以在通过接口进行分派时被认为是虚函数并加入到列表中。把.cctor和.ctor加入到列表中,你会得到总共10个方法。最后列出的是类的两个静态域。MyClass没有实例域。其它域不言自明。

图片 25
Conclusion结论

  (3) 加载并初始化 CLR。

结论

我们关于CLR一些最重要的内在的探索旅程终于结束了。显然,还有许多问题需要涉及,而且需要在更深的层次上讨论,但是我们希望这可以帮助你看到事物如何工作。这里提供的许多的信息可能会在.NET框架和CLR的后来版本中改变,不过尽管本文提到的CLR数据结构可能改变,概念应该保持不变。

随着通用语言运行时(CLR)即将成为在Windows®下开发应用程序的首选架构,对其进行深入理解会帮助你建立有效的工业强度的应用程序。在本文中,我们将探索CLR内部,包括对象实例布局,方法表布局,方法分派,基于接口的分派和不同的数据结构。

  在 CLR 被初始化之后,在 PE 文件的 CLR
头中就可以找到程序集的入口点(Main())。然后,JIT
开始编译并执行入口点。

我们将使用C#编写的简单代码示例,以便任何固有的语言语法含义是C#的缺省定义。某些此处讨论的数据结构和算法可能会在Microsoft®
.NET Framework 2.0中改变,但是主要概念应该保持不变。我们使用Visual
Studio® .NET 2003调试器和调试器扩展Son of Strike
(SOS)来查看本文讨论的数据结构。SOS理解CLR的内部数据结构并输出有用信息。请参考“Son
of Strike”补充资料,了解如何将SOS.dll装入Visual Studio .NET
2003调试器的进程空间。本文中,我们将描述在共享源代码CLI(Shared Source
CLI,SSCLI)中有相应实现的类,你可以从msdn.microsoft.com/net/sscli下载。图1将帮助你在SSCLI的数以兆计的代码中找到所参考的结构。

  综上所述,.NET
程序集的加载步骤如下:

在我们开始前,请注意:本文提供的信息只对在X86平台上运行的.NET Framework
1.1有效(对于Shared Source CLI
1.0也大部分适用,只是在某些交互操作的情况下必须注意例外),对于.NET
Framework
2.0会有改变,所以请不要在构建软件时依赖于这些内部结构的不变性。

  (1) 执行一个 .NET 程序集。

CLR启动程序(Bootstrap)创建的域

在CLR执行托管代码的第一行代码前,会创建三个应用程序域。其中两个对于托管代码甚至CLR宿主程序(CLR
hosts)都是不可见的。它们只能由CLR启动进程创建,而提供CLR启动进程的是shim——mscoree.dll和mscorwks.dll
(在多处理器系统下是mscorsvr.dll)。正如图2所示,这些域是系统域(System
Domain)和共享域(Shared
Domain),都是使用了单件(Singleton)模式。第三个域是缺省应用程序域(Default
AppDomain),它是一个AppDomain的实例,也是唯一的有命名的域。对于简单的CLR宿主程序,比如控制台程序,默认的域名由可执行映象文件的名字组成。其它的域可以在托管代码中使用AppDomain.CreateDomain方法创建,或者在非托管的代码中使用ICORRuntimeHost接口创建。复杂的宿主程序,比如ASP.NET,对于特定的网站会基于应用程序的数目创建多个域。

图片 26

2 由CLR启动程序创建的域

图片 27返回页首

  (2) Windows
加载器查看 AddressOfEntryPoint 域,并找到 PE 文件中的.text 段。

系统域(System Domain)

系统域负责创建和初始化共享域和默认应用程序域。它将系统库mscorlib.dll载入共享域,并且维护进程范围内部使用的隐含或者显式字符串符号。

字符串驻留(string interning)是.NET Framework
1.1中的一个优化特性,它的处理方法显得有些笨拙,因为CLR没有给程序集机会选择此特性。尽管如此,由于在所有的应用程序域中对一个特定的符号只保存一个对应的字符串,此特性可以节省内存空间。

系统域还负责产生进程范围的接口ID,并用来创建每个应用程序域的接口虚表映射图(InterfaceVtableMaps)的接口。系统域在进程中保持跟踪所有域,并实现加载和卸载应用程序域的功能。

图片 28返回页首

  (3) 位于 AddressOfEntryPoint
位置上的字节是一个 JMP 指令,用于跳转到
mscoree.dll 中的一个导入函数。

共享域(Shared Domain)

所有不属于任何特定域的代码被加载到系统库SharedDomain.Mscorlib,对于所有应用程序域的用户代码都是必需的。它会被自动加载到共享域中。系统命名空间的基本类型,如Object,
ValueType, Array, Enum, String, and
Delegate等等,在CLR启动程序过程中被预先加载到本域中。用户代码也可以被加载到这个域中,方法是在调用CorBindToRuntimeEx时使用由CLR宿主程序指定的LoaderOptimization特性。控制台程序也可以加载代码到共享域中,方法是使用System.LoaderOptimizationAttribute特性声明Main方法。共享域还管理一个使用基地址作为索引的程序集映射图,此映射图作为管理共享程序集依赖关系的查找表,这些程序集被加载到默认域(DefaultDomain)和其它在托管代码中创建的应用程序域。非共享的用户代码被加载到默认域。

图片 29返回页首

  (4) 将执行控制转移到
mscoree.dll 中的函数 _CorExeMain 中,这个函数将启动 CLR
并把执行控制转移到程序集的入口点。

默认域(Default Domain)

默认域是应用程序域(AppDomain)的一个实例,一般的应用程序代码在其中运行。尽管有些应用程序需要在运行时创建额外的应用程序域(比如有些使用插件,plug-in,架构或者进行重要的运行时代码生成工作的应用程序),大部分的应用程序在运行期间只创建一个域。所有在此域运行的代码都是在域层次上有上下文限制。如果一个应用程序有多个应用程序域,任何的域间访问会通过.NET
Remoting代理。额外的域内上下文限制信息可以使用System.ContextBoundObject派生的类型创建。每个应用程序域有自己的安全描述符(SecurityDescriptor),安全上下文(SecurityContext)和默认上下文(DefaultContext),还有自己的加载器堆(高频堆,低频堆和代理堆),句柄表,接口虚表管理器和程序集缓存。

图片 30返回页首

   注意,在 Windows XP
及以后版本中,对加载器进行了优化,使其能够识别出一个 PE 文件,是否是.NET
程序集。这样,在加载一个.NET 程序集时,就不再需要通过存根函数调用
mscoree.dll的导入函数了,而是变为自动加载 CLR。

加载器堆(Loader Heaps)

加载器堆的作用是加载不同的运行时CLR部件和优化在域的整个生命期内存在的部件。这些堆的增长基于可预测块,这样可以使碎片最小化。加载器堆不同于垃圾回收堆(或者对称多处理器上的多个堆),垃圾回收堆保存对象实例,而加载器堆同时保存类型系统。经常访问的部件如方法表,方法描述,域描述和接口图,分配在高频堆上,而较少访问的数据结构如EEClass和类加载器及其查找表,分配在低频堆。代理堆保存用于代码访问安全性(code
access security, CAS)的代理部件,如COM封装调用和平台调用(P/Invoke)。

从高层次了解域后,我们准备看看它们在一个简单的应用程序的上下文中的物理细节,见图3。我们在程序运行时停在mc.Method1(),然后使用SOS调试器扩展命令DumpDomain来输出域的信息。(请查看Son
of
Strike
了解SOS的加载信息)。这里是编辑后的输出:

!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

我们的控制台程序,Sample1.exe,被加载到一个名为“Sample1.exe”的应用程序域。Mscorlib.dll被加载到共享域,不过因为它是核心系统库,所以也在系统域中列出。每个域会分配一个高频堆,低频堆和代理堆。系统域和共享域使用相同的类加载器,而默认应用程序使用自己的类加载器。

输出没有显示加载器堆的保留尺寸和已提交尺寸。高频堆的初始化大小是32KB,每次提交4KB。SOS的输出也没有显示接口虚表堆(InterfaceVtableMap)。每个域有一个接口虚表堆(简称为IVMap),由自己的加载器堆在域初始化阶段创建。IVMap保留大小是4KB,开始时提交4KB。我们将会在后续部分研究类型布局时讨论IVMap的意义。

图2显示默认的进程堆,JIT代码堆,GC堆(用于小对象)和大对象堆(用于大小等于或者超过85000字节的对象),它说明了这些堆和加载器堆的语义区别。即时(just-in-time,
JIT)编译器产生x86指令并且保存到JIT代码堆中。GC堆和大对象堆是用于托管对象实例化的垃圾回收堆。

图片 31返回页首

二 应用程序域

类型原理

类型是.NET编程中的基本单元。在C#中,类型可以使用class,struct和interface关键字进行声明。大多数类型由程序员显式创建,但是,在特别的交互操作(interop)情形和远程对象调用(.NET
Remoting)场合中,.NET
CLR会隐式的产生类型,这些产生的类型包含COM和运行时可调用封装及传输代理(Runtime
Callable Wrappers and Transparent Proxies)。

我们通过一个包含对象引用的栈开始研究.NET类型原理(典型地,栈是一个对象实例开始生命期的地方)。图4中显示的代码包含一个简单的程序,它有一个控制台的入口点,调用了一个静态方法。Method1创建一个SmallClass的类型实例,该类型包含一个字节数组,用于演示如何在大对象堆创建对象。尽管这是一段无聊的代码,但是可以帮助我们进行讨论。

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

图片 32

图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关闭为止。

图片 33返回页首

  Windows 使用进程来隔离应用程序,.NET
在此基础上进一步引人了另一种逻辑隔离层,即应用程序域。构造和管理进程的开销是非常高的,应用程序域极大地降低在创建与销毁隔离层时所需的开销。

对象实例

正如我们说过的,所有值类型的实例或者包含在线程栈上,或者包含在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();

在以上代码中,smallObj会使用0作为它的起始的syncblk编号。lock语句使得CLR创建一个syncblk入口并使用相应的数值更新对象头。因为C#的lock关键字会扩展为try-finally语句并使用Monitor类,一个用作同步的Monitor对象在syncblk上创建。堆GetHashCode的调用会使用对象的哈希编码增加syncblk。

在SyncBlock中有其它的域,它们在COM交互操作和封送委托(marshaling
delegates)到非托管代码时使用,不过这和典型的对象用处无关。

类型句柄紧跟在对象实例中的syncblk编号后。为了保持连续性,我会在说明实例变量后讨论类型句柄。实例域(Instance
field)的变量列表紧跟在类型句柄后。默认情况下,实例域会以内存最有效使用的方式排列,这样只需要最少的用作对齐的填充字节。图7的代码显示了SimpleClass包含有一些不同大小的实例变量。

图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可能会提供这样的能力。

所以默认情况下,成员变量在源代码中的词典顺序没有在内存中保持。在交互操作的情况下,词典顺序必须被保存到内存中,这时可以使用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:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.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在需要史可以通过方法表反向访问加载类型时使用类型句柄。

图片 34返回页首

  进程与应用程序域的关系如下:

方法表

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

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

图片 35返回页首

图片 36

基实例大小

基实例大小是由类加载器计算的对象的大小,基于代码中声明的域。之前已经讨论过,当前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

图片 37返回页首

  在任何启动了 CLR 的 Windows
进程中都会定义一个或多个应用程序域,在这些域中包含了可执行代码、数据、元数据结构以及资源等。除了进程本身的保护机制外,应用程序域还进一步引人了以下保护机制:

方法槽表(Method Slot Table)

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

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

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

图片 38返回页首

  • 一个应用程序域中的错误代码不会影响到同一个进程中另一个应用程序域中运行的代码。
  • 一个应用程序域中的代码不能直接访问另一个应用程序域中的资源。
  • 每个应用程序域中都可以配置与代码特定的信息,如安全设置。

方法描述(MethodDesc)

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

图片 39

图12 方法描述

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

!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实现。让我们看方法表另外一个复杂的方面:接口实现。它封装了布局过程所有的复杂性,让托管环境觉得这一点看起来简单。然后,我们将说明接口如何进行布局和基于接口的方法分派的确切工作方式。

图片 40返回页首

  对于没有显式创建应用程序域的应用程序来说,CLR
会创建三个应用程序域:系统应用程序域、共享应用程序域、默认应用程序域。

接口虚表图和接口图

在方法表的第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。

图片 41返回页首

(一) 系统应用程序域

虚分派(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的输出看到这一点。

图片 42返回页首

  系统应用程序域主要功能如下:

静态变量

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

图片 43返回页首

  • 创建其它两个应用程序域(共享应用程序域、默认应用程序域)。

  • mscoree.dll加载到共享应用程序域中。
  • 记录进程中所有其它的应用程序域,包括提供加载、卸载应用程序域等功能。
  • 记录字符串池中的字符串常量,因此允许任意字符串在每个进程中都存在一个副本。
  • 初始化特定类型的异常。

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在应用程序域的低频堆分配,这样操作系统可以更好的进行内存分页管理,因此减少了工作集。

图片 44

图13 EEClass 布局

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

!Name2EE C:\Working\test\ClrInternals\Sample1.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有8个虚表槽(可以被虚分派的方法)。即使Method1和Method2不是虚方法,它们可以在通过接口进行分派时被认为是虚函数并加入到列表中。把.cctor和.ctor加入到列表中,你会得到总共10个方法。最后列出的是类的两个静态域。MyClass没有实例域。其它域不言自明。

图片 45返回页首

(二) 共享应用程序域

Conclusion结论

我们关于CLR一些最重要的内在的探索旅程终于结束了。显然,还有许多问题需要涉及,而且需要在更深的层次上讨论,但是我们希望这可以帮助你看到事物如何工作。这里提供的许多的信息可能会在.NET框架和CLR的后来版本中改变,不过尽管本文提到的CLR数据结构可能改变,概念应该保持不变。

Hanu Kommalapati是微软Gulf
Coast区(休斯顿)的一名架构师。他在微软现在的角色是帮助客户基于.NET框架建立可扩展的组件框架。可以通过hanuk@microsoft.com联系他。

Tom
Christian
是微软开发支持高级工程师,使用ASP.NET和用于WinDBG的.NET调试器扩展(sos/
psscor)。他在北卡罗来州的夏洛特,可以通过tomchris@microsoft.com联系他。

翻译者Luke是微软公司的软件工程师,习惯使用C++和C#开发应用程序。闲暇时间他喜欢音乐,旅游和怀旧游戏,并且愿意帮助MSDN翻译更多的文章和其他开发者共享。可以通过ecaijw@msn.com联系他。

  在共享应用程序域中包含的是与应用程序域无关的代码。mscoree.dll
将被加载到这个应用程序域中,此外还包括在 System
命名空间中的一些基本类型(eg.String、Array等)。在大多数情况下,非用户代码将被加载到共享应用程序域中。启用了
CLR 的应用程序域可以通过加载器的优化属性来注入用户代码。

(三) 默认应用程序域

  通常,.NET
程序在默认应用程序域中运行。位于默认应用程序域中的所有代码都只有在这个域中才是有效的。由于应用程序域实现了一种逻辑并且可靠的边界,因此任何跨越应用程序域的访问操作都必须通过.NET
远程对象来进行。

  下图显示了本文开头创建的 Demo
的应用程序域信息:

图片 46

三 解析类型引用

  运行应用程序时,CLR
会加载并初始化它。然后 CLR 读取程序集的 CLR
头,查找标识了应用程序入口的方法(Main())的 MethodDefToken。然后,CLR
会搜索 MethodDef 元数据表,找到该方法的 IL 代码在文件中的偏移量,把这些
IL 代码 JIT
编译为本地代码。编译时会对代码进行验证以确保类型安全性。最后,将执行本地代码。在
JIT 编译时,CLR
会检查对类型和成员的所有引用,并加载定义了它们的程序集(如果尚未加载),CLR
必须定位并加载程序集。解析一个引用的类型时,CLR
可能在以下三个地方找到类型:

  • 同一个文件 
  • 不同文件,相同程序集
  • 不同文件,不同程序集

  解析一个类型引用时如果发送任何错误,如找不到文件、文件无法加载、哈希值不匹配等,就会抛出异常。下图演示了类型绑定的过程:

图片 47

  (注意 ModuleDef、ModuleRef、FileDef
元数据表使用文件名及其扩展名来引用文件。而 AssemblyRef
元数据表使用不带扩展名的文件名来引用程序集。要和一个程序集绑定时,系统通过探测目录尝试定位文件。)

  对于 CLR
来说,所有程序集都是根据名称、版本、语言文化、公钥来标识的。但是,GAC
根据名称、版本、语言文化、公钥和 CPU 架构来标识程序集。在 GAC
中搜索程序集时,CLR
判断应用程当前在什么类型的进程中运行(32位、64位)。然后,CLR
首先搜索程序集的这种 CPU 架构专用版本,如果没有找到,就搜索不区分 CPU
的版本。

四 类型

  类型是.NET
程序中的基本编程单元。在.NET
应用程序中,要么使用自定义的类型,要么使用现有的类型。类型分为两类:值类型和引用类型。值类型是指保存在线程栈上的类型,包括:枚举、结构以及简单类型(如
int、bool、char等)。通常,值类型是一些占据内存空间较小的类型。另一种类型叫做引用类型,它是在堆上分配的,并由垃圾回收器(GC)负责管理。在引用类型中也可以包含值类型,在这种情况下,值类型将同样位于堆上并且由垃圾收集器来管理。

  托管堆上对象的结构如下:

图片 48

  在托管堆上的每个对象实例中都包含了以下信息:

  • 同步块(sync
    block):同步块可以是一个位掩码,也可以是由 CLR
    维持的同步块表中的索引,其中包含了关于对象本身的辅助信息。
  • 类型句柄(type handle):类型句柄是
    CLR
    类型系统的基础单元,可以用来对托管堆上的类型进行完整描述。
  • 对象实例:在同步块索引和类型句柄之后紧接着是实际的对象数据。

  下图显示了 Demo 的 Circle
对象的内容:

图片 49

(一) 同步块表

   在托管堆上每个对象的前面都有一个同步块索引,它指向
CLR
中私有堆上的同步块表。在同步块表中包含的是指向各个同步块的指针,在同步块中包含了许多信息,如对象的锁、互用性数据、应用程序域索引、对象的散列码(hash
code)等。当然,在对象中也可能不包含任何同步块数据,此时的同步块索引值为0。需要注意的是,在同步块中并不一定只包含简单的索引,也可以包含对象的其它辅助信息。

  (在使用索引时要注意,CLR
可以自由移动/增长同步块表,同时却不一定对所有包含同步块的对象头进行调整。)

(二) 类型句柄

  引用类型的所有实例都被放在托管堆上,这个堆是由
GC
来控制。在所有的实例中都包含了一个类型句柄。简单地说,类型句柄指向的是某个类型的方法表。在方法表中包含了各种元数据,它们完整地描述了这个类型。下图说明了方法表的整体内存布局:

图片 50

  类型句柄是 CLR
类型系统中的粘合剂,它把对象实例及其所有的相关类型数据关联起来。对象实例的类型句柄存储在托管堆上,它是一个指针,指向类型的方法表。在方法表中包含了关于对象类型的大量信息,包括指向其它关键
CLR 数据结构(如
EEClass)的指针。在类型句柄指向的第一类数据中包含了关于类型本身的一些信息(如标志、大小、方法数量、父方法表等)。下一个要注意的域是一个指针,指向一个
EEClass。方法表的下一部分也是一个指针,指向与类型相关的模块信息。在剩余的域中包含了类型的虚方法表。需要注意的是,在方法表中的一些方法指针可能会指向非托管代码。出现这种情况的原因是,一些方法可能还没有被
JIT 编译器编译。事实上,启动编译过程的 JIT
存根代码是一段非托管代码,当方法没有被 JIT
编译器编译时,它会指向这段非托管代码,在编译之后会把执行控制权转移到新编译生成的代码。

(三) 方法描述符

  在方法表中包含了虚方法表,里面包含了一些指向隐藏在类型方法背后的代码的指针。虚方法表中包含了指向代码的指针,这些方法本身可以自行描述,这都归功于方法描述符。在方法描述符中包含了关于方法的详细信息,如方法的文本表示、它所在的模块、标记以及实现方法的代码地址。

  下图显示了 Demo 的 Circle
对象的方法表及方法描述符:

图片 51

  查看 GetCircumference 方法的
IL:

图片 52

  进一步获取方法的信息:

图片 53

(四) 模块

  查看类型 Circle
所在模块的信息:

图片 54

(五) 元数据标记

  CLR
的元数据以表格的形式存储在运行时引擎中,元数据标记是一个4字节的值,其布局如下:

图片 55

  查看 Circle
的方法表可以看到元数据标记:

图片 56

  值为 02000004
的元数据标记可以解释为:指向类型定义表中的第4个索引。

(六)EEClass

  EEClass
数据结构可以看成是方法表的一个逻辑等价物,因此它可以作为实现 CLR
类型系统自描述性的一种机制。本质上,EEClass
和方法表是两种截然不同的结构,但从逻辑来看,它们都表示相同的概念。之所以分成这两种数据结构,是因为
CLR
使用类型域的频繁程度不同。频繁使用的域被保存到方法表中,而不频繁使用的域被保存到
EEClass 中。EEClass 的大体结构如下:

图片 57

  C# 中的层次结构在 EEClass
中同样适用。当 CLR 加载类型时,会创建一个类型的 EEClass
节点层次结构,其中包含了指向父节点和兄弟节点的指针,这样就可以遍历整个层次结构。EEClass
中的方法描述块域,包含了一个指针,指向类型中的第一组方法描述符,这样就能遍历任意类型中的方法描述符。在每组方法描述符中又包含指向链表中下一组方法描述符的指针。

  查看 Circle 的 EEClass:

图片 58

五 内存分配

  CLR管理的内存主要分为3部分,如下:

  • 线程栈
    用于分配值类型实例。线程栈主要由操作系统管理,而不受垃圾收集器的控制,当值类型实例所在方法结束时,其存储单位自动释放。栈的执行效率高,但存储容量有限。
  • 小型对象堆(SOH) 用于分配小对象实例。如果引用类型对象的实例大小小于85000字节,实例将被分配在SOH堆上,当有内存分配或者回收时,垃圾收集器可能会对SOH堆进行压缩。
  • 大型对象堆(LOH) 用于分配大对象实例。如果引用类型对象的实例大小不小于85000字节时,该实例将被分配到LOH堆上,不同于SOH堆,垃圾收集器不会对LOH堆进行压缩。


类型、对象、线程栈、托管堆在运行时的相互联系

  运行 Demo
时,会启动一个进程,因为程序本身是单线程的所有只有一个线程。一个线程被创建时会分配到
1MB
大小的栈。这个栈的空间用于向方法传递实参,并用于方法内部定义的局部变量。

  现在,Windows 进程已经启动,CLR
已经加载到其中,托管堆已初始化,而且已创建一个线程(连同它的 1MB
栈空间)。现在已经进入 Main() 方法,马上就要执行 Main
中的语句,所以栈和堆的状态如下图所示(为了简化示意图,我只画出了自定义的类型):

图片 59

  当 JIT 编译器将 Main() 方法的 IL
代码转换成本地 CPU 指令时,会注意到其内部引用的所有类型。这个时候,CLR
要确保定义了这些类型的所有程序集都已加载。然后利用程序集的元数据,CLR
提取与这些类型有关的信息,并创建一些数据结构来表示类型本身。在线程执行本地代码前,会创建所需的所有对象。下图显示了在
Main 被调用时,创建类型对象后的状态:

图片 60

  当 CLR
确定方法需要的所有类型对象都已创建,而且 Main
的代码已经编译之后,就允许线程开始执行编译好的本地代码。首先执行的是
“Circle circle = new Circle(4.0);”,这会创建一个 Circle
类型的局部变量,并为其赋值。当调用构造函数时,会在托管堆中创建 Circle
的实例。任何时候在堆上新建一个对象 CLR
都会自动初始化内部类型对象指针成员,将它引用与对象对应的类型对象。此外,CLR
会先初始化同步块索引,将对象的所有实例字段设置为 null 或
0,再调用类型的构造器。new 操作符会返回 Circle
对象的内存地址,该地址将保存在局部变量 circle
中(在线程栈上)。此时的状态如下图:

图片 61

  接着执行“Console.WriteLine(circle.ToString());”。ToString()
方法是一个虚方法,在调用虚方法时,JIT
编译器要在方法中生成一些额外的代码,方法每次调用时都会执行这些代码。这些代码首先检查发出调用的变量,然后跟随地址来到发生调用的对象。在本例中,变量
circle 引用的是 Circle
类型的一个对象。然后,代码检查对象内部的“类型句柄”成员,这个成员指向对象的实际类型。然后,代码在类型对象的方法表中查找引用了被调用方法的记录项,对方法进行
JIT 编译(如果需要),再调用 JIT 编译过的代码。就本例来说,调用的是
Circle 类型的 ToString 实现。(在调用非虚方法时,JIT
编译器会找到调用对象的类型对应的类型对象。如果该类型没有定义那个方法,JIT
编译器就会回溯类层次结构,一直回溯到
Object,并在沿途的每个类型中查找该方法。)

  WriteLine(string)
是静态方法。调用一个静态方法时,CLR
会定位与静态方法的类型对应的类型对象。然后,JIT
编译器在类型对象的方法表中查找与被调用的方法对应的记录项,对方法进行 JIT
编译(如果需要),再调用 JIT
编译的代码。综上所述,“Console.WriteLine(circle.ToString());”的操作结果如下图所示:

图片 62

  最后,执行“Console.ReadKey();”,与WriteLine(string)
类似,这里就不再赘述。我们可以看到,Circle
类型对象也包含“类型句柄”成员。这是因为类型对象本质上也是对象。CLR
创建类型对象时,必须初始化这些成员。CLR
 开始在一个进程中运行时,会立即为 mscorlib.dll 中定义的 System.Type
类型创建一个特殊的类型对象。Circle
类型对象是该类型的实例。因此,在初始化时,Circle
类型对象的类型句柄会初始化为对 System.Type
类型对象的引用。如下图所示:

图片 63

  System.Type
类型对象本身也是一个对象,内部的类型句柄指向它本身。System.Object 的
GetType 方法返回的是存储在指定对象的类型句柄(是一个指针)。

相关文章