株式会社ユビキタスから、まさにコロンブスの卵とも言うべき技術が発表された。「QuickBoot」というシンプルな名前が示す通り、コンピュータ用OSの起動速度を高速化する技術である。その仕組み、発想は明快かつ簡単だが、実際に実現するとなると、かなり難しい問題が頭をもたげてきたという。

　ユビキタスの半田晴彦氏のコメントを交えながら、この技術の面白さと各種製品への応用の可能性、それに一般的なWindows PCの体験レベルを引き上げる可能性について話を進めてみたい。

　QuickBootとはOSの起動プロセスを見直すことで高速化を図るというものだ。今回発表されたのはAndroidに対応したソフトウェア開発キットで、コールドブート(電源が完全にオフの状態)からのスタートアップで1秒でアプリケーションの動作が可能になる。

　起動の様子はこちらのYouTubeのビデオで確認可能だ。

　ではどんな仕組みなのか? と気になる人もいるだろう。そういう方は、まずはこのページをご覧頂いた上で読み進めてほしい。仕組みなんかどっちでもいい! という方は、軽くこのセクションと次のセクションを読み流し、その次に進むといい。

　通常、これらのOSがターゲットにする機器のソフトウェアは、ブート直後のメモリイメージを保存しておき、それをロードして適切な初期化を行ない制御を渡す手法が使われる。PCで言うところのハイバネートからのレジュームである。OSのブートアップ手順を飛ばして、いきなりメモリイメージを構築して動作環境を復元するので、当然起動は高速化されるが、システム全体のサイズが大きくなるとハイバネートモードからの復帰は遅くなる。

QuickBootの仕組み

　これに対してQuickBootでは、OSの核となる部分と、メモリ空間のうち本当に必要な分だけをメモリにロードした段階で、すぐに制御がOSに渡り、アプリケーションの動作も可能になるので、起動速度は常に一定で条件によって遅くなったりはしない。ただ、その手法は「必要なデータを優先的にRAMにコピー」とあるだけで、詳細は明らかにされていない。

　話によると申請中の特許などの絡みもあって、細かな仕組みなどは公開していないそうだ。ただし技術的な困難を解決する特徴的な工夫は必要なものの、OSに加える修整の量は小さく、Androidの場合は「明確には言えないが、簡単にコードの行数を数えられる程度(半田氏)」の修正で実装が可能だという。

　このニュースを最初に聴いた時に気になったのが、「QuickBootは、ARMアーキテクチャと密接に結合して動作する、画期的な起動技術のソフトウェア製品であり、システムの起動に必要なメモリ領域を優先的に自動でメモリ上に復元することが可能です」という部分だ。

　起動プロセスがOSに依存するのは当然だが、CPUにはどのような形で依存しているのか。たとえばx86プラットフォームでも利用可能なのだろうか? 半田氏の答えは「現在、x86プラットフォームでもQuickBootが動作するよう作業を進めています」とのことで、実装を変えれば、どんなOS、どんなCPUでも動作させることが可能だという。

　そこであくまで推測で以下のような手順か? と尋ねたところ「極めて近い」という答えが返ってきた。参考までに半田氏に「こうではないか? 」と尋ねた手順は以下の通り。

・ハイバネートの場合と同様、起動直後のメモリイメージとハードウェア状態を用意
・OSのカーネル部分を読み込み、OSのカーネル部分をオンメモリ、それ以外はストレージ上に存在するようMMU(メモリ管理ユニット：仮想メモリの管理を行なう部分)のステータスをセット。ハードウェアのステータスを復元
・OSに制御を引き渡す(この時点で操作が可能に)
・必要なメモリブロックだけが必要になった分だけ実メモリにロードされながらアプリケーションが動作

　つまり、OSのコードのうち仮想メモリにページアウト禁止となっている部分だけを読み込み、他は全部スワップファイルの中に“退避されていること”にしてしまうのだ。あとはOSとCPUが持つ仮想メモリ機能を通じ、動作をさせながらメモリの状態をOS自身が復元してくれる。

　考え方としてはシンプルだが、方法論的にはほとんど変わらないという。ただし、アイディアが簡単だから実現も簡単なのかというとそうではない。MMU(メモリ管理ユニット)の状態をどのように保管し、保管した瞬間の実メモリの状態を保存できるか。かなり多くの難関が待ち受けていたというが、ひとまずはAndroid+ARMの環境で動作するところまでたどり着いたわけだ。

　上記手法の良いところは、シンプルであるが故にOSやCPUに依存しないことだ。QuickBootはOS内部に機能を埋め込む必要がある。オープンソースではないWindows系などのOSではOSベンダーとの共同作業が必要になるが、「動かせない環境」はほとんどない。

　加えて、ほとんどのコンピュータは使用メモリの多くはアプリケーション自身や、アプリケーションが利用するデータ領域として使われているので、カーネルと最低限のUI部分だけならばメモリサイズも小さい。このため、超高速のコールドブート(電源オフからの起動)ができるわけだ。

QuickBootの起動時間

　もちろん、いくら超高速起動で汎用性の高い技術と言っても、応用範囲が狭ければエンドユーザーにはあまり大きな意味を持たない。しかしQuickBootの応用範囲はかなり幅広い。

　QuickBootの用途として、すぐに思いつくのがデジタル家電への応用だ。現在のデジタル家電はソフトウェアで実現している機能が多く、複雑な製品(特にネットワークへの対応が必要なもの)はLinuxを用いていることがほとんどだ。

　これまでは違ったが、今後はTVもLinux(Androidを含む)インターネットからのオンデマンドビデオ受信再生などを行なうのが当たり前になってくれば(すでに欧米ではそうなってきている)、TVへのLinuxの組み込みも加速するだろう。その時に電源オンからの起動速度を速めようとするとき、QuickBootがかなり有力な解決方法となる。

　従来は数十秒から1分前後かかっていたBlu-ray Discレコーダの起動が超高速化できれば、使い勝手も大きく変化するが、デジタル家電に関しては別の視点もある。それは省電力だ。

　上記の例で言うと、ほとんどのBDレコーダは高速起動モードを備えているので、単に高速起動だけをさせたいならば、これを利用すればいい。しかし、このモードでは電源をオフにしているつもりでも、実のところ内部は動作しているので、待機電力を数W使ってしまう(あるいは数十Wの場合も)。

　ここにQuickBootを適用すれば、予約録画用のタイマー部分を除き、完全に電源を落としてしまっても、すぐに復帰することが可能になる。

　省電力という利点はスマートフォンでも有利になる。スマートフォンは常に電波を受信した状態にしておくため、完全に電源をオフにはできない。しかし携帯電話部分だけをモジュール化しておき、スマートフォン用のメインプロセッサやGPUの電源を完全に落としてしまうことができれば、スマートフォンのバッテリ持続時間は飛躍的に伸びる可能性がある。

　Linuxベースで開発されたネットブック(日本ではほとんどないが)も、同じようにQuickBootを活用できるので、スタンバイさせた状態で電池を消耗してしまったなんてこともなく、高速復帰が可能なハイバネーションモードが利用可能になる。

　しかし、本当に面白いのはその先だ。

　半田氏によると、QuickBootはBIOSやブートローダといった、初期プログラムの読み込み用プログラムとOSの間に入るミドルウェアという位置付けになるそうだ。ということは(カンのいい方は思いつくだろうが)、VMwareのようなコンピュータの仮想化システムにもQuickBootが応用できる。

　仮想マシン自身に、QuickBootの機能を組み込んでおけば、保存しておいた仮想実行環境に1秒復帰できる。これをローカルのコンピュータ上で行なってもいいが、仮想マシンサーバーを作っておき、そこに実行環境を保存。ネットワーク上の任意のコンピュータ上で、前回保存した実行環境をQuickBootで呼び出すという仕組みを作れば、ネットワークを通じていつも使っているコンピュータ環境を、手元のコンピュータから呼び出して利用できるようになる(もちろんクライアントの実メモリサイズの違いなどにもよるが)。

　ネットワーク越しにハイバネーションのデータを呼び出すとかなり時間がかかりそうなイメージがあるが、おそらくLAN内ならばあっと言う間に起動するはずだ。インターネット越しであったとしても、ブロードバンド環境ならば、実用的な速度で起動まで持ち込めるはずだ(もちろん動かすアプリケーションの使うデータが巨大な場合は、しばらくの間、動作が遅くなってしまうだろうが)。

　実際に我々が普段使っているコンピュータで、QuickBootを使うとなるとMicrosoftやAppleがOSの中にQuickBootのコードを組み込まなければならないが、もしそうなった場合は、さらに可能性が広がる(実はユビキタスのコアメンバーには元Microsoftのメンバーが多いので、可能性は決してゼロではない)。

　たとえばEFI(OSを起動するイニシャルプログラムの一種)がQuickBootに対応すると、EFIが高速起動の準備を整えてOSに制御を引き渡すこともできる。メモリイメージにOSのハイバネーションファイルを使うのであれば、その暗号を解く必要があるし、仮想メモリ管理の状態も記録しておく必要があるのでOSとの協調は必要だが、OSに対して大きな変更を加えなくともQuickBootを利用する手はありそうだ。

　このような話でひとしきり盛り上がったのは久しぶり。QuickBootは、一見するととても地味でエンドユーザーには無関係な技術に見えるが、なかなかどうして想像力を掻き立てる興味深い技術だ。コンピュータをベースにしたあらゆる製品の体験レベルを引き上げてくれるものとして、今後の発展を期待したい。