转 [翻译经典文章]深入.NET Framework内部, 看看CLR如何创建运行时对象的 - 中道学友 - 博客园

原文: Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects

文章讨论了:

SystemDomain, SharedDomain和Default Domain

对象布局和其他的内存细节

方法表布局

方法分派

文章使用的技术:

.NET Framework

因为公共语言运行时(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)中拥有相关实现的类, 你可以从msdn.microsoft.com/net/sscli下载到它们. 图表1 会帮助你在搜索一些结构的时候到SSCLI中的信息.

图表1 SSCLI索引

Item	SSCLI Path
AppDomain	\sscli\clr\src\vm\appdomain.hpp
AppDomainStringLiteralMap	\sscli\clr\src\vm\stringliteralmap.h
BaseDomain	\sscli\clr\src\vm\appdomain.hpp
ClassLoader	\sscli\clr\src\vm\clsload.hpp
EEClass	\sscli\clr\src\vm\class.h
FieldDescs	\sscli\clr\src\vm\field.h
GCHeap	\sscli\clr\src\vm\gc.h
GlobalStringLiteralMap	\sscli\clr\src\vm\stringliteralmap.h
HandleTable	\sscli\clr\src\vm\handletable.h
InterfaceVTableMapMgr	\sscli\clr\src\vm\appdomain.hpp
Large Object Heap	\sscli\clr\src\vm\gc.h
LayoutKind	\sscli\clr\src\bcl\system\runtime\interopservices\layoutkind.cs
LoaderHeaps	\sscli\clr\src\inc\utilcode.h
MethodDescs	\sscli\clr\src\vm\method.hpp
MethodTables	\sscli\clr\src\vm\class.h
OBJECTREF	\sscli\clr\src\vm\typehandle.h
SecurityContext	\sscli\clr\src\vm\security.h
SecurityDescriptor	\sscli\clr\src\vm\security.h
SharedDomain	\sscli\clr\src\vm\appdomain.hpp
StructLayoutAttribute	\sscli\clr\src\bcl\system\runtime\interopservices\attributes.cs
SyncTableEntry	\sscli\clr\src\vm\syncblk.h
System namespace	\sscli\clr\src\bcl\system
SystemDomain	\sscli\clr\src\vm\appdomain.hpp
TypeHandle	\sscli\clr\src\vm\typehandle.h

在我们开始前请注意, 这篇文章提供的信息仅适用于在x86平台架构下的.NET Framework 1.1(有可能多数信息对于Shared Source CLI 1.0中, 一些互操作情形下的多数值得注意的异常来说, 也还是正确的). 对于.NET Framework 2.0来说, 很多信息可能会改变, 所以不要创建依赖于这些内部结构不会改变的软件.

CLR辅助程序创建的域

=================

在CLR执行第一行托管代码之前, 它先创建三个应用程序域. 其中的两个是从托管代码中产生的, 是透明的, 甚至对于CLR宿主来说都是不可见的. 这两个domain只能通过CLR bootstrap进程创建出来, 这个进程受助于两个垫板作用一样的dll文件, mscoree.dll和mscorwks.dll(当是多处理器系统的时候, 为mscorsvr.dll). 在图表2中, 你可以看到System Domain和Shared Domain, 这两个都是Singleton的(只用唯一一个实例). 第三个域是default app domain, 它是一个AppDomain类的实例, 也是唯一命名的domain. 对于简单的CLR宿主程序, 比方说控制台程序, default domain的名字是由可执行镜像的名字组成的. 其他的域可以通过在托管代码中使用AppDomain.CreateDomain方法, 或者在非托管宿主代码中通过调用ICORRuntimeHost接口, 来创建. 类似ASP.NET这样的复杂的宿主, 基于Web Site的数目来创建多个域.

图表2 CLR辅助程序创建的域

系统域-System Domain

===================

系统域负责创建和初始化Shared Domain和default appdomain. 它加载系统库mscorlib.dll到Shared Domain中. 它还显式或隐式的保持着进程范围的字符串的字面值.

保存字符串的字面值(string interning)在.NET Framework 1.1中是一项有点点笨拙的优化特性, 因为CLR并不给assemblies机会来选择是否使用它. 不论如何, 它在所有的应用程序域范围内, 提供给定字符串值的唯一实例(相同值的字符串在内存中只有一份).

系统域还负责生成进程范围的接口ID, 这些接口ID被用来在每一个AppDomain中创建InterfaceVtableMaps. 系统域记录并监控着进程中的所有域, 并实现了加载和卸载AppDomain的功能.

共享域-Shared Domain

===================

所有的域-中立的代码都被加载到shared domain中.

Mscorlib, 这个系统库, 是被所有的appdomain中的用户代码使用和需要的, 它会被自动的加载到SharedDomain中. 像Object, ValueType, Array, Enum, String, 还有Delegate之类的System命名空间中的基础类型, 都会在CLR辅助程序进程(CLR bootstrapping process)中, 被预先加载到SharedDomain里.用户代码(user code)也可以被加载到该域中, 方法是通过在调用CorBindToRuntimeEx方法时, 指定LoaderOptimization属性. LoaderOptimization属性是由CLR宿主应用程序指定的.控制台程序可以给应用程序的main方法编写属性来加载代码到SharedDomain中, 这个属性是System.LoaderOptimizationAttribute.共享域还管理由基地址(the base address)索引的assembly map, assembly map的功能类似于一种查找表, 这个查找表用于明确被加载到Default Domain中的assembly和在其它应用程序域的托管代码中创建的assembly的共享依赖关系.

默认域(Default Domain)是非共享的用户代码加载的地方.

默认域-DefaultDomain

===================

默认域是一个AppDomain的实例, 典型地, 应用程序代码在这个域中执行.

当一些应用程序需要在运行时创建额外的appdomain的时候(比如拥有插件式架构的应用程序, 或者是正在生成相当大量的运行时代码的应用程序), 多数的应用程序会在他们的生命期中创建一个这样的一个域: 所有执行在这个域中的代码都是在域层次上进行了上下文绑定的.

如果一个应用程序有多个appdomain, 那么任何跨domain的访问都要通过.NET Remoting proxies(.net远程代理).

额外的domain内的上下文边界可以通过继承自System.ContextBoundObject的类型来创建.

每一个AppDomain都有自己的SecurityDescriptor, SecurityContext和DefaultContext, 同样的, 还有自己的加载者堆(高频堆, 低频堆, 和Stub堆), 句柄表(句柄表, 大对象堆句柄表), 接口虚表映射管理器(Interface Vtable Map Manager), 和Assembly Cache.

加载者堆-LoaderHeaps

====================

加载者堆是用来加载各种各样的CLR runtime artifacts【译注:artifact这里可以理解为一种structure】和优化artifacts的, 这些artifacts在域的生命期中都存在.

这些堆按照可以预见的大小的块来增长, 从而最小化内存碎片.

加载者堆与GC堆(在对称的多处理器情况下, 是多重堆-multiple heap) 不同, 不同之处在于GC堆保存对象实例,而加载者堆保存的是整个类型系统.

经常访问到的artifact比如MethodTables, MeghodDescs, FieldDescs和InterfaceMaps, 都在高频堆上分配, 而不那么经常访问的数据结构比如说EEClass和ClassLoader还有ClassLoader的查找表, 在低频堆(LowFrequencyHeap)上分配.

StubHeap保存着很多stub, stub可以帮助代码访问security (CAS), COM wrapper calls和P/Invoke.

简单在高层次上过了一遍各种域和加载者堆之后, 我们现在来看一下以一个简单应用程序为上下文背景的, 这些结构的物理细节. 见图表3. 我们将程序的执行中断在了"mc.Method1();", 并且使用SOS debugger extension的DumpDomain命令dump出了域的信息, 这里是编辑过的输出结果:

---------------------------------------------------

!DumpDomainSystem Domain: 793e9d58, LowFrequencyHeap: 793e9dbc, HighFrequencyHeap: 793e9e14, StubHeap: 793e9e6c,Assembly: 0015aa68 [mscorlib], ClassLoader: 0015ab40Shared Domain: 793eb278, LowFrequencyHeap: 793eb2dc,HighFrequencyHeap: 793eb334, StubHeap: 793eb38c,Assembly: 0015aa68 [mscorlib], ClassLoader: 0015ab40Domain 1: 149100, LowFrequencyHeap: 00149164,HighFrequencyHeap: 001491bc, StubHeap: 00149214,Name: Sample1.exe, Assembly: 00164938 [Sample1],ClassLoader: 00164a78 图表3 Sample1.exe

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"的AppDomain中.

Mscorlib.dll被加载到SharedDomain中, 但是它还是被列在SystemDomain中, 因为他是核心的系统库.

每个域中都分配了自己的高频堆,低频堆,和stub堆. 系统域和共享域使用同样的ClassLoader, 而Default AppDomain使用的是它自己的ClassLoader.

输出结果中并没有显示出加载者堆保存的尺寸和已经committed的尺寸. 高频堆初始保留尺寸是32KB, committed的尺寸是4KB. 低频堆和Stub堆初始保留尺寸是8KB, committed的尺寸是4KB.

在SOS输出中同样没有显示出来的是InterfaceVtableMap堆. 每个域都有一个InterfaceVtableMap堆(后面再用的时候就简写为IVMap), 在域初始化阶段它，被创建在自己的加载者堆上. IVMap堆初始保留大小为4KB, 初始committed的大小是4KB. 我们将在接下来的部分中,探索类型布局的时候,讨论IVMap的重要性.

图表2 展示了默认的进程堆, JIT代码堆, GC堆(针对小对象的), 和大对象堆(针对大于等于85000字节的对象的), 通过他们来说明了：这些堆和加载者堆在语义上的不同.

just-in-time(JIT)编译器生成x86指令, 并且把它们存储在JIT代码堆上.

GC堆和大对象堆都是垃圾收集堆, 托管对象是在这些堆上实例化出来的.

类型基础- Type Fundamentals

========================

类型是在.NET编程中的基础单位. 在C#中, 一个类型使用关键字class, struct,和interface来声明. 多数的类型是显示的由程序员来创建的, 然而, 在特殊的互操作情形下, 或者在远程对象激活(.NET remoting)场景中, .NET CLR隐式的生成一些类型. 这些生成的类型包括COM和运行时可调用的包装器, 还有透明的代理.(COM and Runtime Callable Wrappers and Transparent Proxies).

我们接下来探索一下类型基础, 从包含一个对象引用的栈开始.(典型地, 栈是一个对象实例开始他的生命期的位置.) 代码在图表4中, 其中包括一个简单的程序, 有调用静态方法的控制台入口点. Method1创建了一个类型为SmallClass的的实例, SmallClass中包括一个字节数组, 我们通过这个数组来demo在大对象堆上的对象实例的创建. 代码的实用价值不高, 但是足够为我们的讨论服务了.

图表 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;"语句的栈的一个快照(snapshot), 这是一个典型的fastcall的栈框架. (Fastcall是.NET的一种调用约定, 在这种调用约定下, 传递给函数的参数在可能的情况下会通过寄存器来传递, 其他的参数从右至左的压入栈中供函数调用, 函数调用结束后, 由函数自身将栈中的参数清除.)

值类型变量objSize存储在栈框架之内.

类似smallObj的引用类型以一个固定的大小(4字节的双字), 存储在栈中, 双字的内容是在普通GC堆上的对象实例的地址.

在传统C++中, 这是一个对象指针; 在托管世界中, 这是一个对象引用. 不论如何, 它包含对象实例的地址. 我们将会对存储在对象引用的地址中的数据结构使用术语ObjectInstance.

图表5 简单程序的栈框架和堆-SimpleProgram Stack Frame and Heaps

smallObj对象的实例(object instance), 存储在普通GC堆上, 其中包含一个字节数组, 叫做_largeObj, 这个字节数组的大小是85000字节(注意, 图中显示的是85016字节, 这是真实存储的空间大小.)

CLR对待大小<=85000字节的对象, 跟对待比这小的对象的方式不同. 大对象分配在Large Object Heap(LOH)中, 而小对象是创建在普通GC堆上的. 因为普通GC堆对于对象的分配和垃圾收集是有优化的(所以适合存储小对象的效率高). 大对象堆是没有压缩的(夯实的), 而GC堆在GC垃圾收集发生的时候是压缩的. 更重要的是, 大对象堆(LOH)仅在完全垃圾回收的时候才被释放(LOH is only collected on full GC collections).

smallObj的ObjectInstance包含TypeHandle(类型句柄), TypeHandle指向相关连的类型的MethodTable.

任何一个声明了的类型都仅有一个MethodTable, 并且所有同样类型的对象的实例都指向同一份MethodTable.

MethodTable包含

关于这种类型的信息(属于哪一个? interface, abstract class, concrete class, COM Wrapper还是Proxy).

实现了的接口数量

为了方法分配而设立的接口映射表(interface map for the method dispatch)

方法表中的槽的数量(方法表中方法的数量)(number of slots in the method table)

一张满是指向方法的实现的槽的表格

一个由MethodTable指向的重要的数据结构, 是EEClass. 在MethodTable展开之前, CLR类加载器(class loader)从元数据(Metadata)中创建出EEClass. 在图表4中, SmallClass的MethodTable指向它的EEClass. 这些结构指向他们的模块和assembly.

MethodTable和EEClass典型地分配在具体域的加载者堆上. 字节数组(Byte[])是一个特例. 方法表MethodTable和EEClass分配在共享域中的加载者堆上.

加载者堆是appdomain-specific的, 任何这里提到的数据结构（MethodTable和EEClass）一旦加载起来就不会被移除, 除非它的AppDomain被卸载掉.

同样, 默认的appdomain也不能被卸载掉, 因此代码直到CLR关闭都还存在着.

对象实例-ObjectInstance

====================

正如我们提到的, 所有的值类型要么以inline(内联)地存储在线程栈中, 要么内联地存储在GC堆当中. 所有的引用类型都是在GC堆上或者大对象堆创建的. 图表6 显示了一个典型的对象实例的布局.

一个对象可以被以下的结构引用:

1. 基于栈的局部变量;

2. interop或者P/Invoke情形下的句柄表;

3. 寄存器(寄存器中的内容是:执行方法时的this指针或方法参数)

4. 服务于拥有finalizer方法的对象的finalizer queue.

OBJECTREF并不指向Object Instance的首地址, 而是指向一个以DWORD(4个字节)为单位的一个偏移量.

这个DWORD的偏移量叫做Object Header, 并且拥有一个指向SyncTableEntry表的索引值(a 1-based syncblk number). 通过索引的链锁效应, CLR在需要增长内存尺寸的情况下, 可以在内存中自由的移动SyncTableEntry表.

SyncTableEntry中保存着一个指回对象的weak reference, 这样CLR就可以追踪到SyncBlock的所有权(属于哪个对象). Weak Reference可以让GC在没有其他强引用的情况下, 收集到这个对象.

SyncTableEntry中还存着一个指向SyncBlock的指针, SyncBlock中保存着有用的信息, 但是这些信息很少被所有的对象实例使用到. 这些信息包括对象锁(object's lock), 它的Hash Code, 一些转换数据(thunking data), 和它的AppDomain index.

对多数的对象实例来说, 他们当中没有为SyncBlock分配的存储空间, syncblk number是0. 然而,当线程执行遇到例如lock(obj), 或者obj.GetHashCode的时候, 就不同了. 就像下面的代码一样:

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

图表6 对象实例布局-Object Instance Layout

在这段代码中, smallObj会使用0（没有syncblk）做为它起始时的syncblk number. 那句lock语句引发了CLR创建一个syncblk entry的动作, 并用相应的数值来更新对象的object header. 由于C#的lock关键字可以展开为一个try-finally块, 用来使用Monitor类, 所以Monitor对象在为同步化(synchronization)而准备的syncblk中创建出来. 对GetHashCode方法的调用把对象的hash code填入到syncblk中.

SyncBlock中还有些其他的数据域, 它们有的用在COM的interop上, 有的用在针对非托管代码的marshaling delegate上. 但是这些数据域跟典型的对象使用无关.

TypeHandle的位置是紧跟着ObjectInstance中的syncblk number的. 为了保持连续性, 我会在详细阐述变量实例之后, 讨论TypeHandle.

在TypeHandle之后紧跟着一个实例的变量列表域. 默认情况下, 这个实例域会按照能让内存高效使用的方式来压缩, 或者按照能让内存读取高效的对齐来做最小程度的填充. 图表7中的代码显示了一个SimpleClass, 该class拥有很多包含不同大小的变量的实例.

图表7 拥有实例变量的SimpleClass- 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 显示出了SimpleClas对象实例在Visual Studio Debugger内存窗口中的一个例子. 我们在图表7的return语句上下断点, 然后用在寄存器ECX中存储的simpleObj的地址来在内存窗口中显示对象的实例. 头4个字节的块就是syncblk number. 因为我们之前没有在任何synchronizing的代码中使用这个实例, 它被设置为0. 以变量形式存在栈中的的对象引用, 指向偏移量为4的四个字节. 字节变量b1, b2, b3和b4都被一个挨着一个的排放着. 两个short型的变量被放在一起. 字符串型的变量str是一个4字节的OBJECTREF, 指向GC堆中字符串实际存在的地址. 字符串是一种特殊的类型, 在assembly加载的进程中, 它们的所有包含着相同内容的实例, 都会被指向相同的在全局字符串表中的那一份唯一实例. 这个进程叫做string interning, 是用来优化内存的使用的.

如同我们之前提到的, 在.NET Framework1.1中, 一个assbmbly不可能从这个interning process中退出(opt out of), 尽管未来的CLR版本可能会修改这种能力.

图表8 调试器内存窗口中的object instance- Debugger Memory Window for Object Instance

所以, 默认情况下, 在源代码中声明的成员变量的字面顺序, 在内存中并不会被保留下来. 在Interop的场景下, 变量的字面顺序必须被正向的依次放到内存中, StructLayoutAttribute属性可以用来完成这个设定, 该属性接受LayoutKind枚举类型的变量作为参数. LayoutKind.Sequential会为marshaled的数据设定字面的顺序, 尽管在.NET Framework 1.1中,这个设定还不会对托管布局生效.(.NET Framework 2.0就会了). 在interop场景下, 你实在需要额外的填充(padding)和显式的对于数据域顺序的控制时, LayoutKind.Explicit可以和FieldOffset这个修饰符结合起来在field level帮助您达到目的.

看过了原始内存的内容, 让我们用SOS来看一下对象实例吧. 一个有用的命令是DumpHeap, 它可以列出针对某一类型的所有堆中的内容, 还有这一类型的所有实例. 不依赖寄存器, DumpHeap命令可以show出我们创建的唯一实例的地址.

--------------------------------------------------- !DumpHeap -type SimpleClassLoaded Son of Strike data table version 5 from "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll" Address MT Size00a8197c 00955124 36Last good object: 00a819a0total 1 objectsStatistics: MT Count TotalSize Class Name 955124 1 36 SimpleClass

整个对象的大小是36字节. 不论字符串多大, SimpleClass的instance中只包含一个DWORD OBJECTREF. SimpleClass的实例变量只占28个字节. 剩下的八个字节是由TypeHandle(4字节), 和syncblk number(4字节)组成的.

找到了simpleObj实例的地址后, 让我们用DumpObj命令来dump出这个实例吧, 如下:

--------------------------------------------------- !DumpObj 0x00a8197cName: SimpleClassMethodTable 0x00955124EEClass 0x02ca33b0Size 36(0x24) bytesFieldDesc*: 00955064 MT Field Offset Type Attr Value Name00955124 400000a 4 System.Int64 instance 31 l100955124 400000b c CLASS instance 00a819a0 str < some fields omitted from the display for brevity ><00955124 4000003 1e System.Byte instance 3 b300955124 4000004 1f System.Byte instance 4 b4

如上所述, 由C#编译器生成的类的默认布局是LayoutType.Auto. 对于结构体来说是LayoutType.Sequential. 由于class loader重新安排了实例的数据域, 所以填充(padding)的部分达到了最小化. 我们可以用ObjSize命令来dump出实例占用空间的图示. 这里是输出结果:

--------------------------------------------------- !ObjSize 0x00a8197csizeof(00a8197c) = 72 ( 0x48) bytes (SimpleClass)

******************************************************************************************************

posted on 2012-07-13 12:47 衣不如新阅读(280) 评论(0) 收藏举报