接上文
在初始化时，HashTable中各个方法指向的并不是对应的内存入口地址，而是一个JIT预编译代理，这个函数负责将方法编译为本地代码。注意，这里JIT还没有进行编译，只是建立了方法表！
下表(表1)为首次加载调用时HashTable的情况：
表1 方法表示意
方法槽 |
方法描述 |
a1() |
PreJitStub |
a2() |
PreJitStub |
a3() |
PreJitStub |
好了有了这个HashTable后，JIT开始编译第一个被调用的方法A.a1("First")，这是由一个JIT内部函数来完成的(上面提到的)，遗憾的事，目前还没有发现介绍这个函数的相关资料，有些书中称它为“JIT编译者”，那本文也这么称呼它吧。
下图为首次调用方法时的示意图：
图2 触发JIT编译
JIT借助元数据和IL生成被调用方法的本地代码后，会将这些代码缓存在动态内存中，然后修改HashTable中对应方法的入口地址，将其修改为本地代码的内存片地址(如表2所示)，并将这个地址返回给CLR经行执行，A.a1("First")执行完毕，代码继续运行。
运行至A.a1("Second ")时，会直接执行A.a1()方法的内存代码，不会进行再次编译，表2 为再次加载时HashTable的情况。
表2 方法表变化
方法槽 |
方法描述 |
a1() |
XXXXXXXXX内存地址 |
a2() |
PreJitStub |
a3() |
PreJitStub |
再次加载流程示意图：
图3 未触发JIT编译
图4 方法表、方法描述、预编译代理关系
图2中所示的MS核心引擎指的是一个叫做MSCorEE的DLL，即Microsoft .NET Runtime Execution Engine，它是一个桥接DLL，连同mscorwks.dll主要完成以下工作：
- 查找程序集中包含的对应类型清单，并调用元数据遍历出包含的方法。
- 结合元数据获得这个方法的IL。
- 分配内存。
- 编译IL为本地代码，并保存在第3步所分配的内存中。
- 将类型表(就是指上文中提到的HashTable)中方法地址修改为第3步所分配的内存地址。
- 跳转至本地代码中执行。
所以随着程序的运行时间增加，越来越多的方法的IL被编译为本地代码，JIT的调用次数也会不断减少。
下面借助WinDbg来证实以上的说法，示例中的源程序可以到这里下载到：
http://files.cnblogs.com/isline/IsLine.JITTester.rar
namespace JITTester
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
}
private void GO_Click(object sender, EventArgs e)
{
new A().a1();
lb_msg.Text = "调用完毕!" ;
}
}
class A
{
public void a1() { }
public C a2 = new C();
}
class B
{
public void b1() { }
public void b2() { }
}
class C
{
public void c1() { }
public void c2() { }
}
}
代码中定义了3个类，分别为A、B、C，在“GO”按钮按下后，将调用类型A中的a1()方法，而Form1_Load 中什么也不做，目的是程序运行后，在空载的情况下查看方法描述对应地址入口的情况。
好，第一步运行JITTester.exe程序，并打开WinDbg附加这个进程
图 5 附件进程
第二步，附加进程成功后，在WinDbg中加载SOS.dll
图6 加载SOS.dll
第三步，使用name2ee命令遍历所有已加载模块，name2ee格式为name2ee *! [程序集].[类型]
图7 查看类型信息
回车后注意高亮区域的信息：
图8 JIT前A类型的信息
高亮区域显示的是“<not loaded yet>”，这说明虽然运行和程序，但未点击按钮时，A类型未被JIT，因为它还没有入口地址。这一点体现了即时、按需编译的思想。
同样，!name2ee *!JITTester.B和!name2ee *!JITTester.C命令会得到同样的结果。
好，现在做第4步操作，Detach Debuggee进程，并回到程序中点击“GO”按钮
图9 点击按钮
第五步 重新附加进程(参考第一步)，这时程序已经调用了new A().a1()方法，并重新执行命令!name2ee *!JITTester.A ，注意高亮部分
图10 JIT后A类型的信息
和图8中的信息比较，图10中的方法表地址已经变为JIT后的内存地址，这时图4中的Stub槽将被一条强制跳转语句替换，跳转目标与该地址有关。这一点说明JIT在大多情况下，只编译一次代码。
同样命令查看B类型：
图11 JIT后B类型的信息
该类型未被调用，所以还未被JIT。
C类型：
图12 JIT后C类型的信息
由于实例化A类型时和C类型相关，所以C类型已经JIT了。
第三节．Native Image Generator
Native Image Generator中文译为本地代码生成器，我更习惯叫它“本地映像”，因为通过工具NGen.exe生成的本地代码是无法部分载入的，这意味着操作系统会加载整个程序集文件。
上一节中提到过，有两种方法可以获得本地代码，JIT方式和Native Image Generator方式，JIT方式是在运行时动态编译需要的代码，而NGen.exe会创建托管程序集的本机映像，并且将该映像安装到GAC中，运行该程序集时，就会自动使用该本机映像而不是JIT它们。
这听起来似乎很美妙，但是你必须做好以下准备：
- 当FrameWork版本、CPU类型、操作系统版本发生变化时，.Net会恢复JIT机制。
- NGen.exe工具并不能避免发布IL，事实上，即使使用NGen.exe工具，CLR依然会使用到元数据和IL。
- 忽略了局部性原理(上一节中提到的)，系统会加载整个映像文件到内存中，并很可能重定位文件，修正内存地址引用。
- NGen.exe生成的代码无法在运行时进行优化，无法直接访问静态资源，也无法在应用程序域之间共享程序集。
此外，JIT不但有编译的本事，还会根据内存资源情况换出使用率低的代码，节省资源，这对于一些基于.Net平台的电子产品是很重要的。
所以，除非你已十分清楚程序性能是由于首次编译造成的性能问题，否则尽量不要人工生成本地代码。
本文转自Aicken(李鸣)博客园博客，原文链接：http://www.cnblogs.com/isline/archive/2009/12/27/1633453.html，如需转载请自行联系原作者
