随笔- 105  评论- 1094  文章- 1 

.Net Discovery 系列之六--深入浅出.Net实时编译机制(下)

    接上文

    在初始化时,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主要完成以下工作:

  1. 查找程序集中包含的对应类型清单,并调用元数据遍历出包含的方法。
  2. 结合元数据获得这个方法的IL。
  3. 分配内存。
  4. 编译IL为本地代码,并保存在第3步所分配的内存中。
  5. 将类型表(就是指上文中提到的HashTable)中方法地址修改为第3步所分配的内存地址。
  6. 跳转至本地代码中执行。

    所以随着程序的运行时间增加,越来越多的方法的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它们。

这听起来似乎很美妙,但是你必须做好以下准备:

  1. 当FrameWork版本、CPU类型、操作系统版本发生变化时,.Net会恢复JIT机制。
  2. NGen.exe工具并不能避免发布IL,事实上,即使使用NGen.exe工具,CLR依然会使用到元数据和IL。 
  3. 忽略了局部性原理(上一节中提到的),系统会加载整个映像文件到内存中,并很可能重定位文件,修正内存地址引用。 
  4. NGen.exe生成的代码无法在运行时进行优化,无法直接访问静态资源,也无法在应用程序域之间共享程序集。 

    此外,JIT不但有编译的本事,还会根据内存资源情况换出使用率低的代码,节省资源,这对于一些基于.Net平台的电子产品是很重要的。 

    所以,除非你已十分清楚程序性能是由于首次编译造成的性能问题,否则尽量不要人工生成本地代码。 

 

    我是李鸣(Aicken) 请您继续关注我的下一篇文章。

 

    “.Net Discovery 系列”推荐:

     .Net Discovery 系列之五--Me JIT(上)

     .Net Discovery 系列之三--深入理解.Net垃圾收集机制(上)

     .Net Discovery 系列之四--深入理解.Net垃圾收集机制(下)

     .Net Discovery 系列之一--string从入门到精通(上)

     .Net Discovery 系列之二--string从入门到精通(下)

posted on 2009-12-27 17:35 Aicken(李鸣) 阅读(...) 评论(...) 编辑 收藏