IBM i のウンチクを語ろう
～ その3：アプリケーションの互換性を維持する仕組み
皆さん、こんにちは。前回の続きとして、IBM i においては何故アプリケーション資産の継承性が実現されるのか、その内部のカラクリを見てみたいと思います。
おおよそプログラミングとは、どのプラットフォームにおいてであっても、どの言語であったとしても、人がエディターなる編集ソフトを利用してソースコードというテキスト文を記述し、最終的にはプロセッサが理解できる実行コードに翻訳する、という一連の作業を言います。プログラム実行の方法には、ソースコード全体を読み込んで一括して実行コードを生成し、その後それに基づいて実行するコンパイラ方式と、ソースコードを一文ずつ読み込んで実行コードを生成しながらそれを実行するインタープリタ方式の二つがあります。インタープリタ言語には、ソースコードを記述したら直ぐに実行できるという手軽さがある反面、マシンの立場からみるとソースコードからの翻訳と実行という二つの作業を同時に行わなければならないので、パフォーマンス面で不利になる傾向があります。ただし最近ではハードウェア能力が大分高まってきているので、利便性を重視してPythonやPHPといったインタープリタ言語の人気が高まりつつあるようです。
さてIBM i 上のRPGやCOBOLはコンパイラ方式を採用しています。すなわちプロセッサが直接理解できる実行コードは、あらかじめ一括生成されます。そしてこのIBM i の実行コードは不変ではなく、過去に何回かの大きな転換点がありました。最初が1988年のシステム38からAS/400に切り替わる時、次に1995年の48ビットCISCプロセッサから64ビットRISCプロセッサに置き換わる時、最近のものは2008年バージョン6.1登場時に内部実行コード形式が変更された時、の三回です。これら転換点においては、実行コードの互換性は失われました。しかしながらIBM i のコンパイル済みアプリケーションは、これら転換点を乗り越えて、コンパイルのやり直しといったプロセスを経ずに利用できてきた、という実績があるわけです。実行コードには変更の歴史がある一方で、コンパイルのやり直し不要でアプリケーションは永続的であるという事とは、どうも辻褄が合いませんね。IBM i におけるコンパイラの成果物は実行コードだけではない、というのがポイントです。
IBM i のコンパイルは、内部では二段階のプロセスに分かれています。最初にソースコードを取り出して中間コードを生成する、オペレーティング・システムより上位層にあるプロセスが動きます。次にその中間コードから実行コードを生成するために、下位層にあるトランスレータがプロセスとして起動されます。これはSLICと呼ばれるマイクロコード内で実行されます。
そして実行コードは先に生成済みの中間コードと共に統合（カプセル化）され、最終成果物となります。これがコンパイル済みのロードモジュールになります。すなわち通常のシステムのコンパイル済みモジュールよりも、構造的には中間コード相当分のサイズが大きくなります。そしてプログラム実行にあたって、コンパイル済みモジュールの中からこの実行コードが取り出されるわけです。
ではこのコンパイル済みモジュールを、ハードウェア互換性のない将来の後継マシンに導入し、実行しようとしたら何が起こるでしょうか。もちろん古いマシン上で生成された実行コードは動作することはできません。通常のマシンならば、この段階でエラー・メッセージを吐き出してプロセスを終了します。IBM i においても同様に内部で一旦エラーを発生させますが、続きのプロセスが自動的に起動されます。
SLICトランスレータが中間コードを取り出して、新しいハードウェア用に再度実行コードを生成し、コンパイル済みモジュールの中にあった古い実行コードを置き換えます。その後あらためて新しい実行コードを実行します。この一連のプロセスはユーザーには意識されないところで行われます。
古いモジュールを新しいマシンで実行しようとすると、内部では最初にトランスレータが仕事をするのでパフォーマンスは明らかに不利になります。しかしこの「余分な」仕事は一度きりのものなので、次回以降は常に新しい実行コードが参照され、パフォーマンスの懸念は何もしなくても解消されます。一度きりではあっても本番業務への影響を避けたいのであれば、新しい実行コードをあらかじめまとめて生成しておくこともできます。
すなわちIBM i アプリケーション資産が保護される事とは、より具体的には中間コードの上位互換性が実現されている事に他なりません。ハードウェア・テクノロジーの変化や進化において、実行コードの互換性が保たれる事を期待するのは無理がありますし、将来どうなるのかを予測する事はできません。一方で中間コードは常に互換性を保つように設計されています。両者のギャップを埋めているのは、マイクロコードに匹敵するSLICと呼ばれる階層であり、トランスレータです。IBM i にとって最も重要なテクノロジーはSLICであると言われる所以です。
中間コードの考え方はJavaのバイトコードに近いものです。Javaにおいてはバイトコード生成後にインタープリタ方式でプログラムが実行されるのに対して、IBM i ではパフォーマンス上不利になるのを避けるために、コンパイラ方式を採用しています。かつてのAS/400ないしそれ以前のシステム38の時代では、ハードウェアの能力がインタープリタ方式に耐えられるものではないと判断された事がその最大の理由です。そして互換性が保たれ、オーバーヘッドのない、すなわちパフォーマンスに優れたアプリケーションを利用できる事が、現在においてもなお多くのお客様に支持されているのです。
次回はIBM i のセキュリティについて説明します。ではまた。
