C# NGWS runtime即时编译器

C# NGWS runtime即时编译器

由C#或其它能产生受管代码的编译器所生成的受管代码就是IL码。虽然IL代码被包装在一个有效的PE文件中,但是你还是不能执行它,除非它被转换成为受管原始代码。这就是C# NGWS runtime即时编译器大显身手的时候。

为什么你会对即时编译代码感到厌繁,为什么不把整个IL PE文件编译成原始代码? 答案是时间——需要把IL代码编译成CPU规格的代码的时间。这种编译将更加有效率,因为一些程序段从来就没有被执行过。例如,在我的字处理器中,邮件合并功能从来就没有被编译。

从技术上说,全部的处理过程如下:当一个类型被装载时,装载器创建一个存根(stub),并使它连接每一个类型的方法。当一个方法第一次被调用时,存根把控制交给JIT.JIT把IL编译为原始代码,且把存根指针指向缓冲了的原始代码。

接着的调用将执行原始码。在某些位置上(At some point),所有的IL都被转换成为原始代码,而JITter处于空闲状态。

正如我在前面提到的,JIT编译器有很多,不止一个。在Windows平台上,NGWS runtime装有3个不同的JIT编译器。JIT——这是NGWS runtime默认使用的JIT编译器。它是一个后台(back end)优化的编译器 ,在前台(up front)实行数据流分析,并创建了高度优化的受管原始代码做为输出结果。JIT可以使用不严格的IL指令集编码,但是所需资源将十分可观。主要的限制在于内存足迹(footprint)、结果工作集,以及实行优化所消耗的时间。

EconoJIT—— 和主JIT相比,EconJIT的目标是把IL高速地转换成受管原始代码。它允许缓冲所产生的原始代码,但是输出码并不象主JIT生成的代码那样优化(代码小)。当内存紧张时,快速代码生成方案的优势将荡然无存。通过永久地抛弃无用的已JIT过的代码,你可以把更大的IL程序装入代码缓冲区。因为JIT编译快,执行速度也仍然很快。

PreJIT-尽管它是基于主JIT的,但操作起来更象是一个传 统的编译器。你安装了NGWS组件,它才能运行,才可以把IL代码编译成受管原始代码。当然最终的结果为,更快的装载时间和更快的应用程序启动时间(不需要更多的JIT编译)。

在所列出的即时编译器中,有两个是运行时的即时编译器.可是你怎么决定要使用哪一个JIT,它如何使用内存?有一个称做"JIT编译管理器"的小应用程序(jitman.exe),它存放于NGWS SDK安装目录下的bin目录中。当执行该程序时,它把一个图标加到系统任务条上,双击该图标打开程序对话框。

尽管它是一个小小的对话框,可是你所选择的选项功能是相当强大的。每一个选项将在以下描述。Use EconoJIT only 选项——当该复选框没有选上时,NGWS runtime使用默认的正常的JIT编译器。前面就曾经解释过两种JITter的区别。

Max Code Pitch Overhead(%)选项——该设置仅保留给EconoJIT.它控制了JIT编译时间和执行代码时间的百分比。如果超过了设定的域值,代码缓冲区得到扩充,以缩短JIT编译所消耗的时间。

Limit Size of Code Cache选项——该项默认为非选。没有选择该项意味着缓冲区将使用它所能得到的内存。如果你想限制缓冲区大小,复选该选项,这将允许你使用Max Size of Cache(bytes)选项。

Max Size of Cache(bytes)选项-控制容纳JIT代码的缓冲区的最大值。虽然你可以非常严格地限制这个值,但你还是应该小心,不能超过这个缓冲区所适合的最大值。否则该方法的JIT编译将会失败。

Optimize For Size选项——告诉JIT 编译器,优化的目的是为了使代码更小而不是能执行得更快。这个设置默认是关掉的。

Enable Concurrent GC[garbage collection]选项——垃圾收集(GC)默认地运行在用户代码的线程中。意味GC发生时,可能会注意到回应有轻微的延迟。为防止出现该现象,打开当前GC.注意,当前GC 比标准GC更慢,它仅在windows 2000上写时(the time of writing)有效。

当用C#创建项目时,你可能使用不同的设置试验过。当创建 UI-intensive应用程序时,你将会看到允许当前GC的最大差别。以上介绍C# NGWS runtime即时编译器。

【编辑推荐】

  1. 介绍Mono C#编译器
  2. C#运算符重载学习总结
  3. 概述C#语言的结构体
  4. C#遗传算法学习笔记
  5. 讨论C#分部方法
THE END