.Net Compact Framework CLR設計系列之JIT編譯器講解
這個.Net Compact Framework CLR設計這個話題被很多人關注?，F在我們可以從設計者的角度，深入了解.Net Compact Framework CLR設計的內部結構。這部分我們要討論JIT編譯器的知識。感謝Steven Pratschner，感謝他給我們帶來了這么好的文章。
設計JIT編譯器
.Net Compact Framework CLR設計的***章，以后我們還會為大家提供更多的，希望大家關注。.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 1The size of the JIT heap over the lifetime of an application.
圖1中的一些情況是十分值得注意的。首先，圖中的兩個低點發生的時間，對應于程序被切換到后臺和堆的尺寸太大而開始代碼回收的時間。同樣，注意程序啟動的時候比程序從后臺切換回來時，會有更多代碼被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。如果相應的本地映像是這個尺寸的四倍的話，你就會看到本地映像需要的存儲空間是設備中可用內存中相當大的一部分。另外一種可能就是可以將本地映像保存在外部存儲卡上。可是從存儲卡讀取本地映像文件的速度是非常慢的，因此我們不確定啟動時間可以通過本地映像的方法可以縮短。
以上介紹.Net Compact Framework CLR設計，Compact Framework JIT團隊會在每個主要版本中考慮本地映像，也許在CLR的未來某個版本中，我們會看到本地映像，或者類似的技術。
【編輯推薦】
