JP2004070944A - アプリケーション向けにオペレーティングシステム機能を拡張するシステムおよび方法 - Google Patents

Abstract

【課題】　アプリケーション向けにオペレーティングシステム機能を拡張する。
【解決手段】　本発明に係る方法は、アプリケーションから１つまたは複数の２進命令を受け取るステップと、１つまたは複数の２進命令が、特定のオペレーティングシステム機能を実行する、オペレーティングシステムへのコールに対応するかどうかを判定するステップと、特定のオペレーティングシステム機能をアプリケーション向けに変更すべきかどうかを判定するステップと、特定のオペレーティングシステム機能をアプリケーション向けに変更すべき場合、変更された機能を実施するコードを実行するステップとを含む。
【選択図】図４

Description

　本発明は、オペレーティングシステムの機能拡張に関する。

　コンピュータユーザは、オペレーティングシステム機能（たとえば、新しいプロトコルのサポート、新しい使用パターンへの適合、アプリケーションによるシステム資源使用の監視または制限、アプリケーションのサンドボックス化(sandboxing)等）を、アプリケーションが利用できるように拡張したいと常に望んでいる。
　オペレーティングシステム機能を拡張する現行システムは通常、２つの主な手法のうちのいずれか一方である。

　第１の手法は、新しい拡張可能オペレーティングシステムを設計するというものである。
　この単純な手法では、所望の機能を組み込むようにオペレーティングシステムを変更する必要がある。
　この場合、新しいオペレーティングシステムを所望の機能毎に構成する必要があるため、この手法の適用範囲はかなり制限される。
　第２の手法は、既存のオペレーティングシステムに拡張性を追加するというものである。

　既存のオペレーティングシステムに拡張性を追加するには、様々な手法がある。
　１つの既存の手法は、オペレーティングシステム自体を変更するのではなく、所望の機能を実施する新しいデバイスドライバに変更するというものである。
　別の既存の手法は、すでに存在する標準インタフェースを通して追加サービスを提供するネットワークサーバを設置するというものである。

　これら手法はそれぞれ、必要とされるユーザ介入の度合いが高いため限定的である可能性がある。
　さらに、新しい機能は、デバイスドライバまたはオペレーティングシステムプラグインの文脈において容易に実施することができない場合がある。
　これは、こういった拡張が予め定義されている前提のセットによって制限されるためである。

　さらに、こういった手法は、オペレーティングシステムへの変更が各ユーザによって認識されるため、システムの各ユーザに影響を及ぼす。
　たとえば、新規にインストールしたソフトウェアにバグまたはセキュリティホールがある場合には、システム全体の保全性が脅かされる恐れがある。

　オペレーティングシステム機能を拡張する別の一般的な手法は、仲介エージェントを使用してシステムコールをインタセプトするというものである。
　図１は既存のコンピュータ環境を示す代表的なシステム１００のブロック図である。
　このコンピュータ環境では、アプリケーション１０２がオペレーティングシステム１０４を呼び出して、指定されたオペレーティングシステム機能をハードウェア１０６で実行することができる。

　図１に示すように、アプリケーション１０２とオペレーティングシステム１０４との間には、様々なタイプのインタフェース（たとえば、システムコール、ライブラリ関数等）が一般に見られる。
　当分野において既知であり、かつ上述したように、アプリケーション１０２（たとえば、実行可能プログラム等）は一般に、特定のアクションを実行する機能を利用する。
　関数は、特定のアクションを実行する、かつ／または値を返す宣言および／またはステートメントの集まりを含むことができる。
　関数はユーザによって定義されるか、または予め定義されたものがユーザに提供される場合がある。

　関連機能（たとえば、数学またはグラフィックスルーチン等）を有する予め定義された関数は、たとえばオブジェクトの形態でライブラリまたはアーカイブファイルに格納することができる。
　オブジェクトコードフォーマットは、実行可能プログラムが生成される際に中間ステップとして生成される特定のファイルフォーマットである。
　ライブラリファイルに格納された関数は、ライブラリ関数またはランタイムライブラリルーチンと呼ばれることが多い。

　プログラムが使用する、予め定義されているいくつかの関数は、オペレーティングシステム１０４への実際のシステムコールである。
　ライブラリ関数のフォーマットは似ているが、システムコールは、アプリケーション１０２に関連するプロセスを呼び出す代わりに、オペレーティングシステム１０４があるジョブを直接実行するように要求する。

　オペレーティングシステム１０４によって実行されるコードは、たとえば、オペレーティングシステム１０４のカーネル（すなわち、中央制御プログラム）内に常駐する。
　システムコールは、このコードへの高水準／中間水準言語インタフェースとして機能する。
　カーネルの保全性を守るため、システムコールを実行するプロセスは、ユーザモード（ユーザ特権およびアクセス許可）からシステムモード（システム／ルート特権およびアクセス許可）に一時的に切り換えなければならない。

　文脈においてこの切り換えには、特定量のオーバヘッドが伴い、場合によっては、システムコールの効率を同じタスクを実行するライブラリ関数よりも悪化させてしまうことがある。
　多くのライブラリ関数（たとえば、入出力に関連するライブラリ関数）は完全にバッファリングされるため、これにより、システムが特定のタスクを実際に実行するときをある程度制御することが可能になる。
　図１に示すように、実行可能プログラムは、特定の関数を実行するようオペレーティングシステム１０４に直接要求するシステムコールを利用するか、または代わってシステムコールを実行することが可能なライブラリ関数を呼び出すことができる。

　この手法の各種使用例については、非特許文献１に記載されるとともに、参考文献が載せられており、この文献全体を参照により本明細書に援用する。
　図２は、この手法を用いてオペレーティングシステム１０４の機能を拡張する既存のシステム２００の例を示すブロック図である。
　図２に示すように、オペレーティングシステム１０４の機能を拡張するために、システム２００は、アプリケーション１０２とオペレーティングシステム１０４との間に挿入されたシステムコール仲介エージェント（たとえば、オペレーティングシステム拡張システム２０２）を備える。

　典型的なオペレーティングシステム拡張システム２０２は、インタセプトモジュール２０４およびオペレーティングシステム拡張モジュール２０６からなる。
　インタセプトモジュール２０４は通常、アプリケーション１０２に添付され、アプリケーション２０４によって発行されたシステムコールのうち、選択されたシステムコールをインタセプトする。
　動作にあたり、インタセプトモジュール２０４はユーザプロセスに接続され、オペレーティングシステム１０４にいずれのシステムコールをインタセプトすべきかを伝える。

　たとえば、注目するシステムコール（すなわち、インタセプトモジュール２０２がインタセプトし、Ｏ／Ｓ拡張モジュール２０６が実行すべきシステムコール）が開始されると常に、インタセプトモジュール２０４がオペレーティングシステム１０４にシステムコールのインタセプトを通知し、オペレーティングシステム１０４が対象となるプロセスを停止させる。
　次に、オペレーティングシステム１０４はＯ／Ｓ拡張モジュール２０６とやりとりし、適切な拡張関数を呼び出す。

　この手法もまたかなり限定的である可能性がある。
　たとえば、既存のシステムに使用されるシステムコール仲介エージェントは通常、土台をなすオペレーティングシステムによって提供される機能を使用して実施される。
　例として、Alexandrov等が記載するシステムは、トレース機能（たとえば、Ｕｎｉｘ（登録商標）オペレーティングシステムにより提供される／ｐｒｏｃファイルシステム、ならびにｐｔｒａｃｅプロセス制御よびデバッグインタフェース）を使用することにより、選択されたシステムコールをユーザレベルでインタセプトする。

　オペレーティングシステム１０４によって提供されるトレース機能を用いて、プロセスに、別のプロセスが選択されたシステムコールに入るとき、または出るときを通知することができる。
　この機能の当初の目的はシステムコールのデバッグおよびトレースであったため、既存のシステムはこの機能を実施してプロセスの振る舞いを変更し、それによってオペレーティングシステム１０４の機能を拡張する。

　したがって、こういったシステムでは既存のオペレーティングシステム機能が求められるため、使用されている特定のオペレーティングシステム１０４に依存する。
　この手法は、かかる機能を提供しない、または同様の機能を別の互換性のない形態で提供する特定のオペレーティングシステム（たとえば、Ｗｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステム）では不可能な場合がある。

　さらに、この手法は、複数のアプリケーション１０２、複数のオペレーティングシステム１０４、複数のオペレーティングシステム拡張等に実施することのできる移植性のある方策を提供しない。
　たとえば、図２に特徴付けるシステムは、実施されている特定のシステムのある特定の詳細およびオーバロードする必要があるインタフェースの詳細に基づく。

　一例として、上で引用した参考文献において、Alexandrov等は、オペレーティングシステムが提供する／ｐｒｏｃファイルシステム機能を使用してシステムコールをインタセプトすることにより、標準Ｕｎｉｘ（登録商標）オペレーティングシステムを個人化された大域的ファイルシステムを実施するように拡張するシステムについて記載している。
　さらに、こういったシステムは、一点制御であることから元のシステム中のかなり異なる場所で実施され得る複数の異なる機能のインタセプトが容易な、柔軟な手法を提供しない。

　たとえば、インタセプト／オーバロードに求められる機能が動的リンクライブラリ（ＤＬＬ）にあり、別の機能がオペレーティングシステム自体にある場合、場当たり的な（アドホック）方策は必然的に場合毎に異なるであろう。
　さらに、こういったシステムでは、アプリケーション毎にシステムコール仲介機構の振る舞いに違いを持たせること、および／またはアプリケーション実行中に随意に除去かつ／または再挿入すること、が困難な場合がある。

　また、こういった手法は通常、オペレーティングシステム機能の拡張に関連する大きなオーバヘッドにより非常に遅い傾向がある。
　たとえば、オペレーティングシステム拡張を呼び出すアプリケーションの実行速度は通常、オーバヘッドが大きいため、望ましい速度よりもはるかに低速である。
Alexandrov、Ibel、Schauser、およびScheiman著「UFO:A Personal Global File System Based on User-Level Extensions to the Operating System」（ACM Transactions on Computer Systems, Vol.16, No.3, August 1998, pp. 207-233）

　本発明の目的は、アプリケーション向けにオペレーティングシステム機能を拡張する方法を提供することである。

　手短に述べれば、１つのかかる方法は、アプリケーションから１つまたは複数の２進命令を受け取るステップと、１つまたは複数の２進命令が、特定のオペレーティングシステム機能を実行する、オペレーティングシステムへのコールに対応するかどうかを判定するステップと、特定のオペレーティングシステム機能をアプリケーション向けに変更すべきかどうかを判定するステップと、特定のオペレーティングシステム機能をアプリケーション向けに変更すべき場合、変更された機能を実施するコードを実行するステップと、を含む。

　本発明の別の実施形態は、アプリケーション向けにオペレーティングシステム機能を拡張するシステムを包含することができる。
　手短に述べれば、１つのかかるシステムは、アプリケーションから１つまたは複数の２進命令を受け取る手段と、特定のオペレーティングシステム機能を実行する、オペレーティングシステムへのコールを特定する手段と、特定のオペレーティングシステム機能をアプリケーション向けに変更すべきかどうかを判定する手段と、変更された機能を実施する手段と、を備える。

　本発明の別の実施形態は、システムコールインタセプト機能およびコアを備えるアプリケーション向けにオペレーティングシステム機能を拡張するシステムを包含することができる。
　システムコールインタセプト機能は、以下を行うように構成することができる：アプリケーションから２進命令を受け取り、１つまたは複数の２進命令が、特定のオペレーティングシステム機能を実行する、オペレーティングシステムへのコールに対応するかどうかを判定し、特定のオペレーティングシステム機能をアプリケーション向けに変更すべきであるかどうかを判定する。
　コアは、変更された機能を実施するように適合されたコードを実行しキャッシュするように構成することができる。

　本発明の別の実施形態では、アプリケーションとハードウェアの間にアプリケーション向けにオペレーティングシステム機能を拡張するためのインタフェースを備えることができる。
　手短に述べれば、コンピュータ可読媒体で具現される１つのかかるインタフェースは、アプリケーションから１つまたは複数の２進命令を受け取るように構成されたロジックと、１つまたは複数の２進命令が、特定のオペレーティングシステム機能を実行する、オペレーティングシステムへのコールに対応するかどうかを判定するように構成されたロジックと、特定のオペレーティングシステム機能をアプリケーション向けに変更すべきかどうかを判定するように構成されたロジックと、特定のオペレーティングシステム機能をアプリケーション向けに変更すべき場合、変更された機能を実施するコードを実行するように構成されたロジックと、を備える。

　本発明によれば、アプリケーション向けにオペレーティングシステム機能を拡張する方法を提供することができる。

　概して、アプリケーション向けにオペレーティングシステム機能を拡張かつ／または変更する各種システムおよび方法について述べる。
　詳細に後述するように、アプリケーションは、動的実行レイヤインタフェース（ＤＥＬＩ）を介してオペレーティングシステム機能の拡張および／または変更の呼び出しが可能になる。
　他のシステム例は、２００１年８月８日付けで出願された「Dynamic Execution Layer Interface for Explicitly or Transparently Executing Application or System Binaries」と題する米国特許出願第０９／９２４，２６０号（代理人整理番号１００１１５２５−１）に記載されている。
　システム例について説明した後、システムの動作例を提示して、プログラムバイナリの実行用へのオペレーティングシステム機能の拡張および／または変更を行うことのできる様式について説明する。

　図３は、アプリケーション１０２向けにオペレーティングシステム機能を拡張かつ／または変更するシステム３００の実施形態を示すブロック図である。
　図３に示すように、システム３００は、１つまたは複数のアプリケーション１０２とハードウェア１０６との間に常駐する動的実行レイヤインタフェース（ＤＥＬＩ）３０２を備える。
　当業者は、以下の説明を参照することにより、システム３００がＤＥＬＩ３０２を利用して１つまたは複数のオペレーティングシステム１０４に関連する機能を拡張かつ／または変更することを認めよう。

　図３にさらに示すように、アプリケーション１０２は、インタフェース３０８を介してＤＥＬＩ３０２と通信することができる。
　ＤＥＬＩ３１２は、インタフェース３１２を介してハードウェア１０６と通信することができる。
　ＤＥＬＩ３０２は、Ｏ／Ｓインタセプトモジュール３０４と、１つまたは複数のコードキャッシュ３０６とを備えることができる。

　一般に、Ｏ／Ｓインタセプトモジュール３０４は、アプリケーション１０２と土台をなすオペレーティングシステムまたは動的ロードライブラリ（ＤＬＬ）との間のあらゆるインタフェース（たとえば、インタフェース３１０）をインタセプトかつ／またはオーバロードするように構成される。
　Ｏ／Ｓインタセプトモジュール３０４は、必ずしもＤＥＬＩ３０２内に組み込む必要はない。

　たとえば、他の実施形態では、Ｏ／Ｓインタセプトモジュール３０４は、ＤＥＬＩ３０２の外部に配置してもよい。
　オペレーティングシステム機能をより効率的に拡張かつ／または変更するために、ＤＥＬＩ３０２は、（オーバロード／インタセプトされたインタフェースに関連するオペレーティングシステム機能の代わりに）変更されたオペレーティングシステム機能を実施するコードをコードキャッシュ３０６に格納することができる。

　システム３００の各種実施形態のアーキテクチャ、動作、および機能について、以下に詳細に述べる。
　しかし、序章として、システム３００の全体的なアーキテクチャ、動作、および機能について図４を参照して概説する。
　ブロック４０２において、ＤＥＬＩ３０２は、アプリケーション１０２に対応する２進命令を受け取る。

　より詳細に後述するように、ＤＥＬＩ３０２は、透過モード、非透過モード、またはこれら２つを組み合わせたモードで動作することができる。
　したがって、ＤＥＬＩ３０２は、ＤＥＬＩ３０２を呼び出すアプリケーション１０２に対応する２進命令の受け取り、２進命令のフェッチ、あるいは２進命令へのアクセス権取得を行うことができる。
　ブロック４０４において、オペレーティングシステムインタセプトモジュール３０４が、２進命令によって呼び出されたオペレーティングシステム１０４へのコールをインタセプトする。
　当業者は、オペレーティングシステムインタセプトモジュール３０４が、アプリケーション１０２とオペレーティングシステム１０４との間の任意所望のインタフェース（たとえば、システムコール、ライブラリ関数等）をインタセプトするように構成し得ることを認めよう。
　当業者は、オペレーティングシステムインタセプトモジュール３０４の機能をＤＥＬＩ３０２内で具現し得るが、そうする必要はないことをさらに認めよう。

　判定ブロック４０６において、システム３００は、オペレーティングシステム１０４へのコールによって呼び出されている（ブロック４０４）特定のオペレーティングシステム機能を拡張あるいは変更すべきであるかどうかを判定する。
　オペレーティングシステム機能を拡張あるいは変更すべきではない場合、フローはブロック４０４に戻り、オペレーティングシステム１０４へのコールがインタセプトされることができる。
　一方、２進命令によって呼び出されているオペレーティングシステム機能を拡張あるいは変更すべき場合、システム３００は、オペレーティングシステム機能の代わりに変更されたオペレーティングシステム機能（たとえば、オペレーティングシステム拡張関数等）に関連するコードを実行する。

　図５は、アプリケーション１０２向けにオペレーティングシステム機能を拡張かつ／または変更する本発明によるプロセスの別の実施形態を示すフローチャートであり、この実施形態をシステム３００で実施することができる。
　再び図３を参照すると、ＤＥＬＩ３０２は１つまたは複数のコードキャッシュ３０６を備えることができる。
　当業者は、コードキャッシュ３０６を使用して、オペレーティングシステム機能を拡張あるいは変更するプロセスに関連するオーバヘッドを最小化し得ることを認めよう。

　たとえば、システム３００の動作では、アプリケーション１０２に対応する２進命令が、オペレーティングシステム１０４への特定のコールを頻繁に呼び出すことがある。
　上述したように、システム３００は、特定のシステムコールをインタセプトし、変更されたオペレーティングシステム機能（たとえば、オペレーティングシステム拡張関数等）に関連するコードを実行するように構成され得る。
　この場合、ＤＥＬＩ３０２は、たとえば、頻繁に実行されるオペレーティングシステム拡張関数（または他の関連コード）をキャッシュし、拡張関数を呼び出す元のアプリケーションコードを永久的に変換（コードキャッシュ内で）するように構成されることにより、オーバヘッドを低減することができる。

　再び図５を参照すると、ブロック５０２において、システム３００は、アプリケーション１０２に対応する２進命令をフェッチする。
　ブロック５０４において、システム３００は、２進命令によって呼び出されたオペレーティングシステム１０４へのコールをインタセプトする。
　上述したように、オペレーティングシステムインタセプトモジュール３０４は、アプリケーション１０２とオペレーティングシステム１０４の間の任意所望のインタフェース（たとえば、システムコール、ライブラリ関数等）をインタセプトするように構成され得る。

　インタセプト機構は、オペレーティングシステムインタフェースの特定の詳細により様々な方法で実施することができる。
　たとえば、ｓｙｓｃａｌｌインタフェース（たとえば、Ｍｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムに使用されるＩＮＴ２Ａ／ＩＮＴ２Ｂｘ８６命令）の実施に使用される特定の命令パターンに整合するようにインタセプトモジュールに命令することができる。
　当業者は、オペレーティングシステムインタセプトモジュール３０４の機能をＤＥＬＩ３０２内で具現し得るが、そうする必要はないことをさらに理解しよう。

　判定ブロック５０６において、システム３００は、オペレーティングシステム１０４へのコールによって呼び出されている（ブロック５０４）特定のオペレーティングシステム機能を拡張あるいは変更すべきであるかどうかを判定する。
　オペレーティングシステム機能を拡張あるいは変更すべきではない場合、フローはブロック５０２に戻る。

　一方、２進命令によって呼び出されているオペレーティングシステム機能を拡張あるいは変更すべき場合、判定ブロック５０８において、システム３００は、変更されたオペレーティングシステム機能（たとえば、オペレーティングシステム拡張関数等）に関連するコードをキャッシュするかどうかを判定する。
　コードキャッシュ３０６にコードがキャッシュされている場合、ブロック５１０において、システム３００がコードキャッシュ３０６からのコードを実行し、フローはブロック５０２に続く。

　変更されたオペレーティングシステム機能に関連するコードがキャッシュされていない場合、システム３００はコードを実行し（ブロック５１２）、コードキャッシュ３０６に格納することができる（ブロック５１４）。
　変更されたオペレーティングシステム機能に関連するコードを実行し格納した後、フローはブロック５０２に続くことができる。

　再び図３を参照すると、ＤＥＬＩ３０２は、高水準または低水準言語で書かれた汎用ソフトウェアレイヤを備える。
　ＤＥＬＩ３０２は、オペレーティングシステム（Ｏ／Ｓ）１０４を含むかまたは含まないアプリケーション１０２とハードウェア１０６との間に常駐して、アプリケーションバイナリコードをハードウェア１０６から切り離す。

　この構成を通して、ＤＥＬＩ３０２は、エミュレーション、動的変換および最適化、透過的リモートコード実行、仮想ハードウェア環境プログラムのためのコンピュータシステム機能の再マッピング、コード伸張、コード解読等、多種多様な異なるアプリケーションで使用することのできる動的コンピュータプログラムコード変換、キャッシング、およびリンキングサービスを提供することができる。
　以下にさらに詳細に考察するように、ＤＥＬＩ３０２は、透過モード、非透過モード、またはこれら２つを組み合わせたモードで動作しながらサービスを提供することができる。

　透過モードでは、ＤＥＬＩ３０２は、実行中のプログラムが、コンピュータハードウェア上で直接実行されていないことに気付かないようにプログラムの実行を自動的に制御する。
　非透過モードでは、ＤＥＬＩ３０２は、アプリケーションプログラミングインタフェース（ＡＰＩ）を通してサービスをアプリケーションにエクスポートして、ＤＥＬＩ３０２が特定のシステムイベントに対してどのように反応するかをアプリケーションが制御できるようにする。

　図３に示すように、ＤＥＬＩ３０２は、少なくとも１つのアプリケーション１０２とコンピュータハードウェア１０６との間に常駐する。
　特定の構成によっては、アプリケーション１０２は、ＤＥＬＩの存在を知らない１つまたは複数のユーザアプリケーションおよび／またはＤＥＬＩ３０２の存在を知りＤＥＬＩのサービスを利用するように構成されたクライアント（たとえばエミュレータ）を有することができる。

　しかしながら、より一般的には、アプリケーション１０２は、コンピュータプロセッサによって実行される命令を含むあらゆるタイプのプログラムコードを含む。
　Ｏ／Ｓが使用される場合、ＤＥＬＩ３０２は、提供されるサービスの性質によって、Ｏ／Ｓの上位かまたは下位のいずれに常駐してもよい。
　たとえば、ＤＥＬＩ３０２がＯ／Ｓの上位で動作する場合、ＤＥＬＩ３０２が制御可能なのはアプリケーションの実行のみである。

　一方、ＤＥＬＩ３０２は、Ｏ／Ｓの下位で動作する場合、Ｏ／Ｓ１０４およびアプリケーション１０２の両方からのシステムコードおよびユーザコードの混合を含むことができる命令ストリームにアクセスすることができる。
　ハードウェア１０６は、あらゆる異なるコンピュータシステムコンポーネントを備えることができるが、通常少なくともコンピュータプロセッサを備える。

　図６を参照すると、ＤＥＬＩ３０２は、コア６０６と、アプリケーションプログラミングインタフェース（ＡＰＩ）６０８と、透過モードレイヤ６１０と、システム制御・構成レイヤ６１２と、を含む４つの主なコンポーネントを含むことができる。
　上述したように、実施形態によっては、ＤＥＬＩ３０２はＯ／Ｓインタセプトモジュール３０４を備えることができる。

　概して、コア６０６は、２つの主なサービスをＡＰＩ６０８および透過モードレイヤ６１０の両方にエクスポートする。
　これらサービスのうちの第１のサービスは、ハードウェア１０６の命令セットに対応するネイティブコードフラグメントまたはコードフラグメントのキャッシングおよびリンキングに関連する。

　第２のサービスは、先にキャッシュされたコードフラグメントを実行することに関連する。
　ＡＰＩ６０８は、アプリケーション１０２から、動作の非透過モードでコア６０６のキャッシングおよびリンキングサービスへのアクセスを提供する機能をエクスポートする。
　透過モードレイヤ６１０によって、コア６０６は、動作の透過モードでのコード実行に対する制御を透過的に取得するとともにキャッシュされるコードフラグメントをフェッチすることができる。

　最後に、システム制御・構成レイヤ６１２は、たとえばコードのキャッシング、リンキングおよび最適化のためのポリシーを含む、コア６０６の動作に対するポリシーを提供することによって、ＤＥＬＩ３０２の構成を可能にする。
　これらポリシーは、たとえば、アプリケーション１０２からＡＰＩ６０８を介してレイヤ６１２に提供することができる。
　システム制御・構成レイヤ６１２はまた、ＤＥＬＩ３０２の透過モードをイネーブルにするか否かを制御し、それによってコア６０６が入力をＡＰＩ６０８から受け取るか、透過モードレイヤ６１０から受け取るか、それとも両方から受け取るかが決まる。

　システム３００はバイパスパスを備えることができる。
　アプリケーション１０２は、所望の場合バイパスパスを使用してＤＥＬＩ３０２をバイパスすることができ、したがって、アプリケーションをハードウェア１０６上で直接実行することができる。
　なお、かかる動作は、ＤＥＬＩ３０２が利用されてもされなくてもよい任意の実行レイヤであるため、可能とすることができることを留意されたい。

　図６に示すように、コア６０６は、コアコントローラ６１６と、キャッシュマネージャ６１８と、フラグメントマネージャ６２０と、最適化マネージャ６２２と、を備える。
　コアコントローラ６１６は、タスクを、それらタスクを完了する責任を有するコア６０６の他のコンポーネントに割り当てるディスパッチャとして機能する。
　キャッシュマネージャ６１８は、フラグメントマネージャ６２０および最適化マネージャ６２２と共に、システム制御・構成レイヤ６１２によって指定されるポリシーに従って、１つまたは複数のコードキャッシュ３０６（たとえば、キャッシュ１〜ｎ）内のコードフラグメントのキャッシングを制御する機構（たとえば、アルゴリズムセット）を備える。

　コア６０６の１つまたは複数のコードキャッシュ３０６は、たとえば、ハードウェア１０６の１つまたは複数のプロセッサのハードウェアキャッシュに配置することができ、あるいは、ハードウェアのメインローカルメモリにおいて生成することができる。
　コードキャッシュ３０６が、プロセッサ上のハードウェアキャッシュにマッピングされる場合、命令キャッシュリフィルオーバヘッドの低減、メモリ帯域幅の増大等により、パフォーマンスを大幅に増大することができる。

　フラグメントマネージャ６２０は、コードキャッシュ３０６内のコードフラグメントの構成とフラグメントに対して行う変換のタイプとを指定する。
　最後に、最適化マネージャ６２２は、コードフラグメントに対しそれらの実行を最適化するために適用することができる最適化のセットを含む。

　上述したように、ＡＰＩ６０８は、アプリケーション１０２から、ＤＥＬＩサービスへのアクセスを提供する機能をエクスポートする。
　より詳細には、ＡＰＩ６０８は、通常ＤＥＬＩの存在を知るクライアントを構成するアプリケーション１２０に対して、コア６０６のキャッシングおよびリンキングサービスをエクスポートする。
　ＡＰＩ６０８によってエクスポートされるこれらサービスにより、アプリケーション１０２は、（ｉ）キャッシングのためにコードフラグメントをコア６０６に明示的に放出することによりおよび／または（ｉｉ）ＤＥＬＩ３０２に対しそのコードキャッシュ３０６からの特定のコードフラグメントを実行するように命令することにより、非透過モードでのＤＥＬＩ３０２の動作を制御することができる。

　さらに、ＡＰＩ６０８はまた、ＤＥＬＩ３０２の動作を開始および中断する関数もエクスポートすることができる。
　たとえば、ＡＰＩ６０８は、ＤＥＬＩ３０２の透過的な動作を開始することができ、さらにＤＥＬＩがかかる動作をいつ終了するかを指示することができる。

　ＡＰＩ６０８はまた、上述したように、アプリケーション１０２によって指定されるポリシーをコア６０６に（たとえば、フラグメントマネージャ６０２および／または最適化マネージャ６２２に）引渡すことにより、ＤＥＬＩ３０２の構成を容易にする。
　非透過モードでの動作を容易にする際のＡＰＩ６０８の使用法については、図９に関連して以下に述べる。

　図６をさらに参照すると、透過モードレイヤ６１０は通常、実行中のアプリケーション１０２に対する制御を透過的に取得するために使用されるインジェクタ（injector）６２６を有する。
　ＤＥＬＩ３０２が完全透過モードで動作する時（すなわち、アプリケーションがＤＥＬＩの存在を知らない場合）、インジェクタ６２６を使用して、アプリケーションが実行を開始する前にＤＥＬＩをアプリケーション１０２に投入し（inject）、それによってアプリケーションがＤＥＬＩの制御下で動作できるようにする。
　かかる環境では、ＤＥＬＩ３０２は、アプリケーション１０２の実行可能イメージの変更を避けて、例外処理の妨害を避ける。

　制御は、インジェクタ６２６によりいくつかの異なる方法で取得することができ、こういった各方法では、アプリケーションバイナリを、バイナリがロードされる仮想アドレスを変更することなくロードする。
　例として、Ｏ／Ｓカーネルローダを変更することができ、それによってＤＥＬＩ３０２（たとえば、共有ライブラリとしてコンパイルされる）が、カーネルローダによりアプリケーションの実行可能イメージをロードする時に自動的にロードされる。
　代替的に、ユーザレベルローダを使用して、カーネルローダを変更することなく利用してアプリケーション１０２をサスペンドモードでメモリにロードし、後にアプリケーションに（たとえば、アプリケーションスタックに）命令を投入することができ、アプリケーションが再開される時に、ＤＥＬＩ３０２共有ライブラリをロードする。

　他の代替例では、アプリケーション１０２にＤＥＬＩ３０２を添付するためにｐｔｒａｃｅを使用することができる。
　当技術分野において既知であるように、ｐｔｒａｃｅは、あるプロセスが別のプロセスを制御可能にする、デバッガによって使用されることが多い機構である。

　ＤＥＬＩ３０２は、ｐｔｒａｃｅを介してアプリケーション１０２に添付する別個のプロセスとして構成することができ、アプリケーションのバイナリイメージの最上部の実行スタートアップコード（たとえば、ｃｒｔ０）がアプリケーションのエントリポイントを呼び出そうとする時点まで、アプリケーションを実行する。
　その後、アプリケーション１０２の実行を中断することができ、ＤＥＬＩ３０２を使用してアプリケーション命令をフェッチしアプリケーション１０２に代わってそのアプリケーション命令を実行することができる。

　さらに別の代替例では、アプリケーションのテキストセグメントを、実行可能ファイルの別個のコピーに展開することができる。
　特に、アプリケーションのバイナリイメージを一時的な場所にコピーすることができ、ＤＥＬＩテキストセグメントを最後に追加することによりアプリケーションのテキストセグメントを拡張することができ、開始シンボル（すなわち、ｃｒｔ０と呼ばれるエントリポイント）をＤＥＬＩエントリポイントに変更することができる。

　そして、その結果である実行可能ファイルを、ｅｘｅｃを使用して実行することができる。
　オリジナルアプリケーションのテキストセグメントは依然として、それが通常有するものと同じ仮想アドレスにロードされているが、ＤＥＬＩ３０２は、実際のアプリケーション１０２が開始する前に制御を取得する。

　別の例では、ＤＥＬＩ３０２は、ｃｒｔ０の特別なバージョンを使用してアプリケーション１０２に対する制御を取得することができる。
　当分野において既知のように、ｃｒｔ０コードは、コマンドライン引数のピックアップ、初期スタックおよびデータセグメントのセットアップ、次に開始シンボル（通常、アプリケーション１０２のｍａｉｎ（　）関数）の値のコール実行の責任を負う。

　アプリケーション１０２のエントリポイントを呼び出す前に、ｃｒｔ０は、動的リンクローダｄｌｄをマッピングし、次に、動的リンクローダｄｌｄが、アプリケーション１０２によって参照されるあらゆる動的リンクライブラリ（ＤＬＬ）をロードする。
　ｃｒｔ０のカスタムバージョンを使用して、さらにＤＥＬＩコード（それ自体ＤＬＬとしてコンパイルされる）をマッピングし、開始シンボルによって定義されるエントリポイントの代わりにＤＥＬＩのエントリポイントを呼び出すことができる。

　アプリケーション１０２に対する制御が取得される方法に関りなく、その後命令フェッチコントローラ６２８を使用して、アプリケーションバイナリコードのフラグメント（たとえば、トレース）のコピーを抽出し（すなわち、フェッチし）、それらをキャッシュするためにＤＥＬＩコア６０６に渡し、コア６０６に対してそのコードキャッシュ３０６から適当なキャッシュ済みコピーを実行するよう命令することができる。
　かかる動作を容易にするための透過モードレイヤ６１０の使用については、図１０に関連して以下に説明する。

　本明細書では、ＤＥＬＩ３０２を、透過モードレイヤ６１０を有するように図示し説明したが、当業者は、本開示全体を見ることにより、ＤＥＬＩの動作がＡＰＩ６０８を介してアプリケーション１０２（すなわち、クライアント）によってのみ制御される場合、このレイヤを完全に省略してよいことを認めるであろうことが留意される。

　上述したように、システム制御・構成レイヤ６１２は、コードのキャッシングおよびリンキングのポリシーを提供することによりＤＥＬＩ３０２の構成を可能にする。
　ＤＥＬＩ３０２はいかなる特定のタイプのポリシーまたはポリシー内容にも限定されないが、ポリシーは通常、ＤＥＬＩがいかに挙動するかを決める。
　たとえば、レイヤ６１２は、コードのフラグメントがアプリケーション１０２からいかに抽出されるか、オリジナルコードからいかにフラグメントが生成されるか、より大きいコードフラグメントを形成するためにいかに複数のコードフラグメントを互いにリンクすることができるか等に関するポリシーを提供してよい。

　レイヤのポリシーは、静的とも動的ともすることができる。
　前者の場合、構築時に構成を固定することにより、ポリシーをＤＥＬＩ３０２にハードコード化することができる。
　後者の場合、ポリシーを、アプリケーション１０２によりＡＰＩ６０８における関数呼び出しを介して動的に提供することができる。

　ポリシーの実施は、ＤＥＬＩ３０２が特定のシステムおよび／またはハードウェアイベント（たとえば、例外および割込み）に反応する様式を制御する。
　上述したポリシーに加えて、システム制御・構成レイヤ６１２は、コードキャッシュ３０６のサイズ、ログファイルが生成されるか否か、コードフラグメントが最適化されるべきか否か、等を指定することができる。

　システム制御・構成レイヤ６１２は、さらに、システムおよびハードウェア機能に向けられたアプリケーションバイナリコードの命令をインタセプトすることにより、システムおよびハードウェア機能の抽象化をサポートする。
　そして、これら命令は、フラグメントマネージャ６２０により、システム制御・構成レイヤ６１２の命令下でフラグメント形成プロセスの一部として置き換えられる。
　システム制御・構成レイヤ６１２は、欠損したまたは欠陥のあるハードウェアに向けられた命令を識別し、フラグメントマネージャ６２０に対してそれらを、同様であるが異なるハードウェア１０６に向けられた対応する命令か、あるいはオリジナルハードウェアのソフトウェアシミュレーションと置き換えさせる。

　上述したように、ＤＥＬＩ３０２は、Ｏ／Ｓインタセプトモジュール３０２、Ｏ／Ｓインタセプトモジュール３０４を備えることができる。
　当業者は、オペレーティングシステムインタセプトモジュール３０４が、アプリケーション１０２とオペレーティングシステム１０４との間の任意所望のインタフェース（たとえば、システムコール、ライブラリ関数等）をインタセプトするように構成してよいことを認めよう。

　図７は、コア６０６の構成例および動作を示す。
　この図に示すように、コア６０６は、ＡＰＩ６０８または透過モードレイヤ６１０から２つのタイプの要求を受け入れる。
　第１に、関数インタフェースを介してコードフラグメントをキャッシュしリンクする要求７００を受け入れることができる。

　かかる要求は、たとえば「ＤＥＬＩ＿ｅｍｉｔ＿ｆｒａｇｍｅｎｔ（ｔａｇ，ｆｒａｇｂｕｆ）」という形態の関数を含むことができる。
　この関数は、コードフラグメントを、ＤＥＬＩキャッシュ３０６に格納するためのパラメータおよび識別子（たとえば、タグ）として受け取る。
　さらに、コア６０６は、キャッシュ３０６に格納され実行するためにハードウェア１０６に渡されるコードフラグメントを識別する、「ＤＥＬＩ＿ｅｘｅｃｕｔｅ＿ｆｒａｇｍｅｎｔ（ｔａｇ）」等の関数インタフェースを介して、特定のコードフラグメントタグにおいて実行を開始する要求を受け入れる。

　コアコントローラ６１６はこれら要求を処理して適当なコアモジュールにディスパッチする。
　そして、所与の識別子を有するコードフラグメントの放出に対する要求７０２を、フラグメントマネージャ６２０に渡すことができる。
　フラグメントマネージャ６２０は、フラグメント形成ポリシー７０４に従ってコードフラグメントを変換し、ことによると、そのインスツルメンテーション（instrumentation）ポリシー７０６に従ってコードフラグメントをインスツルメント（instrument）し、そのコードフラグメントをそのフラグメントリンキングポリシー７０８に従って先にキャッシュされたフラグメントとリンクする。

　たとえば、フラグメントマネージャ６２０は、キャッシュ３０６内で複数のコードフラグメントをリンクしてよく、それによって実行がコードフラグメントの実行の最後に別のコードフラグメントにジャンプするようになり、そのためキャッシュからの実行の長さが増大する。
　これを達成するために、フラグメントマネージャ６２０は、キャッシュマネージャ６１８に対してフラグメント割付命令７１０を発行する。
　そして、フラグメントマネージャ６２０は、キャッシュマネージャ６１８に対し、コードキャッシュ３０６の処理済みコードフラグメントを割付ける要求を送信する。

　キャッシュマネージャ６１８は、コードフラグメントの割付を制御するものであり、通常はキャッシュ空間を管理するそれ自体のキャッシュポリシー７１２を備えている。
　しかしながら、フラグメントマネージャ６２０はまた、キャッシュマネージャ６１８に対して特定のフラグメント割付解除命令７１４も発行してもよい。

　たとえば、フラグメントマネージャ６２０は、現フラグメントを先に割付けたフラグメントと統合するよう決定してよく、その場合、先のフラグメントは割付解除される必要がある場合がある。
　構成によっては、キャッシュマネージャ６１８とフラグメントマネージャ６２０とは、コードキャッシュ３０６およびコードフラグメントを、２００１年５月２２日に発行され、「A Preemptive Replacement Strategy for a Caching Dynamic Translator Based on Changes in the Translation Rate」と題された米国特許第６，２３７，０６５号に図示され記載される方法で管理することができる。
　代替的に、コードキャッシュ３０６およびコードフラグメントは、２００１年１月５日に出願され、「A Partitioned Code Cache Organization to Exploit Program Locality」と題された米国特許出願第０９／７５５，３８９号に図示され記載される方法で実行されてもよい。

　フラグメントマネージャ６２０は、フラグメントをキャッシュマネージャ６１８に渡す前に、フラグメントを最適化マネージャ６２２に渡すことにより（７１６）、その最適化ポリシー７１８に従ってコードフラグメントの品質を向上させてよい。
　構成によっては、最適化マネージャ６２２は、コードフラグメントを、２００１年１月５日に出願され、「A Fast Runtime Scheme for Removing Dead Code Across Linked Fragments」と題された米国特許出願第０９／７５５，３８１号に図示され記載されている方法で最適化してよい。

　代替として、最適化マネージャ６２２は、２００１年１月５日に出願され、「A Memory Disambiguation Scheme for Partially Redundant Load Removal」と題された米国特許出願第０９／７５５，７７４号に図示し記載される方法でコードフラグメントを最適化してよい。
　特に、最適化マネージャ６２２はまた、冗長計算の削除、冗長メモリアクセスの削除、プロシージャコール／リターンオーバヘッドを除去するインライン化関数等、以前からあるコンパイラ最適化技法を使用して、コードフラグメントを最適化してもよい。

　上述したように、フラグメントマネージャ６２０は、そのフラグメント形成ポリシー７０４に従ってコードフラグメントを変換する。
　フラグメントマネージャ６２０によって実行される変換は、たとえば、相対アドレス、分岐アドレス等を変更することによりメモリアドレス参照を変化させることによる、コード再配置を含むことができる。

　コードフラグメントのレイアウトはまた、コードの物理レイアウトをその機能（すなわち、セマンティック）を変化させることなく変化させて、変更してもよい。
　これら変換は、フラグメントマネージャ６２０により、ＡＰＩ６０８を通しておよび命令フェッチコントローラ６２８から受け取られるフラグメントに対して実行される。

　コードインスツルメンテーションを実行するために、フラグメントマネージャ６２０は、コードフラグメントの実行の頻度、メモリアドレスがアクセスされる頻度等に関するデータ等、コードプロファイリングのためのインスツルメンテーションポリシー７０６に従ってデータを収集する。
　フラグメント形成または割付解除を容易にするために、プログラムカウンタを使用してこれら統計値を収集することができる。

　これらポリシーは、ＡＰＩ６０８を介して送信されるかまたはＤＥＬＩ構築時に確立されるポリシー命令を受け取る、システム制御・構成レイヤ６１２によって構成される。
　ポリシーは、フラグメントを生成し、インスツルメントし、最適化し、リンクするために、異なる方法に対するオプションを含んでよく、あるいは、ポリシーは、単に、これらタスクを実行するためのＤＥＬＩ３０２内のハードコード化アルゴリズムであってよい。

　ＤＥＬＩコア６０６によって受け入れられる第２のタイプの要求は、所与の識別子（たとえば、タグ）によって識別されるフラグメントを実行する要求７２０である。
　かかる場合、コアコントローラ６１６は、フラグメントマネージャ６２０に対してルックアップ要求７２２を発行し、フラグメントマネージャ６２０は、フラグメントがキャッシュ３０６に目下存在しアクティブである場合、対応するコードキャッシュアドレス７２４を返す。
　例として、フラグメントマネージャ６２０は、コードフラグメントの位置を識別するためにタグを使用することができる、存在しアクティブなコードフラグメントのルックアップテーブルを維持することができる。

　代替的に、フラグメントマネージャ６２０またはキャッシュマネージャ６１８は、コードフラグメントが存在しアクティブであるか否かを追跡する他のいかなる適当な技法も使用することができる。
　フラグメントがキャッシュ３０６に目下存在せずアクティブでない場合、フラグメントマネージャ６２０は、コアコントローラ６１６に対してエラーコードを返し、コアコントローラ６１６は、最初の要求側にフラグメントタグをキャッシュミスアドレスとして返す（７２６）。
　一方、フラグメントが目下存在しアクティブである場合、コアコントローラ６１６は、キャッシュマネージャ６１８に対し最初の要求をそのキャッシュアドレスとともにパッチする（７２８）。

　それによって、キャッシュマネージャ６１８は、そのコードキャッシュ３０６におけるアドレス指定されたコードフラグメントに制御を引渡すことによって、アドレス指定されたコードフラグメントを実行する。
　そして、キャッシュミスが発生するまで、すなわち実行される次のアプリケーションアドレスに対するコピーがキャッシュに目下存在しなくなるまで、実行はコードキャッシュ３０６に注目し続ける。

　上記状態は、たとえば実行中のコードがコードキャッシュ３０６から退避しようとすることによって検出することができる。
　キャッシュミスは、キャッシュマネージャ６１８からコアコントローラ６１６に報告され（７３０）、その後最初の要求側に報告される（７２６）。

　図８は、システム３００（図３）を実行することのできるコンピュータシステム８００のアーキテクチャ例を示す略図である。
　概して、コンピュータシステム８００は、デスクトップコンピュータ、ポータブルコンピュータ、専用サーバコンピュータ、マルチプロセッサコンピューティング装置、携帯電話、個人情報端末（ＰＤＡ）、ハンドヘルドまたはペンベースコンピュータ等、多種多様な有線および／または無線コンピューティング装置のうちの任意の１つを構成することができる。
　コンピュータシステム８００は、その特定の構成に関らず、たとえば、処理装置８０２、メモリ８０４、１つまたは複数のユーザインタフェース装置８０６、ディスプレイ８０８、１つまたは複数の入出力（Ｉ／Ｏ）装置８１０および１つまたは複数のネットワーキング装置８１２を備えることができ、これらはそれぞれ、ローカルインタフェース８１４に接続される。

　処理装置８０２は、カスタムメイドもしくは市販のプロセッサと、コンピュータシステム８００と関連するいくつかのプロセッサ中の中央処理装置（ＣＰＵ）もしくは補助プロセッサと、半導体ベースのマイクロプロセッサ（マイクロチップの形態）と、マイクロプロセッサと、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）と、複数の適当に構成されたデジタル論理ゲートと、個別にかつあらゆる組合せでコンピューティングシステムの動作全体を調整するための個別要素を備えた、他の既知の電気的構成と、を含むことができる。

　メモリ８０４は、揮発性メモリ素子（たとえば、ランダムアクセスメモリ（ＤＲＡＭ、ＳＲＡＭ等のＲＡＭ））と不揮発性メモリ素子（たとえば、ＲＯＭ、ハードドライブ、テープ、ＣＤＲＯＭ等）との組合せのうちの任意の１つを含むことができる。
　通常、メモリ８０４は、Ｏ／Ｓ１０４と、１つまたは複数のアプリケーション１０２（たとえば、ユーザアプリケーションおよび／またはクライアント）と、すでに詳細に説明したＤＥＬＩ３０２と、を含む。
　当業者は、メモリ８０４が簡潔にする目的のために省略した他のコンポーネントを含むことができる（通常は含む）ことを認めよう。

　１つまたは複数のユーザインタフェース装置８０６は、ユーザがコンピューティングシステム８００と対話することができるコンポーネントを備える。
　たとえば、コンピューティングシステム８００がパーソナルコンピュータ（ＰＣ）を構成する場合、これらコンポーネントはキーボードとマウスを含むことができる。

　コンピューティングシステム８００がハンドヘルド装置（たとえば、ＰＤＡ、携帯電話）を構成する場合、これらコンポーネントは、ファンクションキーまたはボタン、タッチセンシティブスクリーン、スタイラス等を含むことができる。
　ディスプレイ８０８は、ＰＣの場合はコンピュータモニタまたはプラズマスクリーン、またはハンドヘルド装置の場合は液晶ディスプレイ（ＬＣＤ）を含むことができる。

　図８をさらに参照すると、１つまたは複数のＩ／Ｏ装置８１０は、コンピューティングシステム８００の別のシステムおよび／または装置への接続を容易にするように適合されているため、１つまたは複数のシリアル、パラレル、小型コンピュータシステムインタフェース（ＳＣＳＩ）、ユニバーサルシリアルバス（ＵＳＢ）、ＩＥＥＥ１３９４（たとえば、Ｆｉｒｅｗｉｒｅ（登録商標））および／またはパーソナルエリアネットワーク（ＰＡＮ）コンポーネントを含んでよい。
　ネットワークインタフェース装置８１２は、ネットワークを介してデータを送信および／または受信するために使用されるあらゆるコンポーネントを備える。
　例として、ネットワークインタフェース装置８１２は、入力と出力とをともに通信することができる装置、たとえば変調器／復調器（たとえば、モデム）、無線（たとえば、無線周波数（ＲＦ））送受信機、電話インタフェース、ブリッジ、ルータ、ネットワークカード等を含む。

　本明細書では、あらゆるソフトウェアおよび／またはファームウェアを説明した。
　このソフトウェアおよび／またはファームウェアを、任意のコンピュータ関連システムまたは方法によるかまたはそれと関連して使用するために、任意のコンピュータ可読媒体に格納することができることが理解されなければならない。
　この文書の文脈において、コンピュータ可読媒体は、コンピュータ関連システムまたは方法によるかまたはそれと関連して使用されるコンピュータプログラムを内蔵するかまたは格納することができる、電子、磁気、光あるいは他の物理装置または手段を示す。

　これらプログラムは、コンピュータベースシステム、プロセッサ内蔵システム、あるいは命令実行システム、機器または装置からの命令をフェッチしそれら命令を実行することができる他のシステム等の、命令実行システム、機器または装置によるかまたはそれと関連して使用されるために、任意のコンピュータ可読媒体において具体化することができる。
　本文書の文脈において、「コンピュータ可読媒体」は、命令実行システム、機器または装置によるかまたはそれに関連して使用されるプログラムを格納し、通信し、伝播し、または移送することができるいかなる手段ともすることができる。

　たとえば、コンピュータ可読媒体は、限定されないが、電子、磁気、光、電磁気、赤外線または半導体のシステム、機器、装置または伝播媒体とすることができる。
　コンピュータ可読媒体のより特定の例（非網羅的リスト）には、１つまたは複数のワイヤを有する電気的接続、ポータブルコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能プログラム可能リードオンリメモリ（ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリ）、光ファイバおよびポータブルコンパクトディスクリードオンリメモリ（ＣＤＲＯＭ）が含まれる。

　なお、コンピュータ可読媒体は、プログラムが印刷された用紙または他の適当な媒体とすることもできる。
　それは、プログラムを、たとえば用紙または他の媒体の光学的走査により電子的に取込み、その後、コンパイルし、解釈しまたは必要であれば他の適当な方法で処理した後、コンピュータメモリに格納することができるためである。

　ＤＥＬＩ３０２の一般的な性質について上で説明したが、これより図９および図１０を参照してＤＥＬＩの動作の実施例について説明する。
　上述したように、ＤＥＬＩ３０２は、２つの一般的な動作モード、すなわち透過モードおよび非透過モードで、またそれらを組合せたモードで動作する。
　これらモードでの動作を説明するためにフローチャートを提供する。

　フローチャートにおけるいずれのプロセスステップまたはブロックも、プロセスにおける特定の論理関数またはステップを実施するための１つまたは複数の実行可能命令を含む、モジュール、セグメントまたはコードの一部を表すことは理解されなければならない。
　特定のプロセスステップ例を示すが、代替の実施形態も可能であることが認められよう。
　さらに、ステップは、関係する機能により、実質的に同時かまたは逆の順序を含む、示しまたは説明する順序ではない順序で実行されてもよい。

　概して、ＤＥＬＩ３０２が透過的にかまたは非透過的にアプリケーション１０２の実行に対する制御を取得したか否かに関らず、アプリケーションは、ハードウェア１０６に対して直接には実行しない。
　むしろ、アプリケーションコードは、コードキャッシュ３０６に保持されてよいコードフラグメントの形態でＤＥＬＩ３０２を通して実行する。

　図９は、透過モードでのＤＥＬＩ動作の単純な実施例を示す。
　より詳細には、図９は、アプリケーション１０２がＤＥＬＩの存在を知らない完全透過モードでのＤＥＬＩの動作を示す。
　ブロック９０２から始まり、ＤＥＬＩ３０２がまず開始される。
　透過モードで動作している場合、この開始は、アプリケーション１０２が開始されると開始されることができる。

　その開始時、ＤＥＬＩ３０２は、ブロック９０４に示すように、透過モードレイヤ６１０のインジェクタ６２６によってアプリケーション１０２に投入され、それによってＤＥＬＩはアプリケーションとその実行とに対する制御を取得する。
　上述したように、この制御を取得することができる方法には様々ある。

　ＤＥＬＩ３０２がアプリケーション１０２に対する制御を取得すると、ＤＥＬＩを使用して、上述したもの等のいくつかの異なるサービスのうちの任意の１つを提供することができる。
　たとえば、ＤＥＬＩ３０２は、ハードウェアおよび／またはソフトウェアエミュレーション、動的変換および最適化、透過的リモートコード実行、仮想ハードウェア環境プログラムのためのコンピュータシステム機能の再マッピング、コード伸張、コード解読等を容易にすることができる。

　これら異なるサービスは、それぞれコードキャッシュ３０６内のプログラムコードフラグメントのキャッシングおよびリンキングを含む。
　アプリケーションバイナリからコピーされるコードのいくつかのフラグメントをキャッシュし、それらを何らかの方法で変換することにより、後にコードキャッシュ３０６からの変換済みコードを実行することによって所望のサービスを提供することができる。

　ＤＥＬＩ３０２は、コードをキャッシュする前に、コードのいずれの特定のフラグメントをキャッシュするかを確定しなければならない。
　完全透過モードで動作している場合、アプリケーション１０２はＤＥＬＩ３０２を知らないことから、ＤＥＬＩは、いずれのコードフラグメントをキャッシュするかに関しアプリケーションから指示を受け取らない。

　コードのキャッシングを、ＤＥＬＩ構築時に生成されたポリシーを通して指示することができるが、より好ましくは、ＤＥＬＩ３０２は、少なくとも部分的にこれらの確定を単独で行う能力を有する。
　ＤＥＬＩ３０２は、これを、ブロック９０６に示すように、アプリケーション１０２によるコードの実行を監視することによって行うことができる。
　そのように行う際に、ＤＥＬＩ３０２は、たとえばいずれのフラグメントが最も頻繁に使用されるかを判定することにより、たとえばいずれのコードフラグメントがアプリケーション１０２に対して最も有用であるかに関する情報を収集することができる。

　ＤＥＬＩ３０２の制御下でアプリケーション１０２によりあらゆるコードフラグメントが実行される際に、ＤＥＬＩは、実行されるコードの各部を「見る（sees）」。
　したがって、ＤＥＬＩ３０２は、監視プロセスを通して、いずれのコードフラグメントが最も頻繁に使用されるかを判定することができる。
　そして、ＤＥＬＩ３０２は、コードのいずれの部分が「ホット（hot）」である、すなわち、システム制御・構成レイヤ６１２によって提供されるポリシーに関してアプリケーション実行に最も重要であるかの判定を行うことができる。

　上述したように、この判定は、実行インスタンスを追跡するプログラムカウンタを使用して行うことができる。
　当業者は、コードのいずれの部分がホットであるかを判定するためにあらゆる他の方法を使用することができることを認めよう。
　この判定を行うことができる方法の例は、１９９８年１１月５日に出願され、「Method for Selecting Active Code Traces for Translation in a Caching Dynamic Translator」と題された、米国特許出願第０９／１８６，９４５号と、１９９９年５月１４日に出願され、「Low Overhead Speculative Selection of Hot Traces in a Caching Dynamic Translator」と題された米国特許出願第０９／３１２，２９６号と、に記載されている。

　図９をさらに参照すると、各コードフラグメントが実行される際に、ＤＥＬＩ３０２は、判定要素９０８に示すように、関連するコードフラグメントが先にキャッシュされているか否かを判定することができる。
　キャッシュされている場合、ＤＥＬＩ３０２は、キャッシュ済み（かつ通常は変換済み）コードを含むコードキャッシュ３０６にジャンプし、ブロック９１０に示すように、このコードが、オリジナルアプリケーションコードの代りにハードウェア１０６によって実行される。
　コードがキャッシュされているか否かの判定は、上述したように、ネイティブアプリケーションコードとコードキャッシュ３０６内でキャッシュされた類似物との関連を識別する識別子（たとえば、タグ）を参照して行うことができる。

　そして、キャッシュされていなかった（すなわち、キャッシュミス）コードに対して参照するまで、コードキャッシュ３０６に存在するコードのリンクされたフラグメントの実行を含む、キャッシュ済みコードの実行が継続する。
　判定要素４１０を参照すると、未キャッシュコードに対する参照がある場合、ＤＥＬＩ３０２はアプリケーションコードにジャンプして戻り、ブロック９１２に示すようにそのコードの実行が再開される。
　この時、ＤＥＬＩ３０２は、この実行の監視を再開することができる（ブロック９０６）。

　判定要素９０８に戻り、ＤＥＬＩ３０２が、関連するコードフラグメントがコードキャッシュ３０６に存在していないと判定した場合、フローは判定要素９１４に進み、所定のポリシーに関してコードフラグメントがホットであるか否かが判定される。
　コードがホットでない場合、フローはブロック４０４に戻り、アプリケーションコード実行の監視を継続する。
　一方、コードがホットである場合、ブロック４１６に示すように、透過モードレイヤ６１０の命令フェッチコントローラ６２８を使用してフラグメントをフェッチすることにより、コードフラグメントがコピーされる。

　この時点で、ブロック９１６に示すように、コードフラグメントを何らかの方法で変換することができる。
　さらに、キャッシュ３０６内のコードフラグメントを、コードリンキングのために確立されたポリシーに従ってリンクすることができる。
　コード変換の性質は、ＤＥＬＩ３０２が提供すべきサービスのタイプによって決まる。

　たとえば、ＤＥＬＩ３０２が単にアプリケーション実行を最適化するものである場合、この変換は、パフォーマンスを向上させるためにコードを再配置および／または再構成することを含むことができる。
　行われる変換の性質に関らず、コード構造は、土台をなすセマンティックを変更することなくある程度変更される。
　コードフラグメントが変換されると、ブロック９１８に示すように、変換済みコードをコードキャッシュ３０６にキャッシュすることができ、フローが上述したブロック９１０に進むことによって、ＤＥＬＩ３０２内で実行することができる。

　上述したように、ＤＥＬＩ３０２は、非透過モードでは別様に動作する。
　概して、ＤＥＬＩ３０２は、非透過モードで動作している場合、たとえば、アプリケーション１０２がアクセスすることができるＡＰＩ６０８の関数をエクスポートするＤＬＬまたは静的リンクモジュール（statically linked module）として動作してよい。
　非透過モードでは、アプリケーション１０２（すなわち、クライアント）は、ＤＥＬＩ３０２を知っており、ＤＥＬＩのサービスを利用するように構成される。

　最も単純な場合、クライアント（たとえば、エミュレータ）は、ＡＰＩ６０８を介してＤＥＬＩ動作のすべての態様を制御する。
　かかる場合、ＤＥＬＩ３０２を利用して、ＡＰＩ６０８を介してクライアントによって提供される明示的な命令に従ってコードをキャッシュし、リンクし、最適化することができる。
　たとえば、ＤＥＬＩ３０２に対し、アプリケーション実行中に最も頻繁に使用されると考えられるいくつかのコードフラグメントをキャッシュするように命令することができる。

　これは、たとえば、タグを識別することによりＤＥＬＩ３０２にコードの位置を提供することによって達成することができる。
　かかる場合、ＤＥＬＩ３０２は、ＡＰＩ６０８によって命令されるようにコードフラグメントを監視するのではなく記録する。
　さらに、クライアントは、ＤＥＬＩに対して適用可能なタグを識別することにより、ＡＰＩ６０８を介していずれのキャッシュ済みフラグメントを実行すべきかに関し、ＤＥＬＩ３０２に対して命令することができる。

　しかしながら、より一般的なシナリオでは、クライアントはＤＥＬＩ３０２に対しそのサービスを透過的に提供するように要求する。
　かかる場合、クライアントは、ＤＥＬＩ３０２の動作を呼び出すと共に、ＤＥＬＩがいつその動作を停止するかに関する命令を提供する。
　図１０に、このような動作の実施例を提供する。

　ブロック１００２から開始され、ＤＥＬＩ３０２が開始される。
　非透過モードでは、この開始は、「ＤＥＬＩ＿ＳＴＡＲＴ」等の開始コマンドが、ＤＥＬＩ３０２を呼出すＡＰＩ６０８によって引渡される時に発生する。
　開始されると、ブロック１００４に示すように、透過モードレイヤ６１０を起動することができ、フローは、図１０に関して上述した透過モードと同様に継続することができる。

　したがって、ＤＥＬＩ３０２は、アプリケーション（クライアント）によるコードの実行を監視し（１００６）、コードフラグメントが先にキャッシュされているか否かを判定し（１００８）、適用可能である場合はキャッシュ済みコードを実行し（１０１０）、ホットなコードフラグメントをコピーし（５１６）、コピー済みコードフラグメントを変換し（５１８）、変換済みコードフラグメントをキャッシュする（１０１８）ことができる。
　ＤＥＬＩ３０２の動作は、このように、クライアントの要求に従ってＤＥＬＩに動作を停止させる状況になるまで継続する。
　例として、この割込みは、ＡＰＩ６０８を介してＤＥＬＩ３０２に送信される関数呼び出しの最後に配置された「ＤＥＬＩ＿ＳＴＯＰ」コマンドによって達成することができる。

　上述したように、ＤＥＬＩ３０２を使用してプログラムバイナリの復号化を容易にすることができる。
　たとえば、ＤＥＬＩ３０２を使用して、圧縮プログラムコードを伸張および実行することができる。
　上述したように、現行の伸張／実行ソリューションには、たとえばシステムパフォーマンスの低下、および相対的に大容量のメモリの必要性を含む、いくつかの問題がある。

　しかしながら、こういった問題は、ＤＥＬＩ３０２を使用することにより回避することができる。
　これは、ＤＥＬＩが、コードフラグメントおよび個々の命令等、コードのごくわずかな部分を制御するためである。

　動作時、ＤＥＬＩ３０２を使用して、コードフラグメントを伸張すると共に、最も頻繁に使用されるコードフラグメントをコードキャッシュ３０６内に伸張された形態でキャッシュすることができる。
　かかる動作により、伸張されるアプリケーションコードの部分が小さくなり、そのため伸張オーバヘッドが低減し必要な利用可能システムメモリが低減する。
　さらに、最も頻繁に使用されるコードフラグメントが伸張された形態でキャッシュされるため、必要な動的伸張が著しく小さくなり、それによってパフォーマンスが向上する。

　アプリケーションバイナリの復号化および実行を行う際のＤＥＬＩ３０２の動作の一実施例を図６に示す。
　この例では、復号化サービスは、透過動作モードで提供される。
　復号化について伸張に関して説明するが、当業者は、プログラムコード解読等、他の形式の復号化を行うことができることを認めるであろう。

　ブロック６００から開始され、ＤＥＬＩ３０２が開始され、ブロック６０２に示すように、その実行に対する制御を取得するように開始する前にアプリケーション１０２に投入される。
　この制御により、ＤＥＬＩ３０２は、ブロック６０４に示すように、最終的に実行されるあらゆる圧縮されたアプリケーション命令をインタセプトすることができる。

　図９に関して説明した動作モードと同様に、ＤＥＬＩ３０２は、コードの実行を監視し、それによっていずれのコードフラグメントをキャッシュするかを判定することができる。
　したがって上述したように、ＤＥＬＩ３０２は、判定要素６０６に示すように、関連するコードフラグメントが先に伸張されキャッシュされているか否かを判定することができる。

　伸張されキャッシュされている場合、ＤＥＬＩ３０２は、伸張コードを含むコードキャッシュ３０６にジャンプし、ブロック６０８に示すように、このコードがハードウェア１０６によりオリジナルアプリケーションコードの代りに実行される。
　この場合もまた、未キャッシュコードが参照されるまで、キャッシュ済みコードの実行が継続（６１０）し、かかるコードが参照された時点で、ＤＥＬＩ３０２はアプリケーションコードおよびブロック６０４に戻るようジャンプする。

　再び判定要素６０６を参照すると、コードキャッシュ３０６に関連するコードフラグメントが存在しない場合、フローはブロック６１２に進み、命令がＤＥＬＩ３０２によって伸張され（すなわち復号化され）、それによって命令を評価することができる。
　例として、この伸張を、復号化マネージャ１３０によって行うことができる。
　この伸張（すなわち復号化）を、ＤＥＬＩ３０２の復号化マネージャ１３０によって実行されるものとして説明するが、当業者は、この関数を、代替的に、クライアントアプリケーションのソフトウェアコンポーネントかまたは土台をなすコンピューティングシステムのハードウェアコンポーネント等の別のコンポーネントによって実行することができることを認めるであろう。

　命令が伸張されると、ブロック６１４に示すように、ＤＥＬＩ３０２は、たとえば１つまたは複数の命令バッファに対し命令のコピーを生成する。
　次いで、判定要素６１６を参照すると、ＤＥＬＩ３０２は、アプリケーション命令が所定ポリシーに関してホットであるか否かを判定する。
　命令がホットでない場合、フローはブロック６１８に進み、コピーされた伸張済み命令が実行される。
　しかし命令がホットである場合、伸張済み命令は所望に応じて変換され（６２０）、次に特定機能が必要とされる時の実行のために利用可能となるように、伸張された形態でキャッシュされる（６２２）。

　かかる伸張および実行サービスもまた、ＤＥＬＩ３０２によって非透過モードで動作中に提供することができる。
　たとえば、アプリケーション１０２（すなわち、クライアント）かまたは別のコンポーネント（図示せず）を、アプリケーションコードを伸張し、最も頻繁に使用される伸張済みコードをキャッシュするためにＤＥＬＩ３０２を呼び出すように構成することができる。
　かかるシナリオでは、アプリケーション１０２によって実行されるコードが先に圧縮されたコードであることを除いて、フローは図１０に示すものと類似する。

　復号化サービスが、ＤＥＬＩ３０２によって透過モードで提供されるか非透過モードで提供されるかに関らず、システムパフォーマンスとメモリ利用とに関して、従来の方策と比較していくつかの利点を達成することができる。
　たとえば、伸張／実行サービスが提供される場合に観察することのできる伸張ペナルティは、コードの多くの部分が伸張されなければならないソフトウェアソリューションで発生するペナルティが５０％程度であるのに比して、およそ１０％である。
　メモリに関しては、アプリケーションコードの大部分が圧縮された形態のままであるため、現行のソフトウェアソリューションと比較して実行中に必要なメモリが著しく少なくなる。

　本発明の特定の実施形態を、例示の目的のために上記説明および図面において詳細に開示したが、当業者には、その変形および変更を、併記の特許請求項に示すような本発明の範囲から逸脱することなく行うことができることが理解されよう。
　たとえば、ＤＥＬＩについて復号化および実行サービスを提供するのみとして上に説明したが、あらゆる他のサービスをＤＥＬＩによって同時に提供することができることに留意されたい。
　たとえば、ＤＥＬＩによって提供される復号化および実行サービスを、たとえばクライアントによって促進されるハードウェアまたはソフトウェアエミュレーションを含む他のタスクを実行する時に利用することができる。
　本開示はかかる応用を含むものであることが意図される。

　本発明は、コンピュータのオペレーティングシステムに利用可能である。

アプリケーションとアプリケーションをサポートするオペレーティングシステムとの間にインタフェースを実施する環境を示すブロック図である。 図１の環境で実施し得る、アプリケーション向けにオペレーティングシステムの機能を拡張する既存のシステムの例を示すブロック図である。 アプリケーション向けにオペレーティングシステム機能を拡張かつ／または変更するシステムの実施形態を示すブロック図である。 図３のシステムで実施し得る、アプリケーション向けにオペレーティングシステム機能を拡張かつ／または変更するプロセスの実施形態を示すフローチャートである。 図３のシステムで実施し得る、アプリケーション用にオペレーティングシステム機能を拡張かつ／または変更するプロセスの別の実施形態を示すフローチャートである。 図３の動的実行レイヤインタフェース（ＤＥＬＩ）の実施形態を示すブロック図である。 図８のＤＥＬＩのコアの実施形態を示すブロック図である。 図３〜図９のシステムおよび方法を実施し得るコンピュータシステムの実施形態のブロック図である。 図３のシステムで実施し得る、アプリケーション向けにオペレーティングシステム機能を拡張かつ／または変更するプロセスのさらなる実施形態を示すフローチャートである。 図３のシステムで実施し得る、アプリケーション向けにオペレーティングシステム機能を拡張かつ／または変更するプロセスのさらに別の実施形態を示すフローチャートである。

符号の説明

１０２・・・アプリケーション、
１０４・・・オペレーティングシステム、
１０６・・・ハードウェア、
３０２・・・動的実行レイヤインタフェース、
３０４・・・Ｏ／Ｓインタセプトモジュール、
３０６・・・コードキャッシュ、
６０６・・・コア、
６１０・・・透過モードレイヤ、
６１２・・・システム制御・構成レイヤ、
６１６・・・コアコントローラ、
６１８・・・キャッシュマネージャ、
６２０・・・フラグメントマネージャ、
６２２・・・最適化マネージャ、
６２６・・・インジェクタ、
６２８・・・命令フェッチコントローラ、
７０４・・・フラグメント形成ポリシー、
７０６・・・インスツルメンテーションポリシー、
７０８・・・フラグメントリンキングポリシー、
７１２・・・キャッシュポリシー、
７１８・・・最適化ポリシー、
８０２・・・処理装置、
８０４・・・メモリ、
８０６・・・ユーザインタフェース装置、
８０８・・・ディスプレイ、
８１０・・・Ｉ／Ｏ装置、
８１２・・・ネットワークインタフェース装置、
８１４・・・ローカルインタフェース、

Claims (10)

1. 　アプリケーション（１０２）向けにオペレーティングシステム機能を拡張する方法であって、
   　前記アプリケーション（１０２）から１つまたは複数の２進命令を受け取るステップと、
   　前記１つまたは複数の２進命令が、特定のオペレーティングシステム機能を実行する、オペレーティングシステム（１０４）へのコール(call)に対応するかどうかを判定するステップと、
   　前記特定のオペレーティングシステム機能を前記アプリケーション（１０２）向けに変更すべきかどうかを判定するステップと、
   　前記特定のオペレーティングシステム機能を前記アプリケーション（１０２）向けに変更すべき場合、前記変更された機能を実施するコードを実行するステップと
   　を含む方法。
2. 　前記１つまたは複数の２進命令がオペレーティングシステム（１０４）へのコールに対応するかどうかを判定するステップは、システムコールをインタセプトするステップを含む
   　請求項１記載の方法。
3. 　前記アプリケーション（１０２）に対応する２進命令を受け取るステップは、アプリケーションプログラムインタフェース（６０８）を介して２進命令を受け取ることを含む
   　請求項１記載の方法。
4. 　前記アプリケーション（１０２）に対応する２進命令を受け取るステップは、動的実行レイヤインタフェース（３０２）を前記アプリケーション（１０２）に投入することにより、前記２進命令の実行に対する制御を取得するステップを含む
   　請求項１記載の方法。
5. 　前記変更された機能を実施するコードをコードキャッシュ（３０６）に格納するステップをさらに含む
   　請求項１記載の方法。
6. 　前記変更された機能を実施するコードがコードキャッシュ（３０６）に格納されているかどうかを判定するステップと、
   　前記変更された機能を実施するコードを前記コードキャッシュ（３０６）から実行するステップと
   　をさらに含む請求項１記載の方法。
7. 　アプリケーション（１０２）向けにオペレーティングシステム機能を拡張するシステムであって、
   　アプリケーション（１０２）から２進命令を受け取る手段と、
   　特定のオペレーティングシステム機能を実行する、オペレーティングシステム（１０４）へのコールを特定する手段と、
   　前記特定のオペレーティングシステム機能を前記アプリケーション（１０２）向けに変更すべきかどうかを判定する手段と、
   　前記変更された機能を実施する手段と
   　を備えるシステム。
8. 　アプリケーション（１０２）向けのオペレーティングシステム機能を拡張するように構成されたコンピュータ（８００）であって、
   　メモリ（８０４）に常駐するオペレーティングシステム（１０４）および少なくとも１つのアプリケーション（１０２）と、
   　システムコールインタセプト機能（３０４）であって、
   　　前記アプリケーション（１０２）から２進命令を受け取り、
   　　前記１つまたは複数の２進命令が、特定のオペレーティングシステム機能を実行する、前記オペレーティングシステム（１０４）へのコールに対応するかどうかを判定し、
   　　前記特定のオペレーティングシステム機能を前記アプリケーション（１０２）向けに変更すべきであるかどうかを判定する
   　ように構成されたシステムコールインタセプト機能（３０４）と、
   　前記変更された機能を実施するように適合されたコードを実行し、キャッシュするように構成されたコア（６０６）と、
   　該コンピュータ（８００）に関連するロジックを処理するように構成されたハードウェア（１０６）と
   　を備えるコンピュータ。
9. 　前記アプリケーション（１０２）に前記コア（６０６）のキャッシュ機能および実行機能へのアクセスを提供するように構成されたアプリケーションプログラミングインタフェース（６０８）をさらに備える
   　請求項８記載のコンピュータ。
10. 　前記コア（６０６）の動作にポリシーを提供するように適合されたシステム制御・構成レイヤ（６１２）をさらに備える
    　請求項８記載のコンピュータ。

Images