网站编译成dll,网站设置主网,小企业网站源码,电子商务网站建设评估的指标有哪些?前言
SystemDomain, SharedDomain, and DefaultDomain。对象布局和内存细节。方法表布局。方法分派#xff08;Method dispatching#xff09;。
因为公共语言运行时(CLR)即将成为在Windows上创建应用程序的主角级基础架构, 多掌握点关于CLR的深度认识会帮助你构建高效的, …前言
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)中拥有相关实现的类, 你可以从 http://msdn.microsoft.com/net/sscli 下载到它们.
图表1 会帮助你在搜索一些结构的时候到SSCLI中的信息.
ITEMSSCLI PATHAppDomainsscliclrsrcvmappdomain.hppAppDomainStringLiteralMapsscliclrsrcvmstringliteralmap.hBaseDomainsscliclrsrcvmappdomain.hppClassLoadersscliclrsrcvmclsload.hppEEClasssscliclrsrcvmclass.hFieldDescssscliclrsrcvmfield.hGCHeapsscliclrsrcvmgc.hGlobalStringLiteralMapsscliclrsrcvmstringliteralmap.hHandleTablesscliclrsrcvmhandletable.hInterfaceVTableMapMgrsscliclrsrcvmappdomain.hppLarge Object Heapsscliclrsrcvmgc.hLayoutKindsscliclrsrcbclsystemruntimeinteropserviceslayoutkind.csLoaderHeapssscliclrsrcincutilcode.hMethodDescssscliclrsrcvmmethod.hppMethodTablessscliclrsrcvmclass.hOBJECTREFsscliclrsrcvmtypehandle.hSecurityContextsscliclrsrcvmsecurity.hSecurityDescriptorsscliclrsrcvmsecurity.hSharedDomainsscliclrsrcvmappdomain.hppStructLayoutAttributesscliclrsrcbclsystemruntimeinteropservicesattributes.csSyncTableEntrysscliclrsrcvmsyncblk.hSystem namespacesscliclrsrcbclsystemSystemDomainsscliclrsrcvmappdomain.hppTypeHandlesscliclrsrcvmtypehandle.h
在我们开始前请注意本文提供的信息只对在X86平台上运行的.NET Framework 1.1有效对于Shared Source CLI 1.0也大部分适用只是在某些交互操作的情况下必须注意例外对于.NET Framework 2.0会有改变所以请不要在构建软件时依赖于这些内部结构的不变性。
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启动程序创建的域 ↓ 系统域System Domain
系统域负责创建和初始化共享域和默认应用程序域。它将系统库mscorlib.dll载入共享域并且维护进程范围内部使用的隐含或者显式字符串符号。
字符串驻留string interning是 .NET Framework 1.1中的一个优化特性它的处理方法显得有些笨拙因为CLR没有给程序集机会选择此特性。尽管如此由于在所有的应用程序域中对一个特定的符号只保存一个对应的字符串此特性可以节省内存空间。
系统域还负责产生进程范围的接口ID并用来创建每个应用程序域的接口虚表映射图InterfaceVtableMaps的接口。系统域在进程中保持跟踪所有域并实现加载和卸载应用程序域的功能。
共享域Shared Domain
所有不属于任何特定域的代码被加载到系统库SharedDomain.Mscorlib对于所有应用程序域的用户代码都是必需的。它会被自动加载到共享域中。系统命名空间的基本类型如Object, ValueType, Array, Enum, String, and Delegate等等在CLR启动程序过程中被预先加载到本域中。用户代码也可以被加载到这个域中方法是在调用CorBindToRuntimeEx时使用由CLR宿主程序指定的LoaderOptimization特性。控制台程序也可以加载代码到共享域中方法是使用System.LoaderOptimizationAttribute特性声明Main方法。共享域还管理一个使用基地址作为索引的程序集映射图此映射图作为管理共享程序集依赖关系的查找表这些程序集被加载到默认域DefaultDomain和其它在托管代码中创建的应用程序域。非共享的用户代码被加载到默认域。
默认域Default Domain
默认域是应用程序域AppDomain的一个实例一般的应用程序代码在其中运行。尽管有些应用程序需要在运行时创建额外的应用程序域比如有些使用插件plug-in架构或者进行重要的运行时代码生成工作的应用程序大部分的应用程序在运行期间只创建一个域。所有在此域运行的代码都是在域层次上有上下文限制。如果一个应用程序有多个应用程序域任何的域间访问会通过.NET Remoting代理。额外的域内上下文限制信息可以使用System.ContextBoundObject派生的类型创建。每个应用程序域有自己的安全描述符SecurityDescriptor安全上下文SecurityContext和默认上下文DefaultContext还有自己的加载器堆高频堆低频堆和代理堆句柄表接口虚表管理器和程序集缓存。
加载器堆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堆和大对象堆是用于托管对象实例化的垃圾回收堆。
类型原理
类型是.NET编程中的基本单元。在C#中类型可以使用classstruct和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的栈结构和堆 一般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 herelock(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 byteprivate byte b2 2; // 1 byteprivate byte b3 3; // 1 byteprivate byte b4 4; // 1 byteprivate char c1 A; // 2 bytesprivate char c2 B; // 2 bytesprivate short s1 11; // 2 bytesprivate short s2 12; // 2 bytesprivate int i1 21; // 4 bytesprivate long l1 31; // 8 bytesprivate 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 x00955124
EEClass x02ca33b0
Size 36(x24) bytes
FieldDesc*: 00955064 MT Field Offset Type Attr Value Name
00955124 00000a 4 System.Int64 instance 31 l1
00955124 00000b c CLASS instance 0a819a0 str lt;lt; some fields omitted from the display for brevity gt;gt;
00955124 4000003 e System.Byte instance 3 b3
00955124 4000004 f System.Byte instance 4 b4 正如之前说过 C# 编译器对于类的默认布局使用 LayoutType.Auto 对于结构使用 LayoutType.Sequential 因此类加载器重新排列实例域以最小化填充字节。我们可以使用 ObjSize 来输出包含被 str 实例占用的空间如下所示
!ObjSize 0x00a8197csizeof(00a8197c) 72 ( 0x48) bytes (SimpleClass)
如果你从对象图的全局大小 72 字节减去 SimpleClass 的大小 36 字节就可以得到 str 的大小即 36 字节。让我们输出 str 实例来验证这个结果
!DumpObj 0x00a819a0Name: System.String
MethodTable x009742d8
EEClass x02c4c6c4Size 36(x24) 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字节的偏移处值为120x0000000C字节。以下是SOS的DumpHeap命令的输出
!DumpHeap -type MyClass Address MT Size
0a819ac 09552a0 12
total 1 objects
Statistics: MT Count TotalSize Class Name
552a0 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 0x9552a0Entry MethodDesc Return Type Name0097203b 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 0x00955268Method Name : [DEFAULT] [hasThis] Void MyClass.Method2()
MethodTable 9552a0Module: 164008mdToken: 06000006Flags : 400IL RVA : 00002068
编译后方法描述的内容如下
!DumpMD 0x00955268Method Name : [DEFAULT] [hasThis] Void MyClass.Method2()
MethodTable 9552a0Module: 164008mdToken: 06000006Flags : 400Method VA : 02c633e8
方法的这个标志域的编码包含了方法的类型例如静态实例接口方法或者COM实现。让我们看方法表另外一个复杂的方面接口实现。它封装了布局过程所有的复杂性让托管环境觉得这一点看起来简单。然后我们将说明接口如何进行布局和基于接口的方法分派的确切工作方式。
接口虚表图和接口图Interface Vtable Map and Interface Map
在方法表的第12字节偏移处是一个重要的指针接口虚表IVMap。如图9所示接口虚表指向一个应用程序域层次的映射表该表以进程层次的接口ID作为索引。接口ID在接口类型第一次加载时创建。每个接口的实现都在接口虚表中有一个记录。如果MyInterface1被两个类实现在接口虚表表中就有两个记录。该记录会反向指向MyClass方法表内含的子表的开始位置如图9所示。这是接口方法分派发生时使用的引用。接口虚表是基于方法表内含的接口图信息创建接口图在方法表布局过程中基于类的元数据创建。一旦类型加载完成只有接口虚表用于方法分派。
第28字节位置的接口图会指向内含在方法表中的接口信息记录。在这种情况下对MyClass实现的两个接口中的每一个都有两条记录。第一条接口信息记录的开始4个字节指向MyInterface1的类型句柄见图9和图10。接着的WORD2字节被一个标志占用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 [eax0Ch] ;move IVMap address into eax at offset 12
mov eax,dword ptr [eax30h] ;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中语句“mi1mc”使用一个指令把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 [eax44h] ;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 tokenmdToken表示了在模块PE文件中映射到内存的元数据表的MyClass索引父类指向System.Object。从相邻链指向名为Program的EEClass可以知道图13显示的是加载Program时的结果。
MyClass有8个虚表槽可以被虚分派的方法。即使Method1和Method2不是虚方法它们可以在通过接口进行分派时被认为是虚函数并加入到列表中。把.cctor和.ctor加入到列表中你会得到总共10个方法。最后列出的是类的两个静态域。MyClass没有实例域。其它域不言自明。
结论
我们关于CLR一些最重要的内在的探索旅程终于结束了。显然还有许多问题需要涉及而且需要在更深的层次上讨论但是我们希望这可以帮助你看到事物如何工作。这里提供的许多的信息可能会在.NET框架和CLR的后来版本中改变不过尽管本文提到的CLR数据结构可能改变概念应该保持不变。
相关文章
《代码的未来》读书笔记内存管理与GC那点事儿CoreCLR源码探索(一) Object是什么CoreCLR源码探索(二) new是什么CoreCLR源码探索(三) GC内存分配器的内部实现.NET跨平台之旅corehost 是如何加载 coreclr 的.NET CoreCLR开发人员指南(上)CoreCLR源码探索(四) GC内存收集器的内部实现 分析篇CoreCLR源码探索(五) GC内存收集器的内部实现 调试篇CoreCLR源码探索(六) NullReferenceException是如何发生的
原文地址http://www.cnblogs.com/savorboard/p/JITCompiler.html.NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
