详解CLR中Jit编译发生的过程

理解在CLR中Jit编译发生的过程，了解这个首先要从CLR谈起。CLR(公共语言运行时,Common Language Runtime)和Java虚拟机一样也是一个运行时环境,它负责资源管理(内存分配和垃圾收集),并保证应用和底层操作系统之间必要的分离。

CLR是如何找到托管代码的入口方法并对其Jit的呢？Jit编译的发生过程是怎么样的呢？Jit编译器和Metadata表又有什么关系呢？本文试图寻找出答案，在此之前，不妨先了解一下CLR Header的大致结构。

以如下代码为例：

Example  
using System;  
 
namespace CLRTesing  
{  
class Program  
{  
static void Main(string[] args)  
{  
System.Console.WriteLine("Hello World!");  
Console.ReadKey();  
 
new P().Display();  
 
 
}  
 
Program()  
{  
Console.WriteLine("Constructor.");  
Console.ReadKey();  
}  
 
static Program()  
{  
Console.WriteLine("Static constructor.");  
Console.ReadKey();  
}  
}  
 
class P  
{  
public void Display()  
{  
System.Console.WriteLine("P!");  
Console.ReadKey();  
 
new Q().Display();  
Console.ReadKey();  
}  
}  
 
class Q  
{  
public void Display()  
{  
System.Console.WriteLine("Q!");  
Console.ReadKey();  
}  
}  
} 

编译后通过dumpbin工具的到其CLR Header，如图所示：

从图中可以看到，CLR Header由以下几个部分组成：

1、CB：表示CLR Header的大小，单位是byte；

2、Run time version：运行时版本，包含两部分MajorRuntimeVersion和MinorRuntimeVersion；

3、Metadata Directory：指出Metadata table的RVA和其大小；

4、Flag：这个标识主要是供加载器使用，flag值为0x00000001表示当前runtime image仅由IL代码组成并且对CPU没有特殊要求；值为0x00000002表示image只能被加载到32位机中，值为0x00010000表示运行时和jit编译器需要追踪方法的调试信息；

5、EntryPointToken：Metadata 表中标记为EntryPoint的方法的MethodDef；

6、Resources Directory：CLR的资源，也就是托管资源的RVA和大小，注意与PE文件中存储Win32资源的section不同；

7、StrongNameSignature Directory：PE文件中供CLR加载器使用的哈希值所处RVA和大小；

8、CodeManagerTable Directory：Code Manager 表的RVA和其大小；

9、VTableFixups Directory：由非托管C++类型中虚方法的指针组成的数组；

10、ExportAddressTableJumps Directory：跳转地址表的RVA和大小；

11、ManagedNativeHeader Directory：一般情况下为0。

以上结构可以从CorHdr.h文件中看出，如果装的是Visual Studio 2005，这个文件在\Microsoft Visual Studio 8\SDK\v2.0\include\。

查看托管PE文件的工具有很多，不用很复杂的，就园子里的大牛Anders Liu写的CliPeViwer就很好用，用Reflector可以偷窥其代码哦。

那么在上面这个结构中我最关心的是Metadata directory和EntryPointToken，Metadata directory存提供了原数据所在内存地址的范围，EntryPointToken告诉我们在原数据表中哪个token标识的方法是入口方法，这里一定是方法，所以这个token是以6开头的一个数。

回到主题，我们从CLR已经被载入内存、mscorwks.dll中的_CorExeMain2方法接管主线程开始说起：

1、_CorExeMain2方法会调用System Domain中的SystemDomain::ExecuteMainMethod方法，然后由此方法再去调用其它方法(具体什么方法参见深入了解CLR的加载过程一文中的第8步)， 通过MetaData表提供的接口查找包含.entrypoint的类型，接着返回入口方法(在C#中这个入口方法一定是Main方法)的一个MethodDesc类型的实例；获取MethodDesc类型实例的这个过程我认为是：CLR通过读取MetaData表，定位入口方法所属的类型，将包含该类型的Module载入，然后建立这个类型的EECLASS(EECLASS结构中包含重要信息有：指向当前类型父类的指针、指向方法表的指针、实例字段和静态字段等)和这个类型所包含方法的Method Table(方法表由一个个Method Descripter组成，具体到内存中就是指向若干MethodDesc类型实例的地址)，通过EEClass::FindMethod方法找到并返回入口方法的MethodDesc类型实例。

MethodDesc这个类型很有意思，它有两个重要的部分，一个部分叫做m_CodeOrIL，用来存储编译好的MSIL在内存中的地址，初值为ffffffffffffffff，另一个部分叫做Stub，如果当前代码没有被编译为本地CPU指令，那么通过这个Stub会触发对Jit编译器的调用。

执行上述代码，

[[5737]]

用Windbg 查看，如下：

Windbg1  
0:000> !name2ee *!CLRTesing.Program  
Module: 790c2000 (mscorlib.dll)  
--------------------------------------  
Module: 00a72c3c (Hello.exe)  
Token: 0x02000002  
MethodTable: 00a73048  
EEClass: 00a7129c  
Name: CLRTesing.Program  
 
0:000> !name2ee *!CLRTesing.P  
Module: 790c2000 (mscorlib.dll)  
--------------------------------------  
Module: 00a72c3c (Hello.exe)  
Token: 0x02000003  
MethodTable:   
EEClass:   
Name: CLRTesing.P  
 
0:000> !dumpmt -md 00a73048  
EEClass: 00a7129c  
Module: 00a72c3c  
Name: CLRTesing.Program  
mdToken: 02000002(D:\test\Hello\bin\Debug\Hello.exe)  
BaseSize: 0xc  
ComponentSize: 0x0  
Number of IFaces in IFaceMap: 0  
Slots in VTable: 7  
--------------------------------------  
MethodDesc Table  
 Entry MethodDescJIT Name  
79371278 7914b928 PreJIT System.Object.ToString()  
7936b3b0 7914b930 PreJIT System.Object.Equals(System.Object)  
7936b3d0 7914b948 PreJIT System.Object.GetHashCode()  
793624d0 7914b950 PreJIT System.Object.Finalize()  
00a7c011 00a73030 NONE CLRTesing.Program.Main(System.String[])  
00a7c015 00a73038 NONE CLRTesing.Program..ctor()  
00da0070 00a73040JIT CLRTesing.Program..cctor() 

CLRTesing.Program类型的静态构造函数执行时，入口方法Main和CLRTesing.Program的实例构造函数还没有被Jit，Main方法中引用到的CLRTesing.P类型也没有被加载，所以它的Method Table和EEClass结构也没有建立起来。

#p#

2、在Windbg中detach debuggee，随便敲一个字符让程序继续运行；接着，入口方法Main开始执行，

因为Main方法第一次执行，所以通过Stub，Jit编译器会被唤起，由于Main方法引用了CLRTesing.P类型，那么在执行前会将CLRTesing.P类型载入，并建立Method Table和其EEClass结构，当然这个建立过程也要去查找MetaData表，我认为这个过程是这样的：

Main方法被调用，由于它没有被Jit过，CLR会通过Main方法的MethodDesc结构的Stub对Jit编译器进行调用，CLR通过MetaData表的接口找到Main方法对应的Token，如下：

我们可以看到Main方法的RVA是0x00002050，于是去PE文件的.Text section中的Raw Data中查找image base+RVA这个位置处的IL代码，接着Jit编译器会对这段IL代码进行验证，验证过程通过调用CheckIL方法来实现，这个方法的签名可以是这样的：

CHECK CheckIL(RVA il);  
CHECK CheckIL(RVA il, COUNT_T size); 

验证结束后把这段IL代码编译成本地CPU指令，将编译后后的CPU指令存到内存并修改Main方法的MethodDesc结构中m_CodeOrIL和Stub的值，让它们指向这个新的内存地址，当这个方法被再次调用的时候就会直接通过这个地址访问到本地CPU指令而不会触发第二次编译。对于这个过程大家的看法呢？用Windbg查看各对象情况：

Windbg2  
0:000> !name2ee *!CLRTesing.Program  
Module: 790c2000 (mscorlib.dll)  
--------------------------------------  
Module: 00a72c3c (Hello.exe)  
Token: 0x02000002  
MethodTable: 00a73048  
EEClass: 00a7129c  
Name: CLRTesing.Program  
 
0:000> !name2ee *!CLRTesing.P  
Module: 790c2000 (mscorlib.dll)  
--------------------------------------  
Module: 00a72c3c (Hello.exe)  
Token: 0x02000003  
MethodTable: 00a730b8  
EEClass: 00a71730  
Name: CLRTesing.P  
 
0:000> !name2ee *!CLRTesing.Q  
Module: 790c2000 (mscorlib.dll)  
--------------------------------------  
Module: 00a72c3c (Hello.exe)  
Token: 0x02000004  
MethodTable:   
EEClass:   
Name: CLRTesing.Q  
 
0:000> !dumpmt -md 00a73048  
EEClass: 00a7129c  
Module: 00a72c3c  
Name: CLRTesing.Program  
mdToken: 02000002(D:\test\Hello\bin\Debug\Hello.exe)  
BaseSize: 0xc  
ComponentSize: 0x0  
Number of IFaces in IFaceMap: 0  
Slots in VTable: 7  
--------------------------------------  
MethodDesc Table  
 Entry MethodDescJIT Name  
79371278 7914b928 PreJIT System.Object.ToString()  
7936b3b0 7914b930 PreJIT System.Object.Equals(System.Object)  
7936b3d0 7914b948 PreJIT System.Object.GetHashCode()  
793624d0 7914b950 PreJIT System.Object.Finalize()  
00da00b0 00a73030JIT CLRTesing.Program.Main(System.String[])  
00a7c015 00a73038 NONE CLRTesing.Program..ctor()  
00da0070 00a73040JIT CLRTesing.Program..cctor()  
 
0:000> !dumpmt -md 00a730b8  
EEClass: 00a71730  
Module: 00a72c3c  
Name: CLRTesing.P  
mdToken: 02000003(D:\test\Hello\bin\Debug\Hello.exe)  
BaseSize: 0xc  
ComponentSize: 0x0  
Number of IFaces in IFaceMap: 0  
Slots in VTable: 6  
--------------------------------------  
MethodDesc Table  
 Entry MethodDescJIT Name  
79371278 7914b928 PreJIT System.Object.ToString()  
7936b3b0 7914b930 PreJIT System.Object.Equals(System.Object)  
7936b3d0 7914b948 PreJIT System.Object.GetHashCode()  
793624d0 7914b950 PreJIT System.Object.Finalize()  
00a7c04c 00a730a8 NONE CLRTesing.P.Display()  
00a7c058 00a730b0 NONE CLRTesing.P..ctor() 

我们可以发现Main方法已经被Jit，且它引用的CLRTesing.P类型的相关结构也已经建立起来了，而CLRTesing.P类型的Display方法所引用的CLRTesing.Q类型没有被载入。

总结一下，Jit编译针对的对象总是方法，不论是入口方法还是其他方法的Jit过程都类似上述过程，Metadata这这里的作用不言而喻，可以说没有Metadata的支持就无法进行Jit，我觉得Meatadata在Jit编译期间的作用至少有三个：

1、Jit编译器通过查找Metadata来找到入口方法；

2、Jit编译器通过查找Metadata来定位待编译方法并利用其RVA找到存储于PE文件中的IL代码在内存中的实际地址；

3、Jit编译器在找到IL代码并准备编译为本地CPU指令前所进行的IL代码验证同样会用到Metadata，例如，验证方法的合法性需要去核实方法参数数量是正确的、传给方法的每个参数是否都有正确的类型、方法返回值是否正确等等。

文中是一些我通过Shared Source Common Language Infrastructure(SSCLI)看到的和感觉到的东西，希望能给大家理解Jit提供一点帮助，如果有错误的地方也请大家指出，大家一起学习。

最后要说明的是，SSCLI里东西仅作为理解CLR使用，与MS真正实现CLR的过程可能不一样。最后，大家在看SSCLI的时候可以使用Source Insight，个人感觉还挺好用。

 SSCLI的下载地址是：http://www.microsoft.com/downloads/details.aspx?FamilyId=8C09FD61-3F26-4555-AE17-3121B4F51D4D&displaylang=en。

本文来自Leo Zhang的博客园文章《深入了解Jit编译发生的过程》

【编辑推荐】

1. C#treeview递归操作数据库浅析
2. C#递归树实现实例简析
3. C#打开记事本实现实例解析
4. C#调用记事本实例浅析
5. C#日期格式化方法简析