03　IBMiの仮想化 ～IBM iの高度な継承性とセキュリティを実現するTIMI、オブジェクト指向、単一レベル記憶　｜新・IBM i入門ガイド［基礎知識編］

「IBM iの仮想化」といっても実はいくつかの捉え方がある。まずは仮想化の全体像から考えてみたい。なお技術的な説明を簡略化しているところがあるため、可能な限り参考資料を挙げたのでそちらも参照されたい。

現代のコンピュータは、最下位レベルの電子回路から最上位レベルの業務プログラムまで、複数のレベルで階層化・抽象化された構成になっている。あるレベルにおいてはそれより下位のレベルの細かいところは気にしなくてよいようになっている。ハードウェアとソフトウェアの区別というのも実はあいまいで、ある機能をどちらに置くこともできる（参考資料*1、注1）。

その一番身近でわかりやすい例は仮想マシン（Virtual Machine. VM）だろう。VMは物理ホスト上で稼働するソフトウェアとしての存在だが、アプリケーションからはハードウェアに見える。

図表1は、IBM Powerのハードウェアからアプリケーションに至る階層を、仮想化という観点から表現したものである。

図表のあちこちに仮想化が登場する。IBM Powerとしての「仮想化」は、すべてのOSに共通するものであり、別途各種資料も入手できる。よって、ここではIBM iの「内部の」仮想化に話を絞ることにする。

かつて日本IBMのSEがAS/400トレーニングを受ける際に使用した資料の1つに［参考資料*2］がある。時期的に紙の出版物であるが、IBM社内ではライブラリーでまだ読めるかもしれない（注2）。

そこでは、AS/400の先進性として以下の3つの概念を挙げている。

❶ ハイレベル・マシン・アーキテクチャ（TIMI）
❷ オブジェクト指向
❸ 単一レベル記憶（SLS）

これらはいずれも「抽象化」「仮想化」という観点から捉えることができる。TIMI、オブジェクト、そしてSLSは言わば三位一体となってIBM iを支えていることを見ていきたい。

ハイレベル・マシン・アーキテクチャ

IBM iの先祖たるS/38の設計意図は、言わば寿命の長いマシンを作ることだった。そのためにはコンピュータのもつ階層的な特性を活かして具体的なハードウェアと顧客のアプリケーション資産を切り離す手法が採用されたわけである。

この「ハイレベル・マシン」（高水準マシン）とは何のことかというと、TIMI（MI）のことだ。ここで「高水準」は抽象的ということ、つまりマシンとは言っても物理的なハードウェアではないよ、と言っている。よってこの「マシン」は仮想マシンと捉えればよい（図表2）。

現在多数派となっているOSは、特定のISAつまり特定のCPUハードウェアに依存する形で実装されている。低レベルソフトウェアのプログラマー（より実際的にはコンパイラ）には目標となるISAのもつ特徴（レジスター・セット、アドレス空間など）が明示的に見えている。

ここで問題は、こうした特徴はその時々のハードウェアの改良のためにしばしば変更されてきたということだ（たとえば、Intel系のCPUはレジスターが8bit→16bit→32bit→64bitと変化してきたし、その数も種類も増えてきた）。これによってソフトウェア側、ひいてはユーザー側が被った影響は非常に大きい。

TIMI（MI）は、この問題に対処するべく設計されている。これは仮想マシンなので実際のハードウェアにこだわりなく、いわば理想的な設計をすることができる。IBMからはMIの詳細は公表されていない（もし公開されていれば互換機が作れることになる！）が、MIより上位のソフトウェアからは具体的なハードウェアの特徴が隠されている、ということが重要である。ただし裏方（IBM）はそのぶん頑張らなければならない。

一方で、これはJavaのような仮想マシンとも異なっている。Javaにも高水準な仮想マシンの概念（JVM）があり、それがJavaバイトコードをインタープリトして実行する方式でハードウェアからの独立性を達成している。しかしこれは高水準命令の逐次解釈になるので性能面でペナルティがあり、そのためにJVMには長い最適化の歴史がある。Just-In-Time（JIT）コンパイラはその1つであり、多用されている高水準命令だけを動的にISAレベルにコンパイルして性能向上を図っている。

IBM iではこの問題にシンプルな対策を取った。まずユーザー・プログラムをコンパイルする時点で、コンパイラはまずMIにコンパイルし、さらにそれを続けてISAにコンパイルする。このバイナリーは高水準マシンではなく実際のハードウェア・レベルで直接実行されるので性能面のメリットが得られる。そもそもコンパイラというものは大体マルチパスの処理になっているのでこれは自然である。

一方でMIの段階の出力（これを識別情報と呼ぶ）をプログラム・オブジェクトの内部に保存しておくことで、将来的にハードウェアのISAが変更された場合でも、コンパイル後半の処理だけ、つまりIBM側だけで対処できるようにした（注3、注4）。

オブジェクト指向　

IBM iがオブジェクト・ベースのOSだということはよく知られている。これも寿命の長いマシンを作ることに関連している。オブジェクト指向の概念については今更説明する必要はないと思うので省略するが、オブジェクトの重要な特性の1つにカプセル化がある。

IBM iのユーザーは、オブジェクトとしてモデル化されたOS上の操作対象を操作するが、そこでは具体的なハードウェアの特徴は隠されている。またオブジェクトには型があり、OS側で定義された操作以外は行うことができないので、ユーザーが内部を独自に解析して利用するようなことは難しく、そのようなプログラムが後々互換性の問題を引き起こすことがない。

IBM iのオブジェクトは、実は2層構造になっている（図表3）。

1つ目はOSレベルのオブジェクトで、これは私たちユーザーに馴染みの深いものである。2つ目はMIレベルのオブジェクトで、OSオブジェクトの部品となるものだ（注5）。

MIオブジェクトは、MI命令のオペランド（操作対象）になる。MIオブジェクトはSLS上の1つまたは複数のメモリ・セグメントから構成される。これらのオブジェクトは「ユーザーが使いやすいOSを作るにはどういうオブジェクトが必要か」という観点から作られた、クラスライブラリーもしくはフレームワークと考えることができる。実際、IBM iをJavaから利用するためのJTOpenは、IBM iそのものうまく表現している印象がある。

IBM iのオブジェクトへのアクセスは、突き詰めればMIレベルのポインターを利用するようになっている。物理ファイルのようなオブジェクトがディスク上にあるとしてもそうなので、奇妙にも思えるが、オブジェクトは常にSLS上に（仮想メモリ上に）存在するために、そこへのアクセスにはポインターを使うのが自然だ。ただしこのポインターは単なる64bitサイズのアドレスではなく128bitあり、仮想アドレス以外の管理情報や将来の拡張のための予備エリアが含まれている。MIポインターはSLICのみが変更可能で、ユーザー・プログラムによる破壊的なポインター操作から保護されている（注6）。

このポインターの保護のためにPowerPCの拡張命令セットが定義されている。IBM iを実行可能なPowerPCプロセッサにはこれが実装されている必要がある。つまりIBM iのポインター保護はハードウェアとソフトウェア（SLIC）の連携で達成されている。MIポインターを操作するコードを生成するコンパイラはIBM製だけである。逆に言えば、IBM以外の誰かがIBM iの低レベルのソフトウェアを書くことは禁じられており、これによりシステムの一貫性と機密保護を確保している（注7）。

単一レベル記憶（SLS）

おそらくIBM iが他のOSと最も違う点がこのSLSであろう。高水準（仮想）マシンもオブジェクトも他のOSにもあるが、商用コンピュータでSLSを実用化しているのは、現状IBM iだけと思われる。

よって比較するものがなく、わかりにくい。そしてSLSは（MIの下に位置するので）定義上ユーザーからは見えない。RPGやCOBOLでプログラムを書いてファイルをオープンするのは他のOSも同じではないのか？ これもわかりにくい。そこで、ここでは仮想化の観点からできるだけ説明を試みる（注8）。

一般にSLSはIBM iの仮想記憶であると説明される。つまりプログラム実行中にメモリが不足すれば、OSが補助記憶装置との間でページングしてくれる。ただしSLSはそれだけにとどまらない。

・SLSはプログラムとデータを同じに扱う。

IBM iでは、プログラム（オブジェクト）もデータ（をもつオブジェクト）も、同じく仮想アドレス空間上に存在する。従って、プログラムのページングも、データを補助記憶装置から持ってくる操作も、基本的に同じものになり単純化される（図表4）。

これは一般にメモリ・マップド・ファイルと呼ばれる技法に相当する。これによりデータ（を含むページ）の利用頻度や、補助記憶装置の実際の構成に応じたI/O処理のパフォーマンス調整が、ユーザーには見えない形で行える。RPG/COBOLがファイルI/Oをしても、Db2がSQL処理をしても、裏ではこうなっている。データベース・マシンたるIBM iには望ましい特性である。

・SLSはオブジェクトの永続性を提供する。

オブジェクトは、必要なものすべてを格納できる大きさ（64bit）をもつ仮想空間に置かれる。現実には現状それほど巨大な実メモリをもつことはできないので、オブジェクトの仮想アドレスは補助記憶装置に割り当てられ、実メモリはそのキャッシュとして働く。実際のCPUが直接アクセスできるのは実メモリだけなのでこうなる（よく「実メモリとディスクが連続している」という説明がなされる。確かに仮想アドレスとしてはそうだが、実メモリが仮想アドレス空間の窓であるという捉え方が本質だと筆者は考える）。

他OSにおけるオブジェクト（たとえばJava）では、オブジェクトは同じく仮想空間に置かれるが、それはある特定のプロセスの中に閉じている。そのプロセスが終了する時にオブジェクトを永続的に保存するためには、改めてファイルとして書き出すことになる。次にそのオブジェクトを使う時には逆に読み出してプロセスの仮想記憶内に再現し直す。オブジェクトはたくさんあり相互に複雑にリンクしているかもしれない。

一方SLSではオブジェクトの存在は特定のプロセスに依存していないので、オブジェクトの利点を享受しつつもずっと単純になっている。

・SLSには仮想アドレス空間が1つだけ存在する。

他OSにおける仮想アドレス空間はプロセスごとに独立しているのが普通だ。しかしSLSではそうではない。個々のプロセスとは独立して仮想アドレス空間上に存在するオブジェクトを無理なく共有しようとすれば、むしろSLSこそが自然とも言える。これは、複数のプロセスを同時実行している場合に、仮想アドレス空間を切り替えないのでコンテキスト・スイッチの負荷が低いということを意味する。マルチユーザーのOLTP処理を行うIBM iにとって、これも望ましい特性である。

しかしすべてのプロセスがアドレス空間を共有していたら、プロセス間の分離・保護はどうなるんだ？ という疑問が湧く。SLSではセキュリティ機構としてプロセス分離というよりも、逆に共用オブジェクトを保護する仕組みを導入している。その基礎は、保護されたMIポインターである。

 

［注1］［参考資料*1］は出版時期が古いと感じられるかもしれないが、現代のコンピュータの具象的な細部はひたすら洗練を積み重ねているものの、本質的なところは驚くほど変化がない。

［注2］［参考資料*2］の英語原典は、［参考資料*4］と思われる。これは別の［参考資料*5］のリファレンスに登場する。この［参考資料*5］は、1989年のIBM System Journal のAS/400特集号の一章であり、性能面からTIMI、SLSおよびオブジェクトを解説している。IEEEのサイトで見つけることができたが、会員でない場合には閲覧に費用がかかるらしい。著者のうちコリガンは［参考資料*3］のPowerPCの機能拡張の箇所で名前が出てくる。なおこの特集号にはほかのトピックを扱った章もある。

［注3］このやり方は単純だが代償として補助記憶域の必要容量が大きくなる。なおAppleはMacのCPUを乗り換える際に、1つのプログラム・ファイルに新旧両方のISA向けのバイナリー・コードを詰め込むということをした。これはfat binaryやuniversal binaryと呼ばれる。技術進歩を前提としたこのような割り切りも時に有効である。

［注4］図表2は概念を伝えるものであり、正確にはユーザー・プログラムはデフォルトで識別情報が残るがOSのプログラムはそうではない。CPUが変わればOSはIBMが作り直すのでそれで構わない。

［注5］このMIオブジェクトの構造はmacOSのリソースフォークとデータフォークを思わせる。

［注6］サイバーセキュリティの観点から近年はメモリ安全性の概念がフォーカスされており、プログラム言語としてC/C++の代わりにRust等の採用が増えている。ハードウェア的にも、x64やarm64など他のプロセッサもメモリ保護機能を取り入れてきている。しかしソフトウェアをそれにあわせて修正しなければならないので、普及は徐々に進んでいる。また商用システムではなく研究プロジェクトでは、arm64/RISC-VベースのCHERI （Capability Hardware Enhanced RISC Instructions）［参考資料*6］がある。これはIBM iのMIポインター保護の考えとほぼ同じと思われる。

［注7］このアプローチは、たとえばオープンソースでOSを作ろうというものとは明らかに異なっている。しかしIBM iの設計意図からすればそれは問題にはならない。

［注8］入手可能なIBM以外の情報源でSLSについて触れたものとしては［参考資料*7］が最も詳しいだろう。かつこれはS/38ではなくAS/400を取り上げている。SLSの単純明快さを高く評価しつつ、同時に実用品に仕上げるのにはそれなりの難しさがあるのではないかとも述べている。それ以外にも［参考資料*8］や［参考資料*9］で若干触れられている。

【参考資料】

*1： A.S.タネンバウム著、長尾高弘訳「構造化コンピュータ構成 デジタルロジックからアセンブリ言語まで」ピアソンエデュケーション、2000

*2： AS/400テクノロジー、日本IBM システム・センター 中型システム・サポート、IBM資料番号N:SG18-9176-0, 1989

*3： F.G.ソルティス著、日本アイ・ビー・エム訳「Inside the AS/400日本語版」インフォ・クリエイツ、1998

*4： IBM Application System/400 Technology, IBM Corporation, IBM資料番号SA21-9450-0, 1988

*5： 「Application System/400 performance characteristics」IBM System Journal Vol.28, No.3, 1989

*6： ArmがMorello Evaluation Platformを発表 – Hot Chips 34
https://news.mynavi.jp/techplus/article/20220824-2433140/ （2024年1月時点）

*7： G.グレイ・A.ロイター著「トランザクション処理 技法と概念（上下巻）」日経BP、2001

*8： 坂村健著「コンピュータ・アーキテクチャ 電脳建築学」共立出版、1984

*9： Computer Today No.28「特集OS新時代」サイエンス社、1988