这个系列文章的第一部分上了CSDN的首页，可见这个话题还是有很多人关注的。而且我们也能够从设计者的角度深入了解.Net Compact Framework CLR的内部结构。这部分我们要讨论JIT编译器的知识。再次感谢Steven Pratschner，感谢他给我们带来了这么好的文章，本章的英文版可以在这里找到。
第二章 设计JIT编译器这是《设计.Net Compact Framework CLR》系列文章的第二部分。你可以在这里看到第一部分。在第二部分中，我们将讨论.Net Compact Framework JIT编译器的一些基本设计原则。
----
.Net Compact Framework的JIT编译器与.Net Framework最大的不同在于内存使用。在内存紧张的情况下，.Net Compact Framework可以释放Jitted代码，将内存返还给操作系统。正如你所预料的那样，如此设计的原因是因为用于存储jitted代码的堆是分配在应用程序私有的32MB地址空间上的（更多信息可以参考第一部分）。除了私有地址空间非常小之外，考虑到它们从来不被分页，在内存受限设备上运行程序，必要时减少空间压力的设计是绝对必要的。
当程序被执行时，JIT编译器会在堆上分配内存，用来存储每个方法编译生成的本地代码。因为编译和内存分配发生在每个方法运行的时候，每次内存分配都会让堆相应减少。换句话说，就是JIT堆在小幅度地逐渐增长。在程序运行过程中，JIT堆会增长到很大的程度。在Compact Framework的早期版本中，JIT堆的尺寸被限制在一个固定的大小中。在第二版中，这个限制已经被去掉了，因此在新方法需要被编译时，堆会增加。
三种情况的发生，会导致JIT堆的大部分空间被释放并将内存归还给OS（这里只所以说“大部分空间”是因为Compact Framework必须始终保留当前执行应用程序方法的jitted代码）。首先，如果CLR试图分配更多内存时，收到一个来自操作系统的错误，JIT堆将会收缩。CLR会认为这个失败表明可用内存数量不足，于是尽可能多的挥手JIT堆中的代码。从JIT堆中释放本地代码的动作是根据代码存在期限决定的。其次，当一个程序被切换到后台时，代码会被回收。在Windows Mobile中，应用程序通常不会被关闭，但是会被切换到后台。当一个程序被切换到后台时，通过释放代码，CLR可以获得更多可用内存供前台程序使用，这样可以增加同时运行在设备上应用程序的数量。最后，当一个托管应用程序收到来自Windows CE的WM_HIBERNATE消息时，CLR会回收jitted代码。当OS发现运行的系统资源过低时，会发出WM_HIBERNATE消息。当设备资源缺乏时，响应WM_HIBERNATE消息的代码回收是CLR释放内存和其他资源操作的一部分。
我在稍后章节讨论自动内存管理时，你将会看到，代码回收是整个垃圾收集的一部分。
Figure 3
The size of the JIT heap over the lifetime of an application.
图3中的一些情况是十分值得注意的。首先，图中的两个低点发生的时间，对应于程序被切换到后台和堆的尺寸太大而开始代码回收的时间。同样，注意程序启动的时候比程序从后台切换回来时，会有更多代码被jitted。这大概是因为应用程序包含一些初始化代码，而这些代码只是在程序开始时被调用。
因为CLR会在内存紧张或者程序切换到后台时丢弃本地代码，所以在程序继续运行时，相同的IL代码会被再次JIT编译。正因为如此我们才作出了第二个关于JIT编译器的设计决定：编译IL代码的时间通常优先于生成本地代码的质量。作为一个优秀的编译器，Compact Framework JIT编译器做了一些基本的优化，但是为了让应用程序保持响应，就需要更快地生成代码，更多地优化措施要根据其速度来决定是否执行。
JIT编译器最后一个关键设计原则是不涉及内存使用，这样做是为了让JIT编译器更方便移植。我在第一部分曾提到，Compact Framework的运行环境不仅要求它能够在内存受限设备上运行，而且需要它可以在不同的处理器上运行。.Net Compact Framework目前可以运行在包括x86、Arm、SH和MIPS等处理器上，而且还可以根据要求支持更多的处理器。因为需要跨越不同领域的设备，JIT编译器被设计成花费最少时间，便可以支持一种新的处理器类型的架构。一种技术被用来增加可移植性，就是将处理器相关的操作限制在最小程度。
Why no Native Images?桌面版的.Net Framework使用一种叫“本地映像”的技术，当应用程序加载时，IL代码都需要被JIT编译器编译。如果利用了本地映像技术，应用程序可以更快地启动。本地映像是一个保存在硬盘上的文件，包含被编译好的IL代码。当.Net Framework安装时，它会调用JIT编译器生成mscorlib、System.Windows.Forms等类库的本地CPU指令。当应用程序启动时，就可以直接调用储存在本地映像中的已经生成的本地代码，从而节省了JIT编译这些程序集的时间。用户也可以为自己编写的程序集产生本地映像（可以参考.Net Framework SDK中ngen.exe工具的文档）。
.Net Compact Framework没有使用本地映像的主要原因是他们的尺寸。根据本地指令集的不同，一个程序集被JIT编译后产生的本地代码大小大约是IL代码的三到四倍。在压缩之后，.Net Compact Framework类库大约是4.5MB。如果相应的本地映像是这个尺寸的四倍的话，你就会看到本地映像需要的存储空间是设备中可用内存中相当大的一部分。另外一种可能就是可以将本地映像保存在外部存储卡上。可是从存储卡读取本地映像文件的速度是非常慢的，因此我们不确定启动时间可以通过本地映像的方法可以缩短。
Compact Framework JIT团队会在每个主要版本中考虑本地映像，也许在CLR的未来某个版本中，我们会看到本地映像，或者类似的技术。
在下一章中，我们将看一下Compact Framework中的垃圾收集相关的设计原则。
This posting is provided "AS IS" with no warranties, and confers no rights.
