ここでCommon Language Runtimeの論理的な実行モデルを見てみよう(Figure 7)。まず、各プログラミング言語のコンパイラが生成した中間言語「IL」を、ジャストインタイムコンパイラ(JIT)が、プラットフォームのマシンコード(ネイティブコード)に変換し実行される。
Figure 7 Common Language Runtimeの実行モデル
 |
|---|
ジャストインタイムコンパイラ(JIT)には、大きく分けて「エコノミー」(「エコノモード」、「“Econo”-JIT」と呼ばれる)と、「スタンダード」(「“Standard”-JIT」と呼ばれる)の2種類が用意されている。そして、JITが実行されるタイミングという意味では、もう1つ「PreJIT」が用意されている。
「“Econo”-JIT」は、“最適化されていない”ネイティブコードを生成する。コードはキャッシュされるが、場合によっては破棄されて生成し直される。最適化の作業には時間的なリスクが伴う。つまり、より速いコードを生成するためには、コンパイルの段階で最も効率のいいコードを作り出す必要があるため、その作業に時間が必要になる。ここで最適化の作業に時間が掛けられない場合、取り敢えず動くコードが早く欲しいといった場合に「“Econo”-JIT」を使う。実行時の実行効率とコンパイルのコストのトレードオフを行なっていると考えることができるだろう。このような方法はスクラップ＆ビルドの多い環境などに有効だ。たとえばWebアプリケーションは頻繁に修正が行なわれることがあり、このようなときは有効だろう。
「“Econo”-JIT」とはまったく逆の発想で、1回目の実行の時は少し遅くとも、生成されたコードは速く動いてほしい。つまり最適化されたコードが欲しい場合には「“Standard”-JIT」を使う。この時、「IL」(中間コード)は、セキュリティのアクセスパーミッションやタイプ情報をもとに、コードの整合性検証が行なわれる。なお、Common Language Runtimeでは「“Standard”-JIT」が規定のネイティブコードコンパイラとして使われる。「“Standard”-JIT」は「“Econo”-JIT」に比べて、実行時の効率を重視するような、リッチなクライアントアプリケーションやWebサービスを提供するためのロジックの実行に有効だろう。
そしてもう1つの「“Pre”JIT」は、ネイティブコードへの変換を行なうタイミングが、初めて呼び出された時ではなく、サービスやアプリケーションをインストールした時、もしくは、何らかのタイミングで要求コンパイルがかけられた時にコードを生成する。この方式のメリットは、あらかじめインストール時にコンパイル作業が行なわれているため、スタートアップ時の作業は必要なく、時間を削減できる部分にある。
Figure 8 実行時の呼び出しの流れ
 |
|---|
ここで、実行時の呼び出しの流れを見てみよう(Figure 8)。一番左上の「Assembly」は、サービスやアプリケーションの配布の単位である。このなかに1つ以上のサービスやアプリケーションを入れて配布することができる。
呼び出し要求によって、実際にアプリケーションがスタートアップすると、まず必要なクラスを「Class Loader」がローディングする。次に、中間コードからネイティブコードに変換するコンパイラ「IL to native code compilers」を通して、ネイティブコードに変換される。この時に新しいクラスが要求されると、「Class Loader」に立ち戻って、新しいクラスをローディングしマシンコードに変換していく。ちなみに、一度変換されたコードは、基本的にネイティブコードに変換し直されるということない。そして、一度ローディングされたクラスは、再ロードされるということはない。
ここで、アプリケーションの実行モデルを見てみると(実行時のプロセスモデルのプロセスは、Win32のプロセスメモリ空間として考える)、今までMicrosoftは、アプリケーションのアイソレーションの単位、そして安全で堅牢な実行環境を確保する単位として「プロセス」を推奨してきた。ほかに害を与えないように、プロセスで別けてアイソレーションしておこうという概念だ。しかし、今回は「アプリケーションドメイン」という単位がアプリケーションの動作単位やサービスの提供する単位になった。そしてそれらは、プロセスのなかに1つ以上配置され、個別に管理されることになる。そして、実行時の危険性を避けるために、「Managed Code」という機構を使って、実行コードを細かく管理し、安全性を確保した上で実行される。
