JP2009528608A - ライブラリ中の特定の関数をアウトライン化することによるコードサイズ削減 - Google Patents

Abstract

コンピューティングデバイス中での使用が意図されたコンピュータコードセットのサイズを削減する方法であって、前記コードセットは、コンピューティングデバイスの電源が入ったとき自動的にメモリ中にロードされることが意図され、コンピューティングタスクを実行するための関数を含んでおり、コンピューティングデバイスの特定の用途を指定する工程と、コンピューティングデバイスの前記用途を実装するために要求されるコンピュータコードセット中の関数を識別する工程と、識別された関数をコードセットから除去して、識別された関数を別個のコンピュータコードライブラリに配置する工程とを含む。

【選択図】図１

Description

本発明は、コンピュータコードセットのサイズを削減する方法、及びコンピュータコードのライブラリを生成する方法に関する。

本明細書で使用される用語「コンピューティングデバイス」は、任意の形式の電気的コンピューティングデバイスを含むように広範囲に解釈されるべきであり、データ記録デバイスと、ハンドヘルド及びパーソナルコンピュータ、例えば携帯情報端末（ＰＤＡ）を含む任意の型又は形式のコンピュータと、単一のデバイス内に通信、画像記録及び／又は再生、及び計算機能を結合した携帯電話、スマートフォン及びコミュニケータを含む任意のフォームファクタの通信デバイスと、デジタルカメラ、ＭＰ３及び他の音楽再生機並びにデジタルラジオを含む他の形態の無線及び有線情報デバイスとを含む。

最新のコンピューティングデバイスは、一般に複数の型のメモリを含む。メモリは、大きく２つの型に分類することができる。

１．直接実行（ＸＩＰ：ｅＸｅｃｕｔｅ Ｉｎ Ｐｌａｃｅ）のプログラム用に使用することができるメモリであり、すなわち、このメモリでは、実行するためにプログラムを別の形式のメモリにロードする必要がない。様々な型のＲＡＭ（ランダムアクセスメモリ）は、この形式の最も顕著な例である。しかしながら、ＲＡＭは、揮発性であり、電源が落ちたときその内容が失われるので、多くのデバイスが、少量のより高価であるが低速の、ＮＯＲフラッシュのような様々な不揮発性ＸＩＰメモリを具備する。

２．記憶用に使用することができるが、ＸＩＰ用ではないメモリ。この理由は、一般に、ランダムにアドレス可能ではなくシーケンシャル又はブロック単位でのみアクセス可能であるからである。ディスクドライブ及びＮＡＮＤフラッシュは、この型の顕著な例である。記憶用メモリ中に保持されるプログラムは、実行可能となるためにＸＩＰメモリにコピーされなければならない。

これら２つの型のメモリ間にはさらに１つの顕著な差異がある、すなわち、ＸＩＰメモリは、記憶用のみに使用することができるメモリよりはるかに高価である。価格に敏感な大衆市場を狙う携帯電話のような携帯デバイスを含む、最新のコンピューティングデバイスの製造業者には相当のコスト圧力があるので、このようなデバイスは、ＸＩＰメモリに対する要件が可能な限り最小化されることが望まれる。

製造プロセスの一部として、コンピューティングデバイスが同デバイスを適切に機能させるために必須のソフトウェアをある種の恒久的不揮発性ストレージ内で供与されるという要件があることが知られている。このようなソフトウェアは一般に、デバイスの電源が入れられたときに実行する立ち上げ手順に必要である、或いは、頻繁に要求される又は重要なアプリケーションを提供するオペレーティングシステム（ＯＳ）サービスを提供するデータ及びプログラムを含む。

この種のソフトウェアを記憶用メモリ中にできる限り多く保持し、必要時にＸＩＰメモリにこのソフトウェアをコピーし（ロードし）、又は、もはや必要でなくなったときにＸＩＰメモリを開放する（アンロードする）デバイスは、ＸＩＰメモリ中にこのソフトウェアの多くを保持するデバイスと比較して、これらの製造コストを最小化することが可能である。

より具体的には、デバイスのコアＯＳが、製造時にストレージメモリ中に供給されている場合、一般に、立ち上げ（ブート）処理の一部としてＸＩＰメモリにストレージから完全なＯＳイメージとしてコピーすることが必要である。本明細書において用語「コアＯＳ」は、コンピューティングデバイスの基本的動作にとって不可欠であり、それ故、コンピューティングデバイスの電源が入ったとき自動的にロードされるＯＳの一部を指すために一般的な意味で使用される。「ＯＳイメージ」は、ＯＳソフトウェアの全体を表すファイルである。したがって、ＯＳイメージのサイズは、メモリ中に記憶されたときのＯＳのフットプリントである。

一般に、ＸＩＰメモリにロードされると、ＯＳイメージは、一部であっても実質的にアンロードすることはできない。このようなＯＳイメージは、通常、静的リンクとして知られる技術を使用して作り上げられるので、占有されるメモリ位置は、予約されたものとみなされなければならず、他のソフトウェアによる再利用はできないことが当業者には知られている。

コアオペレーティングシステムのサイズを最小化するデバイスは、専用に使用されるＸＩＰメモリを用意する固定的コストを最小化し、したがって、ＸＩＰメモリに対するデバイスの要件を最小化し、かつ購入費用を安くし、一般の大衆にとってより買い易くすることが可能になる。また、コアＯＳを記憶するために必要とされる記憶用メモリが少なくなり、記憶用メモリからＸＩＰメモリにコピーされることが必要なデータがより少ないことから、デバイスが迅速に立ち上げられ、またダイナミックＲＡＭの形のＸＩＰメモリの使用が少なくなることにより全体的電力消費を削減することから、電力消費をより低くできるという利点が提供される。

コンピューティングデバイスの製造業者が、製品ファミリーとしてこのようなデバイスを提供し、ファミリーの各メンバーが、異なる機能構成を示すが、同一又は類似のソフトウェアから開発されている場合、製品ファミリーの全てのメンバーが、互換性のあるコアオペレーティングシステムを含むことが、デバイス製造業者の視点からは望ましい。このことが製造業者の開発コストを減少させ、かつデバイスの信頼性を高めることが知られている。

さらに、このようなデバイスが、オープンであり、かつ追加の機能構成を提供するソフトウェアモジュール及びプログラムの製造後のインストールを可能とする場合、ファミリー全体に渡り互換性のあるコアオペレーティングシステムの提供は、このようなモジュール及びプログラムがより多数のデバイスを対象にすることを可能とする。結果として生じる規模の経済性は、開発コストを低減し、かつサードパーティ製造業者に対する信頼性を高めることができる。

最後に、これらのコンピューティングデバイスのエンドユーザに対しては、更なる利益がある。低価格及びより良い製品から得られる利益に加えて、製品ファミリー全体に渡ってこのようなソフトウェアモジュールの利用を可能とすることは、発売後（aftermarket）のソフトウェアを入手し、インストールすることに関わる煩雑さを相当に低減する。エンドユーザが所持するコンピューティングデバイスの正確なモデルを指定する替わりに、それらのファミリー中の全てのデバイスが相互に互換性があることを確信して、単に当該デバイスが属するファミリーを指定することで十分である。

製品ファミリーの関連メンバーは通常、機能セットにより差別化されており、これにより、特定のモデルが市場での互いに異なる領域を対象とすることが可能になる。

このことは、特に、携帯セルラ電話のような多機能コンピューティングデバイスについて言える。これらは、以前は別個のデバイス中で用いられていた機能が単一のデバイス中で利用可能となる、機能融合（ｃｏｎｖｅｒｇｅｎｃｅ）として知られる現象を示すことが知られている。例えば、以前は、デジタルミュージックプレーヤー、デジタルカメラ、ＦＭラジオ、ＰＤＡ、ページャ、目覚まし時計、電子メッセンジャー（例えば、ＲＩＭ Ｂｌａｃｋｂｅｒｒｙ）、口述録音機、携帯ゲームコンソール及び携帯電話において個別に利用可能であった機能の１０項目全てが、ソニーエリクソンＰ９１０ｉのような単一の現在利用可能なコンピューティングデバイス中に見出すことができる。しかしながら、機能融合されたデバイスの複雑性が往々にしてそれらの効果的使用の妨げになる可能性があることが知られており、また、単一のデバイス上でかつ単一のフォームファクタ中で全ての機能を提供するためにはいくつかの妥協が必要であり、そのため満足な顧客体験までには至らない可能性があることが知られている。

これが、機能セットによる差別化が、コンピューティングデバイスにおいてますます一般的になってきている１つの理由である。再度例として携帯電話を取り上げると、デジタルミュージック用に設計されたデバイス（ストレージメモリ、良質なヘッドフォン及びミュージック再生用に設計されたボタンを具備する）、デジタル写真用に設計されたデバイス（記憶用メモリ及び高級なレンズを具備する）、電子的メッセージング用に設計されたデバイス（正規のＱＷＥＲＴＹキーボードを具備する）、又はゲームプレー用に設計されたデバイス（特別な親指ボタンを具備する）の間で、顧客が選択することが現在可能である、すなわち、多くの他の専用化された機能セットが現在利用可能であり、また今後数年間により多くのものが見られるようになることは疑いがない。

特定の機能セットを指定することについての関連した理由は、製品ファミリーの低価格側でデバイスを提供するためにより高価な機能が取り除かれるという形で、価格による市場細分化を可能とすることである。

したがって、製造業者は、同一のデバイスファミリーに属するが、これらの機能セットに関して差別化されている製品群をより多く市場に出している。

ここで解決する必要がある問題は、以下の３つの要件の全てを調和させる明確な方法がないことである。

１．コアＯＳイメージのサイズを最小化すること、これによりデバイスは、より安価に、立ち上げが早く、電力消費が少なくなる。

２．同一のデバイスファミリーに属する全てのモデルに渡り互換性を維持すること、これは、ソフトウェア開発コストを削減し、かつソフトウェアの信頼性を高める経済効果をもたらす。

３．異なる利用者群の様々なニーズを満足するように同一のデバイスファミリー中でデバイスを差別化すること。

コンピューティングデバイスが差別化される場合、ファミリー中の各モデルに対してコアＯＳイメージ中に含まれる必要がある項目が異なってくることは明らかである。３つの特定のアプリケーションとして、音楽演奏リストのエディタ及びセレクタ、カメラ及び映画アプリケーション並びに８０２．１１無線ネットワークドライバーを取り上げると、音楽演奏デバイスの要件、デジタルカメラデバイスの要件、及びメッセージングデバイスの要件には互換性がないことを容易に見て取ることができる。３つ全てに対して、コアＯＳイメージの一部でなければならない、１つのデバイスにとって本質的な機能であるものが、他の２つに対しては重要ではない用途である。重要でない機能を、コアＯＳイメージから取り除くことができる場合、３つの差別化されたデバイスのそれぞれは、より安価かつより速く製造され、立ち上がりがより速くなり、電力消費が少なくなることになろう。

しかし、差別化され、機能融合されたデバイス上の重要でない機能を単に除去することは、デバイスの互換性をなくし、したがって、モデルのファミリーコンセプトにおける本来の価値の大部分を破壊することになろう。非互換性についての主たる理由を上記に説明したが、コアＯＳイメージは静的リンクを使用して構築され、またアフターマーケット用のソフトウェアは、同一ファミリー中の全モデルに対して特定の機能構成が該イメージ中の特定のロケーションにより利用可能になることを想定している。したがって、コアＯＳイメージをストレージからＸＩＰメモリに複写するコンピューティングデバイスの既存のファミリーは、互換性を維持するために非本質的な又はめったに使用されない機能のサポートを含まねばならない。このことは、オペレーティングシステムを過大にし、何らの他の価値をもたらすことなく製造コストを増大させる。これはまた、たとえ頻繁には使用されることがないにしても、これらの機能のサポートコードを、ストレージからＸＩＰメモリに複写する必要があるので、立ち上げ時間を増加させ、またＸＩＰメモリが、ダイナミックＲＡＭである場合電力消費を増加させる。

これらの使用頻度が少ない部分を具備しない、コアオペレーティングシステムの代替バージョンを製造することは無論可能であるが、このようなバージョンは、首尾一貫した製品ファミリーを維持する製造業者及び顧客両者に対するいくつかのかなりの経済的利益を必然的に失うことになる。すなわち：
１．このようなコアＯＳのバージョンは、元の完全なバージョンとの互換性による利益が得られないことになろう。特に、コアＯＳの完全機能付きのバージョンに備わっていると想定されるコードに依拠する、製造後インストールされたソフトウェアがいずれも動作しないことになる。

２．ＯＳの別なバージョンが、製品ファミリーをばらばらにするので、別個の開発及び試験が要求され、それによって開発コスト及び市場投入時間を増大させることになろう。

本発明の第１の態様によれば、コンピューティングデバイス中での使用が意図されたコンピュータコードセットのサイズを削減する方法であって、コードセットは、前記コンピューティングデバイスの電源が入ったとき自動的にメモリ中にロードされることが意図され、コンピューティングタスクを実行するための関数を含んでおり、コンピューティングデバイスの特定の用途を指定する工程と、コンピューティングデバイスの前記用途を実装するために要求されるコンピュータコードセット中の関数を識別する工程と、識別された関数を前記コードセットから除去し、識別された関数を別個のコンピュータコードライブラリに配置する工程と、を含む方法が提供される。

識別された関数を除去する工程は、識別された関数を、別個のコンピュータコードライブラリを呼び出すように構成されたコードで置換する工程を含むことができ、それによって、削減されたコンピュータコードセットと別個のコンピュータコードライブラリの結合された機能構成が、元のコードセットの機能構成と等価になる。

要求される関数を識別する工程は、テスト用コンピューティングデバイス上で前記用途を実行するために元のコンピュータコードセットを実行する工程と、コンピュータコードセット中のいずれの関数が実行中に使用されるかを決定する工程とを含むことができる。

コンピュータコードセット中のいずれの関数が実行中に使用されるかを決定する工程は、関数プロファイリング又はコールグラフ分析技術の使用を含むことができる。

コンピューティングデバイスの特定の用途は、コンピューティングデバイス中で頻繁に使用されないことが予想されるアプリケーションを示し、及び／又はデバイスの動作に必須ではないアプリケーションを示すことができる。

別個のコンピュータコードライブラリは、ダイナミックリンクライブラリであってよい。

別個のコンピュータコードライブラリ中に識別された関数を配置する工程は、関数が、関連したコンピューティングデバイスの対応する用途に従ってクラスタ化されるライブラリを結果として生じることができる。

コンピュータコードセットは、実行可能なコードであることが好ましい。

本発明の第２の態様によれば、上記に説明した方法により得られる削減されたコンピュータコードセットが提供される。

本発明の第３の態様によれば、上記に説明した方法により得られる削減されたコンピュータコードセットを含むオペレーティングシステムが提供される。

オペレーティングシステムは、別個のコンピュータコードライブラリをさらに含むことができる。

本発明の第４の態様によれば、上記に説明した方法により得られる削減されたコンピュータコードセットを含むコンピューティングデバイスが提供される。

コンピューティングデバイスは、別個のコンピュータコードライブラリをさらに含むことができる。

削減されたコンピュータコードセット及び別個のコンピュータコードライブラリは、コンピューティングデバイスのオペレーティングシステムの一部とすることができる。別個のコンピュータコードライブラリは、削減されたコンピュータコードセットとは別にデバイスのメモリにロード可能であることが好ましい。

本発明の第５の態様によれば、コンピューティングデバイス上での使用が意図されたコンピュータコードのライブラリを生成する方法であって、コンピューティングデバイスの特定の用途を指定する工程と、コンピューティングタスクを実行する関数セットを識別する工程であって、コンピューティングデバイスの前記用途を実施することを要求される関数セットと、コンピューティングデバイスの用途に従って、かつ前記セットの個別のメンバーによって実行される前記コンピューティングタスクにはよらずに、ライブラリ中の関数がグループ化されるように、ライブラリ中の関数セットを配置する工程と、を含む方法が提供される。

本発明の第６の態様によれば、コンピュータタスクを実行するための関数セットを含むダイナミックリンクライブラリが提供されて、該セット中の各関数が、特定の用途を実施するために関連したコンピューティングデバイスに要求される。

用語「ライブラリ」は、別のコードセットからアクセスすることができる一群のコンピュータコードを指すために本明細書中で使用される。

したがって、いくつかの実施形態では、本発明は、ＸＩＰ又はＲＡＭメモリを削減して、機能セットに差異を設けることを考慮すると共に、同時に提供する機能に関わりなく製品ファミリーの全てのメンバー間の互換性を維持するための方法を提供する。

本考案の好ましい態様は、デバイス上のＸＩＰ又はＲＡＭメモリを節約するための機構を提供し、この機構は、ＮＡＮＤフラッシュ記憶メモリ中の他の（コアではない）実行可能ファイル（ｅｘｅｃｕｔａｂｌｅ）と一緒になって、デバイスのコアオペレーティングシステムを提供する。

コアＯＳイメージは、通常全てのＯＳの従属物と共に実行可能なファイルを含み、立ち上げ時にＮＡＮＤフラッシュからＲＡＭに再帰的にコピーされる。このコアＯＳイメージは、ＮＡＮＤフラッシュ上の単一のファイルとして供給され、イメージがＲＡＭにコピーされるとき、コアＯＳイメージは、従来のＸＩＰリードオンリーファイルシステム（ＲＯＦＳ）中にマルチファイル（multiple files）として生じる。コアではない実行可能ファイルの残りは、ＮＡＮＤフラッシュ上の非ＸＩＰ ＲＯＦＳ中に残存し、要求に応じてロード及びアンロードされ、コアイメージのコンテンツと異なって、これらはメモリの予約された区域を占有する必要はなく、それらが消費するいかなる資源も、それ以上必要とされなくなったとき、解放することができる。

上記に説明したように、差別化された機能セットを有するデバイス上で同一の完全機能付きのコアＯＳのバージョンを提供することにより、必然的に、実際にデバイスの動作に対して全てのコアではない機能に対して、価値がありかつ乏しいＸＩＰメモリが立ち上げ時に割り当てられることになる。さらに、コア全体が静的にリンクされているので、他の目的のために解放するようにＲＡＭを割り当てることは実用的でない。

本明細書中で開示する方法は、このメモリオーバヘッドを削減すると共に完全機能付きのコアＯＳデバイスとの互換性を保持することができる。

機能構成は、２つの異なる形でコンピューティングデバイスに提供できることを理解されたい。１つの型の実行可能なファイル（多くのオペレーティングシステムにおけるＥＸＥとして一般的に知られる）は、単一のエントリポイントを有する単一のアプリケーションを提供し、通常、他のアプリケーションと共用されない機能構成を含む。コアＯＳイメージからのこの型のスタンドアロンで実行可能ファイルを除去することは、特定の内部的メモリ位置に呼び出すことによりアクセス可能となる共用される機能構成を提供しないので、一般に互換性問題を招くことはない。

逆に、共用される機能構成の複数の領域は、一般にダイナミックリンクライブラリ（ＤＬＬ）と呼ばれる、異なる型の実行可能なファイルにより実現される。この型の実行可能ファイルは、同一の機能構成を要求する複数のアプリケーションが１つのＤＬＬを同時に共用できることから、機能構成をモジュラーフォーマットの形で実現できる手段を提供し、メモリオーバヘッドの削減を助ける。一般に開始時に単一のエントリポイントから実行される、単一のアプリケーションを提供する他の型の実行可能ファイルと異なって、ＤＬＬは、それぞれが通常は異なる機能構成を提供する複数のエントリポイントを提供する。

ＤＬＬへのこれらのエントリポイントを識別する２つの主な方法があることに留意すべきである。第１の選択肢は、名称によりエントリポイントを参照することである。第２の選択肢は、序数によりエントリポイントを参照することである。後者の選択肢は、しばしば関数序数マッピング又は関数序数リンクと呼ばれる。

名称は序数に比べて潜在的に長く、名称の定義のために追加のコードを必要とするので、また序数による位置を見つけることに比べ、その名称と合致させることにより関数の所在を見つけることはより長時間を要するので、名称の使用は一般に、序数の使用と比べて、コンピューティングデバイスのメモリ及び他の資源の浪費であると考えられている。

したがって、アクセスポイントの序数リンクは、特に資源を知るオペレーティングシステムにとって、特に、デスクトップ又は可搬型ＰＣデバイスで利用可能な資源と比べて大きく制限された物理資源を有する小型で可搬型でバッテリー電源式の資源制約型デバイス用に設計されたオペレーティングシステムにおいて、好ましい実施形態である。このようなデバイスにとって、コードの効率的使用は、非常に重要であり、携帯電話は、この型のコンピューティングデバイスの１つの例である。本発明の説明は、序数リンクを使用しているが、これは、いずれにせよ本発明の適用性を制限することを意図するものではない。

本発明の基本をなす見識は、ファミリー全体に共通のオペレーティングシステムから引き出される任意の差別化されたコンピューティングデバイスのＤＬＬ中で提供される共用の機能構成について、単一の静的にロードされたオリジナルＤＬＬを、１つのより小さな静的にロードされたホストＤＬＬと１つ以上の複数の動的にロードされるヘルパーＤＬＬとに分割できるという点にある。

ここで、本発明を、添付の図面を参照して、例を使用して説明する。

以下の実施形態は、いかにしてオリジナルＤＬＬの最適分割を実現するか、及びそれによりいかにして複雑な静的依存関係の鎖を切断することにより相当のＸＩＰメモリを節約するかを示す。新しいホストＤＬＬが、いかにして古いＤＬＬと完全にバイナリ互換を残しながら、要求に応じて動的に機能構成（functionality）をロードするかを説明する。分割されたある機能構成を提供するようホストＤＬＬが要求された場合、これは、要求を満足するために適切なヘルパーＤＬＬをロードする。その後、ヘルパーＤＬＬがそれ以上要求されないとき、これはアンロードされ、メモリは解放される。

＜オリジナルＤＬＬ分割＞
第１の工程は、任意の特定の差別化されたデバイス用に１組のオリジナルＤＬＬを分割して、このデバイスの典型的な用途に対する１組の使用ケースを生成する方法を決定する。これは、当業者にはよく知られた技術である。考慮対象デバイスがファミリー中の他のデバイスと差別化されるということは、特有の使用ケースを生成することが比較的簡単であることを意味することに留意されるべきである。

第２の工程は、オリジナルＤＬＬを使用してデバイスファミリーに対する包括的な試験用オペレーティングシステムを構築し、次いで前述の工程でもたらされた使用ケース中で実行されるＤＬＬ中の全ての関数パスのプロファイルを得ることである。このデータに対するその後の分析は、どの使用ケースでも全く使用されない関数群、１つの使用ケースで使用される関数群、又は非常にまれな使用ケースで使用される関数群を決定することを可能とする。異なる使用ケースに渡って高い再使用レベルを有する関数は、ホスト（静的）ＤＬＬ中に置かれることになり、異なる使用ケースに渡って低い再使用レベルを有する関数は、ヘルパー（ダイナミック）ＤＬＬ中に置かれることになろう。コンピューティングデバイス立ち上げの使用ケースは、特別のものとみなされるべきであり、デバイスが立ち上げられるときに実行される関数は、これが、出現する唯一の使用ケースであったとしてもホストＤＬＬ中に保持されることに留意すべきである。

第３の工程は、低い再使用レベルを持つ関数を分析して、特定のいくつかの使用ケースの回りにクラスタ化しているかどうかを判断する。そうである場合、複数のヘルパーＤＬＬを生成するための明確なケースが存在し、というのも、こうすることが、単一のヘルパーＤＬＬを有する場合に比べより迅速かつ効率的な、要求される機能構成をロードする方法だからである。

この実施形態では、各ヘルパーＤＬＬは、機能的に配列されるのではなく使用ケースに沿って配列されることに留意するべきである。このことは、使用度合いにかかわらず便宜的に全ての関連する機能構成を単一のＤＬＬにまとめる傾向がある旧来のＤＬＬ設計と対比することができる。例えば、全ての数学的関数を単一の数学用ＤＬＬに寄せ集めることがよくある。この実施形態により、グルーピングは、一層利用者中心となり、電話の立ち上げには、コサイン関数が必要であり、またアプリケーションを実行させるにはタンジェント関数が必要となる場合、従来の設計の考え方ではこれらを一緒にしたであろうが、これらは別個のＤＬＬ中に配置されることになろう。

いずれの関数をヘルパーＤＬＬ中に移動するかを評価する第４のかつ最後の工程は、ホストＤＬＬに割り当てられている関数に内在するコールグラフを繰り返し分析することである。関数の直下のコールグラフが大きいほど、より強い従属関係があり、また、ヘルパー中にこれを移動することにより得ることができる節約も大きくなる。この工程は、静的従属関係の連鎖を分析する能力を有するので、最大級の利益をもたらすことができることに留意すべきである。探索は、狭い範囲の関数が、従属ＤＬＬの深いツリーに結びつく場所を検出することであり、このような場所は、ピンチポイントとして知られている。このことは、関数グループの可能な組合せを組み替えて、ヘルパーＤＬＬに対する最適な分割を検出する数学的処理を介して手動又は自動で行うことができる。ピンチポイントが識別されたとき、従属関係ツリーの最上位の関数又は関数群は、最上位にある関数から呼ばれる全ての関数と共に、１つ又は複数の別個のライブラリに移動することができる。

上記の工程を図１に図式的に示す。

残りの図は、最後の２つの工程を例示する。図２は、プロファイリング及びコールグラフ分析により収集することができる情報の形式についてと、異なるＤＬＬの関数及びメソッド間の従属関係をいかにして分離できるかについてとを示す。図３及び図４は、これらの従属関係が、いかにして２つの異なる使用ケースにクラスタ化できるかを示す。

図２、３及び４に示すように使用ケース１は、デバイス立ち上げの特別なケースであり、したがって、全てのそれらの従属関係で使用するメソッド及び関数は、コアＯＳイメージ中に残り、静的にリンクされ続ける。一方、使用ケース２は、デバイスの利用者によって開始される、或いは特定の外部イベントによりトリガーされるものである。使用するメソッド及び関数は、新しい動的にロードされたＤＬＬに移動することができ、その従属ＤＬＬが、他の使用ケースで必要とされない場合、これらもまた、動的にロードすることができる。図５は、分析により提示された分割を示し、図６は、使用ケース１をより詳細に示し、また図７は、使用ケース２をより詳細に示す。

＜ホストＤＬＬからヘルパーＤＬＬへのパッシングコール＞
これに対する機構は、通常、オリジナルＤＬＬからホストＤＬＬを生成するとき同時に加えられることになる。ホストＤＬＬは、スタブコードを持つヘルパーＤＬＬに委任されている関数を置換することになる。スタブコードは、当初の要求を満足する処理を何も実行しないコードを意味する。この場合、スタブコードが行うのは、適切なヘルパーＤＬＬ中の適切な関数に呼び出しを通過させることだけである。このメソッドは、オリジナルＤＬＬをホストＤＬＬ及び複数のヘルパーＤＬＬに分割することを可能とする。

＜ヘルパーＤＬＬのロード＞
ヘルパーＤＬＬをロードするにはいくつかの方法がある。

ａ）ヘルパーＤＬＬは、任意の関数に対する要求に応じてロードすることができる。これは、いずれの呼び出し元に対しても透過的であり、残りのホストＤＬＬは、オリジナルＤＬＬとバイナリ互換である。ヘルパーＤＬＬをロードするためのコード（必要であれば）は、ホストＤＬＬとして同時に生成されるスタブコード中に含まれることになろう。

ｂ）ヘルパーＤＬＬは、適切な機能構成の可用性に対する必要性が明らかになった時点に達すると、アプリケーション又はクライアントからの直接の要求を介して事前にロードすることができる。この機構は、アプリケーション又はクライアントが修正される必要があり、同一のファミリー中の各種デバイスに対して各種バージョンが必要となるという短所を有する。

ｃ）ヘルパーＤＬＬは、適切な機能構成が必要な場合を特定するために使用し得るパターンを使用ケース分析が示した場合、或いは、それを要求する使用ケースが開始された場合に、事前にロードすることができる。これは、アプリケーション又はクライアントに対して透過的となる。例えば、使用ケース「ｂ」に対して要求される関数のグループの直前に関数「ｙ」が常に呼び出されることが分かっている場合、必要時に動作準備完了となるように使用ケース「ｂ」に対する適切なヘルパーのロードを非同期に開始することができる。これに対するトリガーは、ホストＤＬＬが生成されたとき、関数「ｙ」に対するコード中に含めることができる。この機構は、１つ以上のホストＤＬＬにより要求されるヘルパーＤＬＬを同一の使用ケースにリンクさせることができ、したがって、使用ケースが特定されると、複数のホストＤＬＬに対する適切なヘルパーＤＬＬを全てトリガーすることができるという利点を有する。この機構の変形は、関数「ｙ」に対して、適切なロードをトリガーするシステム全体に渡る通知機構（例えば、公表及び加入サーバ）の使用を行うことであろう。ヘルパーＤＬＬをロードするためのコードは、分析によって識別されたスタブ関数に追加することができる。

＜ヘルパーＤＬＬのアンロード＞
ヘルパーＤＬＬが使用された後、かつもはや必要とされないとき、ヘルパーＤＬＬはアンロードされ、占有していたメモリは、他の用途のために開放することができる。ヘルパーＤＬＬをアンロードするためにはいくつかの考えられる機構がある。

ａ）ヘルパーＤＬＬは、適切な機能構成の可用性がもはや必要ではないことが明らかになった時点に達すると、アプリケーション又はクライアントによる直接の要求を介して事前にアンロードすることができる。この機構は、アプリケーション又はクライアントが修正される必要があり、同一のファミリー中の各種デバイスに対して各種バージョンが必要となるという短所を有する。

ｂ）ヘルパーＤＬＬは、適切な機能構成がもはや必要ない場合を特定するために使用し得るパターンを使用ケース分析が示した場合、或いは、それを要求する使用ケースが終了した場合に、事前にアンロードすることができる。これは、アプリケーション又はクライアントに対して透過的となる。例えば、使用ケース「ｂ」に対して要求される関数のグループが関数「ｙ」の後でもはや呼び出されないことが分かっている場合、関数「ｙ」の直後に使用ケース「ｂ」に対するヘルパーをアンロードすることができる。これに対するトリガーは、ホストＤＬＬが生成されたとき、関数「ｙ」に対するコードを含めることができる。この機構は、１つ以上のホストＤＬＬにより要求されるヘルパーＤＬＬを同一の使用ケースにリンクさせることができ、したがって、使用ケースが特定されると、複数のホストＤＬＬに対する複数のヘルパーＤＬＬのアンロードをトリガーすることができるという利点を有する。ヘルパーＤＬＬをアンロードするためのコードは、分析によって識別された適切なスタブ関数に追加することができる。この機構の変形は、関数「ｙ」に対して、適切なアンローディングをトリガーするシステム全体に渡る通知機構（例えば、公表及びサーバ加入）の使用を行うことであろう。

ｃ）ヘルパーＤＬＬは、その関数の１つも呼ばれなかった期間後アンロードすることができ、この機構は、メモリページングに関連して用いられる最小使用頻度アルゴリズムに多少類似している。

同一のファミリー中の他のモデルと互換性を保持しながら、同一のファミリーに属するコンピューティングデバイスの異なる機能のモデルのＲＡＭ要件を各特定のモデルの機能レベルに合致させることができる方法を上記に説明した。この設計概念の実施形態は、コアオペレーティングシステムイメージがＮＡＮＤフラッシュ又は他の型の実行可能でない不揮発性記憶メモリ中に備えられ、同イメージが立ち上げ時にＲＡＭに複写されるデバイスに対して特に好適であろう。好ましい実施形態は、デバイスに対して使用ケースを生成することにより、差別化されたデバイスによる使用頻度が低い機能構成を識別し、次いで、デバイスファミリーの完全機能付きのメンバー上でこれらの使用ケースにより呼び出される関数のプロファイルを得ることを含む。結果として生じるコールグラフの分析は、コアＯＳイメージ中にホストＤＬＬとして残すために必要とされる関数、及びヘルパーＤＬＬから合理的に動的に読み出すことができるものを明らかにする。デバイスファミリーとのバイナリ互換性は、ホストＤＬＬからヘルパーＤＬＬに移動されて削除されたこれらの関数をヘルパーＤＬＬにコール及びリクエストを引き渡すスタブと置き換えることにより維持される。

様々な利点が、本発明の実施形態を使用することにより得られることが、上記に説明した特定の例から理解できる。いくつかの潜在的利点は、次の通りである。

・このようなデバイスのファミリーに属するＮＡＮＤフラッシュコンピューティングデバイス中のＯＳコアイメージのサイズは、当該デバイスに要求される機能構成に合わせることができると共に、完全機能付きの同一のファミリー中の他のデバイスとのバイナリ互換性を保持することができる。

・ＮＡＮＤフラッシュ中のコアＯＳイメージのサイズがより小さいことは、当該イメージが、ロードされた場合のＲＡＭの消費が少なくなることを意味する。

・ＮＡＮＤフラッシュ中のコアＯＳイメージのサイズが小さいことは、当該デバイスがより速く立ち上がることを意味する。

・要求されるＲＡＭが少ないことは、削減された機能セットを有するデバイスが、低コストで製造できかつ自然の資源の使用が少ないことを意味する。

・要求されるＲＡＭが少ないことは、削減された機能セットを有するデバイスが、消費電力が少ないことを意味する。

別の実施が可能であり、また上記に説明した方法及び実施の様々な修正が、添付の請求の範囲により特定される、本発明の範囲内で行うことができることが当業者には理解されるであろう。

関数セットの分析を例示するフローチャートである。 、 、 、 、 、 本発明において使用することができるいくつかのコード分析技術を示す図である。

Claims (18)

1. コンピューティングデバイス中での使用が意図されたコンピュータコードセットのサイズを削減する方法であって、前記コードセットは、前記コンピューティングデバイスの電源が入ったとき自動的にメモリ中にロードされることが意図され、コンピューティングタスクを実行するための関数を含んでおり、
   前記コンピューティングデバイスの特定の用途を指定する工程と、
   前記コンピューティングデバイスの前記用途を実行する（implement）ために要求される前記コンピュータコードセット中の関数を識別する工程と、
   前記識別された関数を前記コードセットから除去し、前記識別された関数を別個のコンピュータコードライブラリに配置する工程と、
   を含む方法。
2. 前記識別された関数を除去する工程は、前記識別された関数を、前記別個のコンピュータコードライブラリを呼び出すように構成されたコードで置換する工程を含み、それによって、前記削減されたコンピュータコードセットと前記別個のコンピュータコードライブラリとの結合された機能構成（functionality）が、元のコードセットの前記機能構成と等価である請求項１に記載の方法。
3. 前記要求される関数を識別する前記工程は、
   テスト用コンピューティングデバイス上で前記用途を実行するために前記元のコンピュータコードセットを実行する工程と、
   前記コンピュータコードセット中のいずれの関数が前記実行中に使用されるかを決定する工程と、
   を含む請求項１又は請求項２に記載の方法。
4. 前記コンピュータコードセット中のいずれの関数が前記実行中に使用されるかを決定する前記工程は、関数プロファイリング又はコールグラフ分析技術の使用を含む請求項３に記載の方法。
5. 前記コンピューティングデバイスの前記用途は、前記コンピューティングデバイス中で頻繁には使用されないことが予想されるアプリケーションを示す請求項１乃至４のいずれか１項に記載の方法。
6. 前記コンピューティングデバイスの前記用途は、前記デバイスの動作に必須ではないアプリケーションを示す請求項１乃至５のいずれか１項に記載の方法。
7. 前記別個のコンピュータコードライブラリは、ダイナミック・リンク・ライブラリである請求項１乃至６のいずれか１項に記載の方法。
8. 別個のコンピュータコードライブラリ中で前記識別された関数を配置する前記工程は、関連したコンピューティングデバイスの対応した用途に従って関数がクラスタ化されるライブラリを結果として生じる請求項１乃至７のいずれか１項に記載の方法。
9. 前記コンピュータコードセットは実行可能なコードである請求項１乃至８のいずれか１項に記載の方法。
10. 請求項１乃至９のいずれか１項に記載の方法から得られる削減されたコンピュータコードセット。
11. 請求項１乃至９のいずれか１項に記載の方法から得られる前記削減されたコンピュータコードセットを含むオペレーティングシステム。
12. 請求項１に記載の前記別個のコンピュータコードライブラリをさらに含む請求項１１に記載のオペレーティングシステム。
13. 請求項１乃至９のいずれか１項に記載の方法から得られる前記削減されたコンピュータコードセットを含むコンピューティングデバイス。
14. 請求項１に記載の前記別個のコンピュータコードライブラリをさらに含む請求項１３に記載のコンピューティングデバイス。
15. 前記削減されたコンピュータコードセット及び前記別個のコンピュータコードライブラリは、前記コンピューティングデバイスのオペレーティングシステムの一部である請求項１４に記載のコンピューティングデバイス。
16. 前記別個のコンピュータコードライブラリは、前記削減されたコンピュータコードセットとは別に前記デバイスのメモリにロード可能である請求項１４又は請求項１５に記載のコンピューティングデバイス。
17. コンピューティングデバイス上での使用が意図されたコンピュータコードのライブラリを生成する方法であって、
    前記コンピューティングデバイスの特定の用途を指定する工程と、
    コンピューティングタスクを実行する関数セットを識別する工程であって、前記関数セットが前記コンピューティングデバイスの前記用途を実行することを要求される工程と、
    前記コンピューティングデバイスの用途に従うが、前記セットの個別のメンバーによって実行される前記コンピューティングタスクには従わずに、前記ライブラリ中の前記関数がグループ化されるように、前記ライブラリ中の前記関数セットを配置する工程と、
    を含む方法。
18. コンピューティングタスクを実行するための関数セットを含むダイナミック・リンク・ライブラリであって、前記セット中の各関数が、特定の用途を実行するために関連したコンピューティングデバイスに要求されるダイナミックリンクライブラリ。

Images