(57)【要約】【課題】起動時にロードするＯＳイメージサイズを抑制する事で起動高速化を実現しながらも、その後の実行スピードも極力低下させない仕組みを実現する。【解決手段】ページフォルトを契機にしたデマンドページング機構２２によるデマンドページング時に、ＯＳコードの実行履歴２３を収集し、収集したＯＳコードの実行履歴２３を外部記憶装置１３に保存し、システムの再起動時にｂｏｏｔ２５が参照でき、再起動時には、ｂｏｏｔ２５が保存されたＯＳコードの実行履歴２３を元に、前回起動時に実行した実績のあるＯＳコードのみをメインメモリ１２にロードする。【選択図】図２
2012123762.tif 000002
【特許請求の範囲】
【請求項１】
デマンドページング機構を利用した情報処理装置であって、
ページフォルトを契機にした前記デマンドページング機構によるデマンドページング時に、ＯＳコードの実行履歴を収集する収集手段と、
前記収集手段で収集したＯＳコードの実行履歴を外部記憶装置に保存し、システムの再起動時にブートストラッププログラムが参照できる参照手段と、
前記再起動時には、前記ブートストラッププログラムが前記保存されたＯＳコードの実行履歴を元に、前回起動時に実行した実績のあるＯＳコードのみをメインメモリにロードするロード手段と
を具備する事を特徴とする情報処理装置。
【請求項２】
前記保存されたＯＳコードの実行履歴を元に、前回実行された部分だけを起動時にメインメモリにロードして、システムを高速に起動する事を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記再起動時に、前回起動時に実行した実績のあるＯＳコードのみをメインメモリにロードした場合、ロードした部分と未ロード部分をページテーブルを操作する事によって、未ロード部分だけが実行時に前記ページフォルトを発生するように初期化する初期化手段を更に具備する事を特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記実行履歴に、前回実行された部分が無い場合には、最低限必要なＯＳ機能部分をロードする事を特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記実行履歴が前記外部記憶装置に存在しない場合には、前記ＯＳコードの全体をロードする事を特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記実行履歴が所定のしきい値を超えて収集された場合には、上限を超えた部分を起動時にロードしない事を特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
前記ＯＳコードの中でほとんど実行される事の無い、特別な例外処理部分に関する位置情報を持たせる事で、前記実行履歴がこれと一致する場合には、前記実行履歴としては保存せずに破棄することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
前記実行履歴を起動する毎に収集し、かつその情報を１回ごとにクリアせずにカウントアップする事により実行頻度の高い部分を明確化し、当該実行頻度の高い部分だけをロードして実行効率を向上させる事を特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
【請求項９】
デマンドページング機構を利用した情報処理装置による情報処理方法であって、
ページフォルトを契機にした前記デマンドページング機構によるデマンドページング時に、ＯＳコードの実行履歴を収集する収集ステップと、
前記収集ステップで収集したＯＳコードの実行履歴を外部記憶装置に保存し、システムの再起動時にブートストラッププログラムが参照できる参照ステップと、
前記再起動時には、前記ブートストラッププログラムが前記保存されたＯＳコードの実行履歴を元に、前回起動時に実行した実績のあるＯＳコードのみをメインメモリにロードするロードステップと
を具備する事を特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デマンドページング機構を利用した情報処理装置及び情報処理方法に関するものである。
【背景技術】
【０００２】
従来、システムの起動時にはブートストラッププログラム（以降「ｂｏｏｔ」と表記）が、オペレーティングシステム（以降「ＯＳ」と表記）全体を不揮発メモリ又は外部記憶装置から、ＲＡＭにコピーした後、ＯＳのエントリコードにＪＵＭＰして起動していた。この手法は、単純かつ明快であるので、多くのシステムで採用されている。
【０００３】
ところが、近年、ＯＳの機能拡張によりそのコードサイズが大きくなってきた。特に、ＵＮＩＸ（登録商標）系のＯＳなどを使った場合、ＯＳのサイズが数ＭＢを超える事も有り、これを全てメモリに展開するのに時間がかかり、その結果、システムの起動スピードが低下する問題があった。
【０００４】
これに対処するため、圧縮ＯＳイメージを使ったメモリ転送で高速化する手法や、ＲＡＭをバッテリで保持しておいて再展開を抑制する手法などが提案されて使われている。ところが、これらの手法は効果が低かったり、ハードウェアの支援が必要でコストがかかったりするため、必ずしも有効な解決策とはなっていない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−３１６８０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記の様なＯＳコードの展開に時間がかかる問題は、ＯＳのイメージサイズが巨大である事に起因する。つまり、起動時に展開するＯＳコードが十分小さければ、展開にかかる時間の問題は解決できる。
【０００７】
この点に目をつけた解決策として、上記特許文献１の技術がある。この特許文献１の技術では、ＯＳの中で起動に必要な部分だけをまとめておき、これを先行してＲＡＭに展開する。この状態でＯＳの起動を開始し、残りの部分は必要に応じてページフォルトを契機としたデマンドページング機構でダイナミックロードするというものである。このように、上記特許文献１の手法は、確かに起動時のＲＡＭへの展開量を抑制する事が可能なので、有効な解決策である。ただし問題もある。ＯＳの残りの大部分はＲＡＭ等に展開されていないので、その後のスループットがデマンドページングのオーバーヘッドにより低下してしまう。
【０００８】
本発明は、このような問題点に鑑みてなされたものであり、起動時にロードするＯＳイメージサイズを抑制する事で起動高速化を実現しながらも、その後の実行スピードも極力低下させない仕組みを実現することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の情報処理装置は、デマンドページング機構を利用した情報処理装置であって、ページフォルトを契機にした前記デマンドページング機構によるデマンドページング時に、ＯＳコードの実行履歴を収集する収集手段と、前記収集手段で収集したＯＳコードの実行履歴を外部記憶装置に保存し、システムの再起動時にブートストラッププログラムが参照できる参照手段と、前記再起動時には、前記ブートストラッププログラムが前記保存されたＯＳコードの実行履歴を元に、前回起動時に実行した実績のあるＯＳコードのみをメインメモリにロードするロード手段とを具備する。
また、本発明は、上述した情報処理装置による情報処理方法を含む。
【発明の効果】
【００１０】
本発明によれば、起動時にロードするＯＳイメージサイズを抑制する事で起動高速化を実現しながらも、その後の実行スピードも極力低下させない仕組みを実現することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１の実施形態に係る情報処理装置のシステム構成の一例を示すブロック図である。
【図２】本発明の第１の実施形態を示し、図１のＣＰＵによって実行履歴を収集し、その実行履歴を利用する事で次の起動を高速化する流れの一例を示す模式図である。
【図３】本発明の第１の実施形態を示し、デマンドページング機構で未ロードのＯＳコードを検出する過程の一例を示す模式図である。
【図４】本発明の第１の実施形態を示し、ｂｏｏｔが実行履歴を参照してメインメモリに必要なＯＳイメージを展開する処理の一例を詳細に示す模式図である。
【図５】本発明の第１の実施形態を示し、ｂｏｏｔがＯＳイメージをメインメモリに展開する処理の一例を示すフローチャートである。
【図６】本発明の第１の実施形態を示し、ＯＳコアがメモリにロードされ、ｂｏｏｔからＯＳコアのエントリコードにＪＵＭＰした後の、ＯＳコア内のページテーブル初期化処理の一例を示すフローチャートである。
【図７】本発明の第１の実施形態を示し、ページフォルトが発生した時のＯＳコアにおける処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下に、図面を参照しながら、本発明を実施するための形態（実施形態）について説明する。
【００１３】
（第１の実施形態）
図１は、本発明の第１の実施形態に係る情報処理装置のシステム構成の一例を示すブロック図である。
【００１４】
図１において、１０は、本実施形態に係る情報処理装置である。
図１において、１１は、ＣＰＵであり、情報処理装置１０のほぼ全てを管理している。
図１において、１２は、メインメモリであり、ＣＰＵ１１からアクセスすることが可能である。
【００１５】
図１において、１３は、外部記憶装置である。
図１において、１４は、不揮発メモリである。この不揮発メモリ１４は、一般にＦＬＡＳＨメモリであり、プログラムはここに格納されている。
情報処理装置１０のシステム構成によっては、外部記憶装置１３として、不揮発メモリ１４を利用して、一時ファイルを格納する場合もある。
【００１６】
図１において、１５は、情報等を入力する入力インタフェース（入力Ｉ／Ｆ）である。
図１において、１６は、情報等を出力する出力インタフェース（出力Ｉ／Ｆ）である。
【００１７】
また、本実施形態では、以下の様なシステムを想定する事とする。
・ＯＳ全体のコードサイズ＝４ＭＢ
・ＯＳコアのサイズ＝３２ＫＢ
・１ページのサイズ＝４ＫＢ
【００１８】
図２は、本発明の第１の実施形態を示し、図１のＣＰＵ１１によって実行履歴を収集し、その実行履歴を利用する事で次の起動を高速化する流れの一例を示す模式図である。
【００１９】
図２において、２１は、ＯＳの中で最低限必要な機能だけを集めたコアコード（ＯＳコア）である。このＯＳコア２１は、システム起動時に必ずメモリに展開される必要がある。なぜなら、ＯＳの実行位置の履歴を取るために、以下の様な機構を必要とするからである。
・デマンドページング機構（２２）
・最低限の初期化コード
・最低限のデバイスドライバ
【００２０】
図２において、２２は、ＯＳコア２１に含まれる、デマンドページング機構である。これは、ページフォルトを検出し、その履歴を記録後、未ロード部分のＯＳコードをメインメモリ１２に展開する機能を持つ。
【００２１】
図２において、２３は、実行履歴であり、デマンドページング機構２２によって更新される。この実行履歴２３は、ＯＳコードの実行個所の情報として、次回起動時に不揮発メモリ１４に格納されている、ブートストラッププログラムであるｂｏｏｔ２５によって参照される。
【００２２】
図２において、２４は、ＯＳイメージ本体である。ここには、ＯＳコア２１が含まれており、外部記憶装置１３か不揮発メモリ１４に保存されている。図２の例では、ＯＳイメージ本体２４は、外部記憶装置１３に保存されている。
【００２３】
図２において、２５は、ｂｏｏｔであり、システムの起動時に最初に実行されるプログラムである。ｂｏｏｔ２５は、実行履歴２３の情報を元に、不揮発メモリ１４か、又は、外部記憶装置１３内のＯＳイメージ２４から、ＯＳコア２１と前回実行したＯＳコードをメインメモリ１２にコピー（展開）して起動する。
【００２４】
この様に起動された後、デマンドページング機構２２は、再び、ＯＳプログラムのどの部分が実行されたかを監視し、その結果を実行履歴２３として書き出す。このサイクルによって、起動高速化を実現する。
【００２５】
図３は、本発明の第１の実施形態を示し、デマンドページング機構２２で未ロードのＯＳコードを検出する過程の一例を示す模式図である。
【００２６】
実行履歴２３にＯＳコア位置情報しか存在しない場合、ｂｏｏｔ２５は、ＯＳコア２１だけをメインメモリ１２に展開し、ＯＳコア２１のエントリアドレスにＪＵＭＰする。ＯＳコア２１は、ｂｏｏｔ２５から起動されると最低限のシステム初期化を行うが、その初期化過程の中でページテーブル３１を構築する。
【００２７】
今回の実施形態では、ページテーブル３１のイメージは図３の様になる。つまり、ＯＳコア２１の３２ＫＢの領域に対応するページテーブル３１（ｐａｇｅ０〜ｐａｇｅ７）の属性ビット３２が１（有効）にセットされる。また、その他のＯＳの領域に対するページテーブル３１（ｐａｇｅ８〜ｐａｇｅ１０４８５７５）の属性ビット３２が０（無効）に設定される。
【００２８】
もし、実行履歴２３にページ位置情報が存在した場合には、そのページはｂｏｏｔ２５によってメモリに展開済みであるので、そのページに対応するページテーブル３１の属性ビットは１（有効）に初期化される。
【００２９】
この様に初期化された後、システムがスタートする。関数呼び出しやＪＵＭＰ命令の実行によりＯＳの処理がＯＳコア２１外に出る（図３の［１］）と、それはページフォルトとしてＣＰＵ１１に補足され、デマンドページング機構２２に処理が移る（図３の［２］）。
【００３０】
デマンドページング機構２２は、ページフォルトを起こしたアドレスをＣＰＵ１１から取得すると、その結果に基づき実行履歴２３を更新する（図３の［３］）。その後、外部記憶装置１３にあるＯＳイメージ２４本体から該当するＯＳコードの１ページをメインメモリ１２に展開し、対応するページテーブル３１の属性ビットを１（有効）に変更する。そして最後に、ページフォルトを起こしたアドレスから実行を再開させる（図３の［４］）。
【００３１】
このサイクルによって、実際に実行したＯＳのコード位置を実行履歴２３として記録していく。
【００３２】
図４は、本発明の第１の実施形態を示し、ｂｏｏｔ２５が実行履歴２３を参照してメインメモリ１２に必要なＯＳイメージを展開する処理の一例を詳細に示す模式図である。
【００３３】
システムが起動すると、不揮発メモリ１４にあるｂｏｏｔ２５に制御が移る。ｂｏｏｔ２５は、外部記憶装置１３又は不揮発メモリ１４にある実行履歴２３を参照する（図４の［１］）。この実行履歴２３にＯＳコア位置情報しかない場合には、ＯＳコア２１だけをメインメモリ１２に展開し、エントリアドレスにＪＵＭＰする。実行履歴２３にページ位置情報もある場合には、その情報を元にアクセスしたコード位置を算出し、ＯＳイメージ２４から該当するコードを含むページをメインメモリ１２に展開する（図４の［２］）。そしてこの処理を繰り返して、前回アクセスした全てのページを展開後、エントリアドレスにＪＵＭＰする（図４の［３］）。
【００３４】
図５は、本発明の第１の実施形態を示し、ｂｏｏｔ２５がＯＳイメージをメインメモリ１２に展開する処理の一例を示すフローチャートである。以下、各処理について述べる。
【００３５】
まず、ステップＳ５１において、ＣＰＵ１１は、実行履歴ファイルが存在するか否かを判断する。この判断の結果、実行履歴ファイルが存在しない場合には、ＯＳコア位置情報やページ位置情報を得る事が出来ないので、本発明の起動高速化を適用する事は出来ない。よって、この場合には、ステップＳ５８に進み、ＯＳイメージ全体をメインメモリ１２に展開後、ＯＳエントリにＪＵＭＰして、図５のフローチャートの処理を終了する。
【００３６】
一方、ステップＳ５１の判断の結果、実行履歴ファイルがある場合には、ステップＳ５２以降に進み、本発明の起動高速化の処理を継続する。
【００３７】
ステップＳ５２に進むと、ＣＰＵ１１は、実行履歴ファイルからＯＳコア２１の位置情報を取得する。そして、ＣＰＵ１１は、ＯＳイメージから該当する部分をメインメモリ１２に展開する。
【００３８】
続いて、ステップＳ５３において、ＣＰＵ１１は、実行履歴に、ページ位置情報がまだあるか否かを判断する。この判断の結果、全てのページ位置情報を処理するか、又はページ位置情報がまったく無い場合には、必要なＯＳコードをメインメモリ１２に展開する処理が終わったと判断できるので、ＯＳエントリにＪＵＭＰして、図５のフローチャートの処理を終了する。
【００３９】
一方、ステップＳ５３の判断の結果、実行履歴に、ページ位置情報がまだある場合には、ステップＳ５４に進む。
ステップＳ５４に進むと、ＣＰＵ１１は、実行履歴からページ位置情報を取り出す。
【００４０】
続いて、ステップＳ５５において、ＣＰＵ１１は、ここでページ位置情報から該当するＯＳイメージのファイル位置を算出する。
【００４１】
続いて、ステップＳ５６において、ＣＰＵ１１は、算出したファイル位置に対応するＯＳコードを１ページ分、メインメモリ１２にロードする。
【００４２】
続いて、ステップＳ５７において、ＣＰＵ１１は、次のページ位置情報をインデックスして、即ち、次のページ位置情報に進んで、ステップＳ５３に戻る。
【００４３】
図６は、本発明の第１の実施形態を示し、ＯＳコアがメモリにロードされ、ｂｏｏｔからＯＳコアのエントリコードにＪＵＭＰした後の、ＯＳコア内のページテーブル初期化処理の一例を示すフローチャートである。以下、各処理について述べる。
【００４４】
まず、ステップＳ６１において、ＣＰＵ１１は、ページテーブルの全要素をすべて０で初期化する。ここで、ページテーブルの要素が０であると言う事は、そのページには何も割りあたっていない事を意味する。つまり、このアドレスへのアクセスは、ページフォルトとしてＯＳコアに検出される。
【００４５】
続いて、ステップＳ６２において、ＣＰＵ１１は、ＯＳコア部分に対応するページテーブルを初期化する。本実施形態では、ＯＳコア部分のサイズを３２ＫＢ、ページサイズを４ＫＢと仮定しているので、８ページ分のページテーブルを初期化することになる。ここで、初期化するのは、ページテーブルの各要素、物理アドレスと属性ビットである。物理アドレスは、ＯＳコアがマッピングされているアドレスであり、属性ビットは、本実施形態では１である。
【００４６】
続いて、ステップＳ６３において、ＣＰＵ１１は、実行履歴に記録されているページ位置情報に対応するページテーブルを初期化する。ページ位置情報は、ＯＳイメージに対するファイルページ位置として記録されているので、これを元にＯＳイメージがロードされている物理アドレスからのオフセットを算出し、ページテーブルの要素を初期化する。
【００４７】
続いて、ステップＳ６４において、ＣＰＵ１１は、実行履歴のある全てのページ位置情報を０クリアする。これは、今回の再起動で新しい実行履歴の収集サイクルが始まるからである。このステップＳ６４の処理が終了すると、図６のフローチャートの処理が終了する。
【００４８】
図７は、本発明の第１の実施形態を示し、ページフォルトが発生した時のＯＳコアにおける処理の一例を示すフローチャートである。以下、各処理について述べる。
【００４９】
まず、ステップＳ７１において、ＣＰＵ１１は、ページフォルトを起こしたアドレスがＯＳ空間であるか否かを判断する。この判断の結果、ページフォルトを起こしたアドレスがＯＳ空間で無い場合には、そのページフォルトは、ユーザプログラムの引き起こした物なので、ステップＳ７８に進み、通常のユーザプログラム向けページフォルト処理を行う。その後、図７のフローチャートの処理を終了する。
【００５０】
一方、ページフォルトを起こしたアドレスがＯＳ空間である場合には、ステップＳ７２に進む。
ステップＳ７２に進むと、ＣＰＵ１１は、ステップＳ７１に引き続き、ここでは、ページフォルトを起こしたアドレスがＯＳのコード領域であるか否かを判断する。この判断の結果、ページフォルトを起こしたアドレスがＯＳのコード領域で無い場合には、通常のＯＳ空間におけるページフォルト（例えばメモリ確保）と判断できるので、ステップＳ７９に進み、通常のＯＳ空間におけるページフォルト処理を行う。その後、図７のフローチャートの処理を終了する。
【００５１】
ステップＳ７１とステップＳ７２の判断で共に肯定判断だった場合には、ページフォルトアドレスがＯＳコード領域であると判断できる。よって、この場合は、ＯＳコード領域のデマンドページングであるので、ステップＳ７３以降に進む。
【００５２】
ステップＳ７３に進むと、ＣＰＵ１１は、ページフォルトアドレスからＯＳイメージのファイルページ位置を算出する。
【００５３】
続いて、ステップＳ７４において、ＣＰＵ１１は、ステップＳ７３で算出したファイルページ位置を、実行履歴２３に追記する。
【００５４】
続いて、ステップＳ７５において、ＣＰＵ１１は、通常のデマンドページング処理を行い、ＯＳイメージから該当するＯＳコードを１ページ分、メインメモリに展開する。
【００５５】
続いて、ステップＳ７６において、メモリに展開したページに対応するページテーブルを更新し、再実行時に再びページフォルトが発生しないように、属性ビットとアドレス情報の更新を行う。
【００５６】
続いて、ステップＳ７７において、ＣＰＵ１１は、ページフォルトを起こしたＯＳコードの再実行を行う。その後、図７のフローチャートの処理を終了する。ここまでの処理で、未ロードであった該当コードはメモリに展開され、さらに、対応するページテーブルも更新されているので、再実行は正常に行えるようになっている。
【００５７】
以上のように、本実施形態では、ＣＰＵ１１は、デマンドページング機構を利用した情報処理装置１０において、ページフォルトを契機にしたデマンドページング機構によるデマンドページング時に、ＯＳコードの実行履歴を収集する。また、ＣＰＵ１１は、収集したＯＳコードの実行履歴を外部記憶装置１３に保存し、システムの再起動時にブートストラッププログラムであるｂｏｏｔ２５が参照できる。また、ＣＰＵ１１は、再起動時には、ｂｏｏｔ２５が保存されたＯＳコードの実行履歴を元に、前回起動時に実行した実績のあるＯＳコードのみをメインメモリにロードする。
【００５８】
本実施形態によれば、実際に実行されたＯＳコード部分だけを起動時に展開する事が可能となり、起動スピードが向上する。
また、起動に必要な部分だけを展開するわけではないので、その後のＯＳの実行スピードの低下も最低限に抑える事が出来る。
【００５９】
また、本実施形態では、ＣＰＵ１１は、再起動時に、前回起動時に実行した実績のあるＯＳコードのみをメインメモリにロードした場合、ロードした部分と未ロード部分をページテーブルを操作する事によって、未ロード部分だけが実行時にページフォルトを発生するように初期化する。また、ＣＰＵ１１は、実行履歴に、前回実行された部分が無い場合には、最低限必要なＯＳ機能部分をロードする。
【００６０】
（第２の実施形態）
第１の実施形態では、実行履歴内のページ位置情報は、システムの起動中に無制限に収集するようになっていた。この場合、システムの起動期間が長かったり、様々な用途に使われたりすると、ページ位置情報がどんどん大きくなり最終的にＯＳイメージ本体に限りなく近くなってしまう。こうなると、再起動時にはＯＳイメージを全てロードする事とほとんど変わらなくなってしまい、システムが高速に起動しない恐れがある。
これに対処するため、第２の実施形態では、ページ位置情報の収集に上限を設けるものである。この場合、ｂｏｏｔで上限値の判定を行う様にする。この上限値に達した場合には、それ以上のロードを中断してカーネルエントリにＪＵＭＰする。
具体的に、本実施形態では、ＣＰＵ１１は、実行履歴が所定のしきい値を超えて収集された場合には、上限を超えた部分を起動時にロードしない。
【００６１】
（第３の実施形態）
第１の実施形態では、デマンドページングが発生したＯＳコードは、全て実行履歴に保存していた。この手法では、ほとんど実行されない特別なエラーコードも記録されてしまう恐れがある。その様なコードは、再起動時にメモリに展開されても、ほとんどの場合、実行されないので無駄である。これに対処するために、第３の実施形態では、ＯＳコードの中でほとんど実行されない部分を登録したテーブルを用意する。そして、デマンドページングが発生した時に、そのアドレスをこのテーブルと比較し、もしこのテーブルと一致した場合には実行履歴に記録せずに、通常のデマンドページングだけを行う。こうする事で、めったに発生しない例外コードが実行履歴に登録される事を防ぎ、再起動の速度低下を防ぐ事が可能となる。
具体的に、本実施形態では、ＣＰＵ１１は、ＯＳコードの中でほとんど実行される事の無い、特別な例外処理部分に関する位置情報を持たせる事で、実行履歴がこれと一致する場合には、実行履歴としては保存せずに破棄する。
【００６２】
（第４の実施形態）
第１の実施形態では、実行履歴内のページ位置情報は、再起動時に０クリアされていた。この手法は、単純なので実装が簡単であるが、「ＯＳコードの良く使う部分」を優先してロードする事は出来ない。
【００６３】
よって、第４の実施形態では、「ＯＳコードの良く使う部分」を優先してロードするために、実行履歴内のページ位置情報を再起動時に０クリアしないようにする。そして、デマンドページング発生時に実行履歴内のページ位置情報をチェックし、もし同じ位置情報があった場合には、これをインクリメントする。この様にする事で、起動する毎に毎回アクセスされる「ＯＳコードの良く使う部分」を明確にする事が出来る。
【００６４】
そして、ｂｏｏｔでＯＳコアのロードに引き続き、実行履歴内のページ位置情報を元にしたロードをする段階で、ページ位置情報のカウントが大きいページを優先してロードする。この仕組みと第２の実施形態の仕組みを組み合わせれば、起動時間を犠牲にせずに実行頻度の高いＯＳコードのロードが可能となる。
【００６５】
具体的に、本実施形態では、ＣＰＵ１１は、実行履歴を起動する毎に収集し、かつその情報を１回ごとにクリアせずにカウントアップする事により実行頻度の高い部分を明確化し、当該実行頻度の高い部分だけをロードして実行効率を向上させる。
【００６６】
（第５の実施形態）
ここまで説明してきた、第１〜第４の各実施形態の全てを盛り込んだ実装も可能である。この場合、ページ位置情報の上限があり、かつ実行頻度の低いエラー処理コード等はロードされず、さらに過去に実行された実績のあるコードに順位がつけられ、それに従ってそれらが優先的にロードされるようになる。
【００６７】
［作用］
本発明における実施形態では、「通常の使用において巨大なＯＳコード全てを使う事はない」という前提に立ってなされている。例えばＯＳの構成要素が、割込み管理、メモリ管理、ファイル管理、プロセス管理、ネットワーク管理、デバイス管理・・・などで構成されているとする。この時、ＨＤＤだけを使うならデバイス管理の中のＩＤＥに関するＯＳコードは実行されるが、同じデバイス管理のＳＣＳＩ−ｄｉｓｋに関するＯＳコードは不要のはずである。同様に、ファイルシステム機能でＦＡＴファイルシステムを使うなら対応するコードは必要であるが、ＮＦＳを使用しないならそのコードは不要である。
【００６８】
また、ＯＳはあらゆる不測の事態に備えて、非常に緻密なエラーリカバリコードを抱え込んでいる。これらのコードは、重要ではあるものの、殆どの場合、実行されないままである。この様に、実際には実行されない機能を抱え込んでいるにもかかわらず、ＯＳとしてはユーザがどの機能を使うか事前に想定する事は出来ないため、全ての機能を詰め込んだ「全部入り」のＯＳイメージを作り準備しなければならない。これが、ＯＳイメージが数ＭＢを超える原因の１つになっている。
【００６９】
本発明における実施形態では、上記実行されないコードは起動時にロードせず、実行した実績のあるコードだけをロードする事で起動高速化を実現する。
このＯＳで実際に実行されたコード（＝実行履歴）の取得には、プロセッサのページフォルト機構とＯＳの標準機構であるデマンドページング機構を活用する。デマンドページング機構は、ページフォルトを利用して、メモリにロードされていないコードへのアクセスを検出する。この様なアクセスを検出すると、ページフォルト割込みがプロセッサから通知され、ＯＳのページフォルトハンドラに制御が移る。ページフォルトハンドラは、ロードされていないコード位置を算出し、外部記憶装置又は不揮発メモリからメインメモリにコードを１ページ分展開し、そのコードを再実行する。
【００７０】
つまり、デマンドページング機構は、「実際に実行されたコード」の位置情報を、ページフォルトによって取得する事が出来る。本発明における実施形態では、このデマンドページング機構のページフォルト検出処理を利用し、そのコード位置情報を実行履歴として外部記憶装置又は不揮発メモリに保存する。この様に位置情報を収集しておけば、再起動時に実際にロードすべきコード位置情報をｂｏｏｔに渡す事が可能になる。そして、ｂｏｏｔコードはこの実行履歴を元に、ＯＳで実際に実行された部分だけをメモリに展開して起動する。
【００７１】
上記の様な構成を採れば、実際に実行されたＯＳコード部分だけを起動時に展開する事が可能となり、起動スピードが向上する。
また起動に必要な部分だけを展開するわけではないので、その後のＯＳの実行スピードの低下も最低限に抑える事が出来る。
【００７２】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。
即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
このプログラム及び当該プログラムを記憶したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。
【符号の説明】
【００７３】
１２  メインメモリ、１３  外部記憶装置、１４  不揮発メモリ、２１  ＯＳコア、２２  デマンドページング機構、２３  実行履歴、２４  ＯＳイメージ、２５  ｂｏｏｔ（ブートストラッププログラム）
【図１】
2012123762.tif 000003
【図２】
2012123762.tif 000004
【図３】
2012123762.tif 000005
【図４】
2012123762.tif 000006
【図５】
2012123762.tif 000007
【図６】
2012123762.tif 000008
【図７】
2012123762.tif 000009