第二章 NGWS runtime 技術基礎
既然你已經具有了C#全面的印象，我也想讓你了解NGWS runtime的全貌。C#依靠由NGWS提供的運行時；因此，有必要
知道運行時如何工作，以及它背後所蘊含的概念。
所以，這一章分為兩部分——它們是所有的概念和使用的基礎。兩部分的內容雖然有些重疊，但它有助於加深理解正
在學習的概念。
2.1 NGWS Runtime
NGWS和NGWS Runtime為你提供了一種運行時環境。該運行時管理執行代碼，並提供了使編程更容易的服務。只要你的
編譯器支持這種運行時，你就會從這種受管理的執行環境中得益。
你猜測C#編譯器支持NGWS runtime很正確，但是不僅它支持NGWS runtime，VB和C++也支持。這些為支持運行時所創建
的代碼稱作"受管代碼"(managed code)。以下是你的應用程序從NGWS runtime那裡所得到的利益：
交叉語言集成(通過通用語言規范)
自動內存管理(垃圾收集)
交叉語言異常處理(統一展開)
增強安全(包括類型安全)
版本支持("DLL地獄"終結者)
組件交互簡化模式
因NGWS runtime 要提供了所有的這些好處，編譯器必須把元文件和受管代碼一起發出。元文件描述代碼中的類型，它
和你的代碼存在一起(與PE類似---PE為可變位執行文件)
正如你從很多種交叉語言功能所看到的，NGWS runtime主要是關於高度集成交叉多異編程語言(tight integration
across multiple different programming languages)。這種支持可達到允許你從一個VB對象派生出一個C#類的程度(我後
面會給出要討論的文章)。
C#程序員將會喜歡的一個功能是，他們不必擔心內存管理—也就是說不必擔心臭名昭著的內存洩漏。NGWS runtime提
供了內存管理，當對象和變量的生命期結束(不再被引用)時，垃圾收集器釋放它們。我真的喜歡這個功能，因為在COM中的
內存管理一直是我的一塊心病。
應該鼓勵配置一個管理應用程序或者組件。因為管理應用程序含有元數據文件，NGWS runtime可以利用這些信息，以
確保你的應用程序具有它所需的各種規定版本。所產生的明顯效果為，由於你的代碼沒有相互之間的依賴，很少可能出現
中斷。
這章余下來的將分為兩部分，每一部分討論NGWS runtime的各個方面，直到你的C#應用程序能執行為止。
1、中間語言(Intermediate Language，縮寫IL)和元數據
2、即時編譯器(just-in-time compliers,簡稱JITers)
2.1.1 中間語言和元數據
由C#編譯器生成的受管代碼並不是原始代碼，但它是中間語言(IL)代碼。這種IL代碼自身變成了NGWS runtime的受管
執行進程的入口。IL代碼明顯的優勢在於它是CPU無關的，這也意味著，你要用目標機器上的一個編譯器才能把IL代碼轉換
成原始代碼。
盡管IL代碼由編譯器產生，但它並不是編譯器提供給運行時僅有的東西。編譯器同樣產生有關你代碼的元數據，它告
訴運行時有關你代碼的更多的東西，例如各種類型的定義、各種類型成員的簽名以及其它數據。基本上，元數據是類型
庫、注冊表內容和其它用於COM的信息。盡管如此，元數據還是直接和執行代碼合並在一起，並不處在隔離的位置。
IL和元數據存放於擴展了PE格式的文件中(PE格式用於.exe和.dll文件)。當這樣的一個PE文件被裝載時，運行時從文
件中定位和分離出元數據和IL。
在進一步說明之前，我想給你已有的IL指令的簡短目錄。盡管它不是一個完整的清單，也不需要你熟記和理解，但是
它列出了你所必需的、C#程序所基於的知識基礎。
算術和邏輯操作符
控制流
直接內存訪問
堆棧操作
參數和局部變量
堆棧分配
對象模式
實例類型值
臨界區
數組
分型位置
即時編譯器(JITters)
2.1.2 即時編譯器(JITters)
由C#或其它能產生受管代碼的編譯器所生成的受管代碼就是IL碼。雖然IL代碼被包裝在一個有效的PE文件中，但是你
還是不能執行它，除非它被轉換成為受管原始代碼。這就是NGWS runtime 即時編譯器(也稱作JITters)大顯身手的時候。
為什麼你會對即時編譯代碼感到厭繁， 為什麼不把整個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編譯)。
在所列出的JITters中，有兩個是運行時的JITters。可是你怎麼決定要使用哪一個JIT，它如何使用內存? 有一個稱
做"JIT編譯管理器"的小應用程序(jitman.exe)，它存放於NGWS SDK安裝目錄下的bin目錄中。當執行該程序時，它把一個
圖標加到系統任務條上，雙擊該圖標打開程序對話框(見圖2.1)。
圖2.1 JIT編譯管理器允許你設置各種相關性能的選項
盡管它是一個小小的對話框，可是你所選擇的選項功能是相當強大的。每一個選項將在以下描述。
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的最大
差別。
2.2 虛擬對象系統(VOS)
到目前為止，你僅看到了NGWS runtime如何工作，但是並不了解它工作的技術背景以及為什麼它要這樣工作。這節都
是關於 NGWS 虛擬對象系統的(VOS)。
以下
