.Net Discovery 系列之六--深入浅出.Net实时编译机制(下)-阿里云开发者社区

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

2017-11-15 1259

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介：

接上文

在初始化时，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() { }



}



}