JP5650240B2 - オフデバイス・サービスを用いた実行コードのランタイム・プロビジョニングのための技術 - Google Patents

Description

本開示は一般にクライアント・デバイスで実行されるプログラムのランタイム中の実行コードのプロビジョニングに関する。特に、オフデバイス・プロビジョニング・サービスを伴う技術が記載される。

今日、中央処理ユニット（ＣＰＵ）の動作周波数はおおよそ成長が止まっており、一部の場合には減少してさえいる。このため、なおも増加している処理要求に対処するため、複数のプロセッサ・コアを有する異種プロセッサが段々と重要になっている。近年の異種マルチコア・デバイスは例えばＣＰＵコア、グラフィカル処理ユニット（ＧＰＵ）コア、デジタル信号プロセッサ（ＤＳＰ）コアなどを備えうる。

マルチコア・デバイスの異種性は、様々なハードウェア構成及び様々な実行プラットフォームを有する対象デバイスでポータブル・アプリケーションが実行可能であることを要求する。このようなポータブル・アプリケーションはバイトコードを保持する実行ファイルに基づきうる。（Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）のような）デバイス固有の仮想マシンはバイトコードを解釈・実行するか、ランタイム・コンパイルを用いてバイトコードを実行コード（すなわち、バイナリコード又は機械コード）に変換する。

携帯電話機、スマートフォン、携帯情報端末（ＰＤＡ）のような移動体デバイスは徐々に高性能になっており、それ故、異種マルチコア・システムの有望な候補である。しかし、移動体デバイスは処理能力、バッテリ電力などの観点で制限されたリソースを有する。そこで、移動体デバイスの個別のハードウェア・ソフトウェア環境に適合されたオフデバイス・コンパイル・サービスを用いて、利用可能なリソースをコンパイル・タスクから解放することが示唆されている。

特許文献１は移動体クライアント・デバイスのための例示のオフデバイス・コンパイルのシナリオを記載する。ソースコードはローカル・ファイルシステムを介してクライアント・デバイスのメモリに格納される。クライアント・デバイスのＣＰＵで、ソースコード・ファイルを読み出すように構成されたプログラム（例えば、インストーラ・アプリケーション）が実行される。クライアント・プログラムはまず、クライアント・デバイスのハードウェア・ソフトウェア環境を示すコード・コンパイル要求を生成する。その後、コード・コンパイル要求は、リモートのネットワーク・サーバへ送信され、リモートのネットワーク・サーバは、示されたハードウェア・ソフトウェア環境についてコードをコンパイルする能力を有するならば受理メッセージで応答する。

受理メッセージを受信すると、クライアントプログラムはローカル・ファイルシステムを介してソースコード・ファイルを読み出し、これをサーバへ送信する。サーバは受信したソースコードをコンパイルして（クライアント・デバイスの個別のハードウェア・ソフトウェア環境に適合された）実行コードを生成し、コンパイルされたコードをクライアント・デバイスへ返す。クライアント・デバイスはコンパイルされたコードをローカル・ファイルシステムに格納してもよい。クライアント・デバイスは様々なプロセッサ・コアでその後に処理される単一のソフトウェアの様々なコンポーネントについて様々なコンパイル要求を発行してもよい。

国際公開第２００９／０５５７３１号

オフデバイス・サービスから実行コードを取得するためのより効率的な技術が必要である。

第１側面によれば、ホスト・コアと、ホスト・コアとは異なるコアに実装された少なくとも１つの処理要素とを備えるクライアント・デバイスのための実行コードを取得する方法が提供される。本方法は、ホスト・コアによって実行されるホスト・プログラムのランタイムにホスト・コアによって実行される、ホスト・プログラムに埋め込まれた非実行コード部分を判定する工程と、検出された非実行コード部分に対する実行コードをリモートのネットワーク・サーバに要求する工程と、要求した実行コードをネットワーク・サーバから受信する工程と、受信した実行コードを処理要素による実行のために提供する工程とを有する。例として、受信した実行コードを実行のために提供する工程は、クライアント・デバイスが実行コードを格納する工程を含んでもよい。

本方法は、処理要素が、受信した実行コードの実行を開始する工程をさらに含んでもよい。この開始する工程は、ホスト・コアによってホスト・プログラムのランタイムで実行されてもよいし、他の任意の方法で実行されてもよい。受信した実行コードは、受信直後に（例えば、次のクロックサイクルで）実行されてもよいし、後の時点で実行されてもよい。さらに、受信したコードが一度も実行されないシナリオ（例えば、一度も通らないＩＦ分岐に受信したコードが属する場合）が存在してもよい。

１つの実装では、実行コードを要求する処理は、ホスト・プログラムから非実行コード部分を抽出する工程と、抽出した非実行コード部分をネットワーク・サーバへ送信する工程とを含む。非実行コード部分は例えばソースコードを含んでもよい。ホスト・プログラムはバイトコード形式で提供されてもよい。

非実行コード部分は様々な方法でホスト・プログラムに埋め込まれうる。例えば、非実行コード部分自体がホスト・プログラムに埋め込まれてもよいし、非実行コード部分の位置を指し示すリンク、参照又は識別子の形式でホスト・プログラムに埋め込まれてもよい。この位置はクライアント・デバイス自体のものであってもよいし、ネットワークのものでもよい。１つの変形によれば、非実行コード部分は文字列の形式でホスト・プログラムに埋め込まれる。文字列はソースコードの形式で非実行コード部分を含んでもよい。これに代えて、文字列は、非実行コード部分を指し示すユニバーサル・リソース・ロケータ（ＵＲＬ）列の形式を取ってもよい。ＵＲＬは例えばリモートのネットワーク・サーバを指し示してもよく、１つのシナリオでは要求される個別の実行コードを指し示してもよい。

本方法は、デバイスのモード設定を判定する工程と、モード決定を示す情報をネットワーク・サーバへ送信する工程とをさらに有してもよい。その後、ネットワーク・サーバはモード設定情報を考慮に入れて実行コードを取得してもよい。更なる変形では、デバイスのモード設定の変更が判定されてもよい。モード設定の変更を判定したことに応じて、実行コードを求める新たな要求が開始されてもよい。この新たな要求に応じて受信された実行コードは新たなモード設定を考慮に入れてネットワーク・サーバによって取得されていてもよい。モード設定は一般にデバイスの１つ以上の動作モードに関する。この動作モードは例えば、性能モード（例えば、高性能／低性能）と電力モード（例えば、通常電力モード／節電モード）とのうちの少なくとも１つに関する。モード設定関連の機能は単一コア・シナリオ（一方でのホスト・コアと他方での処理要素との間の区別がなされないシナリオ）にも適用できることに留意されたい。

１つのシナリオでは、実行コードは、暗号形式と署名付き形式とのうちの少なくとも１つで受信される。このシナリオでは、本方法は、（例えば、実行コードの実行を開始する前に）受信した実行コードを復号する工程をさらに有してもよい。これに加えて、又はこれに代えて、本方法は、（例えば、実行コードの実行を開始する前に）実行コードに付与された署名を確認する工程を有してもよい。さらに、ホスト・プログラムから抽出された非実行コード部分は、ネットワーク・サーバへ送信される前に、暗号化と署名とのうちの少なくとも１つが行われてもよい。

ネットワーク・サーバから受信した実行コードはローカルのキャッシュに格納されてもよいし、ホスト・プログラムの実行又はホスト・プログラム内の非実行コード部分の検出をさらに行う場合にキャッシュから読み出されてもよい。その後、処理要素による読み出された実行コードの実行が開始されてもよい。このようなクライアント側でのキャッシュ・シナリオでは、ネットワーク・サーバ及びネットワークコネクションは、不要な反復タスクの負荷が軽減される。

ホスト・プログラムはホスト・コアで実行される仮想マシンによって実行されてもよい。仮想マシンはＪａｖａに基づいてもよい。１つの実装では、ホスト・プログラムはＯｐｅｎＣＬ規格に従って記述される。しかし、ホスト・プログラムはまた、ランタイムでコンパイルされる必要のある（例えばソースコード形式の）計算タスクをプログラムに埋め込むことを認める任意の他の言語で記述されてもよい。

デバイスは、ホスト・プログラムのようなバイトコードを保持する実行ファイルと互換性を有するオペレーティングシステムを実行してもよい。一例として、アンドロイド・オペレーティングシステムがデバイス上で実行されてもよく、ホスト・プログラムはアンドロイド・アプリケーション又はアンドロイド・アプリケーションの一部であってもよい。アンドロイド・オペレーティングシステム及びアンドロイド・アプリケーションの代わりに、他のＪａｖａベースのオペレーティングシステム及びアプリケーションが同様にデバイス上に実装されてもよい。

別の側面によれば、クライアント・デバイスに実行コードを提供する方法が提供される。クライアント・デバイスは、ホスト・コアと、ホスト・コアとは異なるコアに実装された少なくとも１つの処理要素とを備え、ホスト・コアは、埋め込まれた非実行コード部分を含むホスト・プログラムを実行する。本方法は、ホスト・プログラムのランタイムにネットワーク・サーバによって実行される、埋め込まれた非実行コード部分に関する実行コードを求める要求を受信する工程と、要求された実行コードを取得する工程と、取得した実行コードをデバイスへ送信する工程とを有する。実行コード要求は、実行コード自体を含んでもよいし、実行コードへの参照を含んでもよい。例として、実行コード要求はＵＲＬに基づいてもよい。

１つの実装では、要求された実行コードを取得する工程は、要求された実行コードを生成するために非実行コード部分をコンパイルする工程を含む。別の実装では、要求された実行コードはローカルのキャッシュ又はデータベースからネットワーク・サーバによって読み出される。このような読み出しは、実行コード要求とともに受信されたコード識別子に基づいてもよい。

さらに別の変形によれば、ネットワーク・サーバは、デバイスに関するハードウェア情報と、ソフトウェア情報と、モード設定情報とのうちの少なくとも１つを受信するように適合される。このような実装では、非実行コード部分はハードウェア情報と、ソフトウェア情報と、モード設定情報とのうちの少なくとも１つを考慮に入れて取得（例えば、コンパイル又は読み出し）されてもよい。

更なる側面によれば、１つ以上の計算デバイス、例えばスマートフォンのような移動体クライアント・デバイスで実行された場合に、本明細書に記載される任意の方法及び方法の側面の各工程を実行させるプログラムコード部分を含むコンピュータプログラムが提供される。コンピュータプログラムは、計算デバイスに含まれるかこれに関連する固定メモリ又は書き換え可能メモリ、ＣＤ−ＲＯＭ、ＤＶＤなどのようなコンピュータで読み取り可能な記憶媒体に格納されてもよい。これに加えて、又はこれに代えて、コンピュータプログラムは、例えば電話線又は無線リンクのようなインターネット及び／又は通信コネクションのようなデータ・ネットワークを介して計算デバイスにダウンロードされるように提供されてもよい。

さらに別の側面によれば、クライアント・デバイスが提供される。本クライアント・デバイスは、ホスト・プログラムを実行し、ホスト・プログラムに埋め込まれた非実行コード部分をホスト・プログラムのランタイムで判定するように適合されたホスト・コアを備える。本クライアント・デバイスは、検出された非実行コード部分に対する実行コードをリモートのネットワーク・サーバに要求し、要求した実行コードをネットワーク・サーバから受信するように適合されたインタフェースと、ホスト・コアとは異なるコアに実装された少なくとも１つの処理要素とをさらに備え、ホスト・コアは、処理要素による実行のためにホスト・プログラムのランタイムで受信した実行コードを提供するように適合される。

クライアント・デバイスは固体端末の形式で構成されてもよいし、移動体端末の形式で構成されてもよい。移動体の構成では、クライアント・デバイスは、携帯電話機、スマートフォン、ＰＤＡ、ネットブック、ノートブックなどの形式で実現されてもよい。クライアント・デバイスは、無線リンクを介してリモートのネットワーク・サーバと通信する無線通信能力を有してもよい。

相補的な側面によれば、ホスト・コアと、ホスト・コアとは異なるコアに実装された少なくとも１つの処理要素とを備えるクライアント・デバイスに実行コードを提供するように構成されたネットワーク・サーバが提供される。ホスト・コアは、埋め込まれた非実行コード部分を含むホスト・プログラムを実行する。ネットワーク・サーバは、埋め込まれた非実行コード部分に関する実行コードを求める要求を受信するように適合されたインタフェースと、要求された実行コードをホスト・プログラムのランタイムで取得するように適合されたコンポーネントとを備え、インタフェースは実行コードをデバイスへ送信するようにさらに適合される。

要求された実行コードを取得するように適合されたコンポーネントは、コンパイラとして構成されてもよいし、以前にネットワーク・サーバによってコンパイルされた実行コードを一時的に保持するキャッシュとして構成されてもよいし、事前にコンパイルされた実行コードを保持するデータベースとして構成されてもよい。実行コードは、クライアント・デバイスに関するハードウェア情報と、ソフトウェア情報と、モード設定情報とのうちの少なくとも１つを考慮に入れてネットワーク・サーバによって取得されてもよい。

以下に、図面に説明される例示の実施形態を参照して本開示がより詳細に記載される。

クライアント・デバイスの実施形態及びネットワーク・サーバの実施形態を含む実行コードを要求し提供するためのシステムの概略図を説明する。 例示の方法の実施形態における図１のクライアント・デバイス及びネットワーク・サーバの動作を説明する概略フローチャートを示す。

以下の記載は、説明のためであって限定のためではなく、本開示の完全な理解を提供するために個別の詳細が説明される。本明細書で開示される技術はこれらの個別の詳細から逸脱する他の実施形態で実施されてもよいことを当業者は理解するだろう。例えば、以下の実施形態は主にＯｐｅｎＣＬフレームワークに関して記載されるが、本開示がこのような実施に限定されないことを当業者は理解するだろう。従って、本明細書で用いられる用語及び表現はＯｐｅｎＣＬによる本開示の実現に限定されるものとして解釈されるべきではない。

本明細書で説明される機能は個別のハードウェア回路を用いて実施されてもよいし、プログラム式マイクロプロセッサ又は汎用コンピュータと連動して機能するソフトウェアを用いて実施されてもよいし、特定用途向け集積回路（ＡＳＩＣ）を用いて実施されてもよいし、１つ以上のＤＳＰを用いて実施されてもよいことを当業者はさらに理解するだろう。本明細書に記載される技術はマイクロプロセッサと、マイクロプロセッサに結合されたメモリとに具現化され、プロセッサによって実行される場合に本明細書に開示される方法及び方法の側面を実行する１つ以上のプログラムでメモリに符号化されてもよいことも当業者は理解するだろう。

図１はオフデバイス・コードのプロビジョニング・サービスを用いて実行コードを要求し取得するためのシステムを説明する。本システムは、通信ネットワーク１２を介してリモートのネットワーク・サーバ１４と通信するように構成されたクライアント・デバイス１０を備える。本実施形態では、クライアント・デバイス１０はスマートフォンのような移動体端末として構成される。通信ネットワーク１２は、例えばＧＳＭ、Ｗ−ＣＤＭＡ又はＬＴＥ通信技術に基づく１つ以上の無線リンクを備える。ネットワーク・サーバ１４はサービスプロバイダ又はネットワークオペレータのコアネットワークに位置する。

図１に説明されるように、クライアント・デバイス１０は異種構成を有し、少なくともＣＰＵ２０、ＧＰＵ２２及びＤＳＰ２４を含む複数のプロセッサを備える。各プロセッサ２０、２２、２４は１つ以上のプロセッサ・コア２６、２８、３０を備える。クライアント・デバイス１０は、ネットワーク・サーバ１４と通信するように適合されたインタフェース３２をさらに備える。インタフェース３２はソフトウェアの形式で実現されてもよいし、ハードウェアの形式で実現されてもよいし、これらの組み合わせとして実現されてもよい。インタフェース３２はネットワーク・サーバ１４に実行コードを要求し、ネットワーク・サーバ１４から実行コードを受信するように適合される。クライアント・デバイスのローカルキャッシュ３４は、プロセッサ・コア２６、２８、３０のうちの１つ以上による即時実行又は後での実行のためにネットワーク・サーバ１４から受信した実行コードを一時的に格納するように適合される。

ネットワーク・サーバ１４はクライアント・デバイス１０と通信するように適合されたインタフェース５０を備える。クライアント・デバイス１０のインタフェース３２と同様に、ネットワーク・サーバ１４のインタフェース５０はソフトウェアの形式で実現されてもよいし、ハードウェアの形式で実現されてもよいし、これらの組み合わせとして実現されてもよい。ネットワーク・サーバ１４は、クライアント・デバイス１０によって要求された実行コードを取得するように適合されたコンポーネント５２をさらに備える。図１に説明される例示の実装では、コンポーネント５２はコンパイラとして構成される。コンポーネント５２は様々な方法で実現されてもよく、例えばクライアント・デバイス１０によって要求されうる複数のコード機能について事前にコンパイルされた実行コードを保持するデータベースの形式で実現されてもよいことが理解されるだろう。さらに、ネットワーク・サーバ１４はコンポーネント５２によってコンパイルされた実行コードをキャッシュするためのキャッシュ５４を備える。キャッシュ５４のプロビジョンは、コンポーネント５２から同様のコンパイル・タスクを繰り返して実行することによる負荷を軽減する。

本実施形態では、ＣＰＵ２０による実行のためにアンドロイド又は仮想マシンの形式で実行可能な別のＪａｖａベースのオペレーティングシステムがクライアント・デバイス１０にインストールされる。クロノスＯｐｅｎＣＬワーキンググループによって規定されるＯｐｅｎＣＬフレームワーク（例えば、２０１２年８月８日付けのＯｐｅｎＣＬ仕様書バージョン１．０、文書改訂２９版を参照）はＣＰＵ２０、ＧＰＵ２２及びＤＳＰ２４による異種集合体のプログラミングに利用される。

一般に、ＯｐｅｎＣＬアプリケーションは、一方でホストで動作するプログラム（「ホスト・プログラム」）と、他方で１つ以上のＯｐｅｎＣＬデバイスで動作するプログラム（「カーネル」）との組合せと見なされうる。本実施形態では、ホスト・プログラム４０はＣＰＵ２０のコア２６（「ホスト・コア」）で実行され、ＯｐｅｎＣＬデバイスはＧＰＵ２２及びＤＳＰ２４によって実現される。各ＯｐｅｎＣＬデバイスは計算ユニットの集合体として定義され、各計算ユニットは１つ以上の処理要素（ＰＥ：Processing Element）から構成される。図１に説明される実施形態では、ＧＰＵコア２８は２つのこのようなＰＥ４２、４４を備え、ＤＳＰコア３０は１つのＰＥ４６を備える。

ホスト・コア２６で実行されるホスト・プログラム４０はＰＥ４２、４４、４６での計算タスクを実現するために、ＧＰＵ２２及びＤＳＰ２４へコマンドを投入するように構成される。計算タスクは、ホスト・プログラム４０で宣言され、非実行ソースコード部分の形式でホスト・プログラムに埋め込まれた１つ以上のカーネル４８によって定義される。ホスト・プログラム４０自体はＣＰＵ２０で実行される仮想マシンによって実行可能なバイトコードの形式で提供されてもよい。

以下のソースコードの断片はホスト・プログラム４０のソースコードに文字列の形式でどのようにカーネル４８の１つが埋め込まれるかを説明する。
const char *embedded_code =“__kernel void some_computation(…) {
int x = 3;
int y = get_local_id(0);
… /* ＯｐｅｎＣＬの計算はここから */
}“;
…
program = clCreateProgramFromSource(…, embedded_code, …);
clBuildProgramExecutable(program, …);
kernel = clCreateKernel(program, …);
…
clExecuteKernel(…, kernel, …);

ホスト・プログラム４０をバイトコードに変換した後であっても、カーネル４８は結果のバイトコードにソースコード表現で（例えば文字列の形式で）埋め込まれたままであることが理解されるだろう。埋め込まれたソースコード表現はネットワーク・サーバ１４によって（典型的にはアプリケーションの起動中に）ホスト・プログラム４０のランタイムでコンパイルされるだけだろう。

ソースコード列をホスト・プログラム４０に埋め込む代わりに、ネットワーク・サーバ１４を指し示すＵＲＬ列（１つの実施形態ではコンパイルされる要求対象のソースコード又は事前にコンパイルされた要求対象のコードを識別子によって参照するＵＲＬ列）の形式で埋め込まれてもよい。さらに、ソースコードは（例えばアプリケーション・バンドルの形式で）ホスト・プログラム４０と一緒にクライアント・デバイス１０に格納されたファイルへの参照の形式でホスト・プログラム４０に埋め込まれてもよい。

ネットワーク・サーバ１４により提供されるオフデバイス・コンパイル・サービスの利用によって、クライアント・デバイス１０は、かなりの処理リソース及びメモリリソースを必要とするだろう洗練されたコンパイラを実装する必要性の負荷が軽減される。これは、クライアント・デバイス１０はＯｐｅｎＣＬアプリケーションを実行できるが、必要なコンパイル・タスクを実行できなくてもよいことを意味する。よって、クライアント・デバイス１０の計算リソースはコンパイル・タスクに利用可能でなくてもよいので、クライアント・デバイス１０は実際にＯｐｅｎＣＬフレームワークの十分な利用を排除する（ＯｐｅｎＣＬフレームワークは並列計算タスクと結びつくが、コンパイラは従来型のシーケンシャルプログラムである）。

あるシナリオでは先行コンパイルがオフデバイス・コンパイルに対する許容可能な代替でありうるが、典型的なアンドロイド・アプリケーションの可搬性によって、先行コンパイルは非実用的なものになる。先行コンパイルは特定の対象デバイスのハードウェア・ソフトウェア環境に合わせて個別に調整された実行コード（すなわち、バイナリコード又はマシンコード）を生じる結果となるので、バイトコード実行のアイデアを無にする。図２の概略フロー図２００を参照して以下に詳細に記載されるように、リソースに制限のあるクライアント・デバイス１０でＯｐｅｎＣＬコンパイル・タスクを実行するのではなく、制約の少ないネットワーク・サーバ１４へソースコード・カーネル４８が渡され、ネットワーク・サーバ１４は要求された実行コードを返す。図２に説明される様々なステップはホスト・プログラム４０のランタイムで実行される。

ＣＰＵ２０でバイトコード形式のホスト・プログラム４０を実行する際に、１つ以上のソースコード・カーネル４８に対応する１つ以上の非実行コード部分は初期ステップ２０２でホスト・プログラムに埋め込まれているものとして判定される。この判定は例えば、ホスト・プログラム４０内の各ソースコード・カーネル４８について関数clCreateProgramFromSourceを検出することに基づきうる（ホスト・プログラム４０の上記のソースコードの断片を参照）。従来、この関数はローカルのＯｐｅｎＣＬランタイム・コンパイラを呼び出すために実装される。本実施形態では、関数はその代わりに、ネットワーク・サーバ１４にソースコード・カーネル４８に対する実行コードを要求するために実装される。この目的のために、検出されたソースコード・カーネル４８について実行コード要求が生成される。その後、ステップ２０４で、この要求はインタフェース３２を介してネットワーク・サーバ１４へ送信される。

１つの変形では、埋め込まれたソースコード・カーネル４８はホスト・プログラム４０からソースコード列として抽出され、要求は実行コードが要求される対象の抽出されたソースコード・カーネル４８を含む。別の変形では、ソースコード・カーネル４８の識別子だけが要求と一緒にネットワーク・サーバ１４へ送信され、所定のシナリオにおいてソースコード・カーネル４８の送信が省略されうる。例として、ソースコード・カーネル４８は（ホスト・プログラム４０におけるソースコード・カーネル４８の以前の検出の際に）前もってすでに送信されていてもよいし、ネットワーク・サーバ１４はローカルのデータベースを介してソースコード・カーネル４８へのアクセスを有してもよい。ソースコード・カーネル４８の識別子はホスト・プログラム４０に埋め込まれたＵＲＬ列から導出されてもよい。

ソースコード・カーネル４８又はその識別子に加えて、さらなる情報がネットワーク・サーバ１４へ送信されてもよい。この付加的情報は、ネットワーク・サーバ１４によって返されるコンパイル済コードがクライアント・デバイス１０に展開されるハードウェア・ソフトウェア環境に合致することを保証するために、クライアント・デバイス１０の個別のハードウェア・ソフトウェア環境に関連してもよい。これに加えて、又はこれに代えて、クライアント・デバイス１０に関するモード設定情報がネットワーク・サーバ１４へ送信されてもよい。後述するように、この付加的情報は要求された実行コードを取得する際にネットワーク・サーバ１４によって使用されてもよい。

ステップ２０６で、実行コード要求はインタフェース５０を介してネットワーク・サーバ１４により受信される。要求には、ソースコード・カーネル４８又はその識別子（並びに、場合によってはデバイスに関するハードウェア／ソフトウェア情報及び／又はモード設定情報）が付随する。次のステップ２０８で、ネットワーク・サーバ１４はソースコード・カーネル４８に関する要求された実行コードを取得する。１つの実施形態では、ネットワーク・サーバのコンポーネント５２は、要求された実行コード（すなわち、バイナリコード又は機械コード）を生成するために、要求を介して受信された（又はローカルのデータベースから読み出された）ソースコード・カーネル４８をコンパイルする。代替の実施形態では、要求された実行コードは既にサーバキャッシュ５４において利用可能である（例えば、クライアント・デバイス１０や他のクライアント・デバイスによって以前に同様のコンパイル・タスクが既に要求されているからである）。

ソースコード・カーネル４８をコンパイルするか、キャッシュ５４又はローカルのデータベースからコンパイル済の実行コードを読み出す場合に、クライアント・デバイス１０から受信された付加的情報を考慮に入れてもよい。例えば、コンパイルされたコードがクライアント・デバイス１０の個別のハードウェア・ソフトウェア環境に合致するようにコンパイル処理が制御されてもよい。追加の手法又は代替の手法として、クライアント・デバイス１０から受信された個別のモード設定情報が検討されるようにコンパイルが制御されてもよい。例として、モード設定情報は、クライアント・デバイス１０で現在稼動している（高性能／低性能のような）性能モードと、（通常電力モード／節電モードのような）電力モードとのうちの少なくとも１つに関してもよい。言い換えると、例えばクライアント・デバイス１０の節電設定又は高性能（例えば、ゲーム）設定を結果の実行コードが支援するようにコンパイルが制御されてもよい。

１つの実装では、クライアント・デバイス１０は、実行バイナリコードを求める初期要求の後に、（例えば通常電力モードから節電モードへのものやその逆である）モード設定変更を判定した際にネットワーク・サーバ１４へ新たな要求を送信するように構成される。実行コードが要求される対象のソースコード・カーネル４８は初期要求を処理する際にネットワーク・サーバ１４によってキャッシュされているかもしれないので、モード設定変更の指標と一緒にソースコード・カーネル４８の識別子を送信すれば十分でありうる。その後、ネットワーク・サーバ１４はクライアント・デバイス１０の新たなモード設定を考慮に入れて（キャッシュされた）ソースコード・カーネル４８をコンパイルする。

コンパイル又は他の手段によって実行コードが取得されると、ステップ２１０で、ネットワーク・サーバ１４はインタフェース５０及び通信ネットワーク１２を介してクライアント・デバイス１０へ実行コードを返す。その後、ステップ２１２で、実行コードはインタフェース３２を介してクライアント・デバイス１０によって受信される。さらに、ステップ２１４で、ホスト・プログラム４０は受信したコードをローカルのキャッシュ３４に格納し、関連する処理要素４２、４４又は４６によって、受信した実行コードの実行を開始する。（あるグラフィカル・タスクのような）並列に実行されるタスクの場合に、ホスト・プログラム４０は（ＧＵＰコア２８のＰＥ４２及びＰＥ４４のような）２つ以上のＰＥによる、受信された実行コードの実行を並列に開始してもよい。

実行コードは即座に（例えば、受信後の次のクロック・サイクルで）実行される必要はなく、後の時点で実行されてもよいことに留意されたい。さらに、あるシナリオでは、受信された実行コードは（例えば一度も満たされない条件を有する条件付きコード文に実行が依存する場合に）一度も実行されなくてもよい。

ネットワーク・サーバ１４からソースコード・カーネル４８に対して受信された実行コードは更なる（２回目、３回目などの）実行のためにクライアント・デバイス１０のローカルのキャッシュ３４に格納されたままであってもよい。このような更なる実行はホスト・プログラムの更なる起動の文脈や、実行中のホスト・プログラム４０内のソースコード・カーネル４８の更なる検出の文脈で発生しうる。よって、実行コード要求はクライアント・デバイスによって、比較的低頻度で、例えばコア２８、３０のうちの１つ以上を電源停止させる新たな電力モードにクライアント・デバイス１０がなったことを理由に再コンパイルが必要な場合に（例えばスタンバイ・モードになるか音楽再生モードになった場合に）発行されるだろう。

ある実施形態では、クライアント・デバイス１０からネットワーク・サーバ１４へ転送される非実行コード及び／又はネットワーク・サーバ１４からクライアント・デバイス１０へ返送される実行コードは、第三者による不注意のコードの改変を避けるために、（例えば公開鍵基盤ＰＫＩを用いて）署名されてもよい。さらに、第三者にコードが読み取れないようにするために暗号化技術が用いられてもよい。このような実装では、コードのコンパイル及び／又はコードの実行の前に、署名確認ステップ及び／又は復号ステップが実施されてもよい。

上記の有利な実装の説明から明らかになったように、本明細書に開示される技術は、ＯｐｅｎＣＬフレームワーク又は非実行コード部分がホスト・プログラムに埋め込まれる他の任意のフレームワークと組み合わせてオフデバイス・コードのプロビジョニング・サービスを利用可能にする。このような技術は、実行ファイルが携帯されることが予想されるアンドロイドや同様のオペレーティングシステムを実行する、リソースに制約のあるクライアント・デバイスの場合に特に有益である。

本明細書に提示される技術はその好適な実施形態に関して記載されてきたが、この記載は説明の目的のためだけであることが理解されるだろう。従って、本発明は添付の特許請求の範囲のみによって限定されることが意図される。

Claims (18)

1. ホスト・コア（２６）と、前記ホスト・コア（２６）とは異なるコア（２８、３０）に実装された少なくとも１つの処理要素（４２、４４、４６）とを備えるクライアント・デバイス（１０）が実行コードを取得する方法であって、ホスト・プログラム（４０）のランタイムに前記ホスト・コア（２６）によって実行される、
   ‐前記ホスト・プログラム（４０）に埋め込まれた非実行コード部分（４８）を判定する工程と、
   ‐前記検出された非実行コード部分（４８）に対する実行コードをリモートのネットワーク・サーバ（１４）に要求する工程と、
   ‐前記要求した実行コードを前記ネットワーク・サーバ（１４）から受信する工程と、
   ‐前記受信した実行コードを前記処理要素（４２、４４、４６）による実行のために提供する工程とを有することを特徴とする方法。
2. 前記実行コードを要求する工程は、前記ホスト・プログラム（４０）から前記非実行コード部分（４８）を抽出する工程と、前記抽出した非実行コード部分（４８）を前記ネットワーク・サーバ（１４）へ送信する工程とを含むことを特徴とする請求項１に記載の方法。
3. 前記非実行コード部分（４８）は、ソースコード列の形式か、前記非実行コード部分（４８）を参照する識別子の形式か、又は前記非実行コード部分（４８）を指し示すＵＲＬ列の形式で前記ホスト・プログラム（４０）に埋め込まれることを特徴とする請求項１又は２に記載の方法。
4. 前記デバイス（１０）のモード設定を判定する工程と、
   前記モード設定を示す情報を前記ネットワーク・サーバ（１４）へ送信する工程とをさらに有することを特徴とする請求項１乃至３の何れか１項に記載の方法。
5. 前記デバイス（１０）のモード設定の変更を判定する工程と、
   前記モード設定の変更に応じて前記実行コードを求める新たな要求を開始する工程とをさらに有することを特徴とする請求項１乃至４の何れか１項に記載の方法。
6. 前記モード設定は、性能モードと電力モードとのうちの少なくとも１つに関することを特徴とする請求項４又は５に記載の方法。
7. 前記実行コードは、暗号形式と署名付き形式とのうちの少なくとも１つで受信され、
   前記方法は、
   ‐前記受信した実行コードを復号する工程と、
   ‐前記実行コードに付与された署名を確認する工程とのうちの少なくとも１つをさらに有することを特徴とする請求項１乃至６の何れか１項に記載の方法。
8. ‐前記受信した実行コードをローカルのキャッシュ（３４）に格納する工程と、
   ‐前記ホスト・プログラム（４０）の実行又は前記ホスト・プログラム（４０）内の前記非実行コード部分の判定をさらに行う場合に前記キャッシュ（３４）から前記実行コードを読み出す工程とをさらに有することを特徴とする請求項１乃至７の何れか１項に記載の方法。
9. 前記ホスト・プログラム（４０）は前記ホスト・コア（２６）で実行中の仮想マシンによって実行されることを特徴とする請求項１乃至８の何れか１項に記載の方法。
10. 前記ホスト・プログラムはＯｐｅｎＣＬ規格に従って記述されることを特徴とする請求項１乃至９の何れか１項に記載の方法。
11. 前記デバイス（１０）はアンドロイド・オペレーティングシステムを実行することを特徴とする請求項１乃至１０の何れか１項に記載の方法。
12. ホスト・コア（２６）と、前記ホスト・コア（２６）とは異なるコア（２８、３０）に実装された少なくとも１つの処理要素（４２、４４、４６）とを備えるクライアント・デバイス（１０）に実行コードを提供する方法であって、前記ホスト・コア（２６）は、埋め込まれた非実行コード部分（４８）を含むホスト・プログラム（４０）を実行し、前記方法は、前記ホスト・プログラム（４０）のランタイムにネットワーク・サーバ（１４）によって実行される、
    ‐前記埋め込まれた非実行コード部分（４８）に関する実行コードを求める要求を受信する工程と、
    ‐前記要求された実行コードを取得する工程と、
    ‐前記取得した実行コードを前記デバイス（１０）へ送信する工程とを有することを特徴とする方法。
13. 前記要求された実行コードを取得する工程は、前記要求された実行コードを生成するために前記非実行コード部分（４８）をコンパイルする工程を含むことを特徴とする請求項１２に記載の方法。
14. 前記デバイス（１０）に関するハードウェア情報と、ソフトウェア情報と、モード設定情報とのうちの少なくとも１つを受信する工程と、
    前記ハードウェア情報と、前記ソフトウェア情報と、前記モード設定情報とのうちの少なくとも１つを考慮に入れて前記非実行コード部分を取得する工程とをさらに有することを特徴とする請求項１２又は１３に記載の方法。
15. 装置で実行される場合に請求項１乃至１４の何れか１項に記載の方法の各工程を実行させるためのプログラムコード部分を有するコンピュータプログラム。
16. コンピュータで読み取り可能な記憶媒体に格納されたことを特徴とする請求項１５に記載のコンピュータプログラム。
17. クライアント・デバイス（１０）であって、
    ‐ホスト・プログラム（４０）を実行し、前記ホスト・プログラム（４０）に埋め込まれた非実行コード部分（４８）を前記ホスト・プログラム（４０）のランタイムで判定するように適合されたホスト・コア（２６）と、
    ‐前記検出された非実行コード部分（４８）に対する実行コードをリモートのネットワーク・サーバ（１４）に要求し、前記要求した実行コードを前記ネットワーク・サーバ（１４）から受信するように適合されたインタフェース（３２）と、
    ‐前記ホスト・コア（２６）とは異なるコア（２８、３０）に実装された少なくとも１つの処理要素（４２、４４、４６）とを備え、
    前記ホスト・コア（２６）は、前記処理要素（４２、４４、４６）による実行のために前記ホスト・プログラム（４０）のランタイムで前記受信した実行コードを提供するように適合されることを特徴とするクライアント・デバイス（１０）。
18. ホスト・コア（２６）と、前記ホスト・コア（２６）とは異なるコア（２８、３０）に実装された少なくとも１つの処理要素（４２、４４、４６）とを備えるクライアント・デバイス（１０）に実行バイナリコードを提供するように構成されたネットワーク・サーバ（１４）であって、前記ホスト・コア（２６）は、埋め込まれた非実行コード部分（４８）を含むホスト・プログラム（４０）を実行し、前記サーバ（１４）は、
    ‐前記埋め込まれた非実行コード部分（４８）に関する実行コードを求める要求を受信するように適合されたインタフェース（５０）と、
    ‐前記要求された実行コードを前記ホスト・プログラムのランタイムで取得するように適合されたコンポーネント（５２）とを備え、
    ‐前記インタフェース（５０）は前記実行コードを前記デバイス（１０）へ送信するようにさらに適合されることを特徴とするネットワーク・サーバ（１４）。

Images