JPH09269898A - 実行可能ファイルの実行効率を改善するための方法及びシステム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 オブジェクト指向言語において、実行可能な
プログラムをリンクする前に未使用のプログラム構成要
素をコンパイルおよびリンク時に除去する最適化。 【解決手段】 コンパイラは、関連仮想関数のグループ
のメンバとしてそれを識別するコードによって各定義済
み仮想関数にタグを付ける。また、コンパイラは、どの
関連仮想関数のグループ（複数も可）が仮想関数呼出し
による呼出しの候補であるかを識別するために各仮想関
数呼出しにもタグを付ける。リンカは、この２つのコー
ドを結合し、どの定義済み仮想関数が仮想関数呼出しに
よる呼出しの候補ではないかを識別する。次にリンカ
は、このような非候補仮想関数へのすべての参照が仮想
関数テーブルからのものである場合、その非候補仮想関
数をリンクから省略する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、実行可能なプログ
ラムをリンクする前に未使用のプログラム構成要素を除
去するためにプログラムのコンパイルおよびリンク時に
実行される最適化方法に関する。

【０００２】

【従来の技術】オブジェクト指向プログラムは、ディジ
タル・コンピュータの実行を制御するために使用するプ
ログラムであり、そのプログラムは、「クラス」と呼ば
れる特定の形式のユーザ定義タイプをサポートする１組
の言語ツール、抽象概念、および構成を使用して作成さ
れる。このようなタイプのそれぞれは、宣言済みデータ
の集合をそのデータに関する１組の操作に関連付ける。
実行中のプログラム内のこのようなタイプの変数、すな
わち、インスタンスは、オブジェクトと呼ばれる。

【０００３】継承によって複数のクラスを互いに関連さ
せることができる。親クラス、すなわち、「基本」クラ
スの特性、挙動、データ、操作は、一部の子クラス、す
なわち、「派生」クラスによる修正なしに継承すること
ができ、あるいは挙動、特性、操作は、プログラマの制
御下で選択的に改善することができる。派生クラスを定
義する場合、作成すべき基本クラスによく似た既存の基
本クラスを基礎とすることによって開始することができ
る。派生クラスは、派生クラス定義に詳述されている改
訂によって修正されたものを除き、基本クラスのインプ
リメンテーションと挙動を継承する。複数のクラスが１
つの共通の親の挙動を継承することができ、派生クラス
が複数の基本クラスから継承することもできる。例とし
て、正方形は矩形から、円は楕円から、スタックと待ち
行列は集合から、それぞれ継承することができる。

【０００４】メンバ関数とは、いずれかのユーザ定義の
タイプの挙動として定義された関数または演算であり、
そのタイプが他のタイプの階層に関与しているものであ
る。仮想関数とは、名前で呼び出されたときにその仮想
関数の特定のアイデンティティが、それが関連するオブ
ジェクトのタイプの関数として実行時に決定されるとい
う追加の特性を備えたメンバ関数である。これは、名前
で呼び出されたときにその特定のアイデンティティが、
オブジェクトにアクセスするのに使用する変数の宣言済
みタイプの関数としてコンパイル時に決定されるよう
な、仮想関数ではないメンバ関数とは対照的なものであ
る。

【０００５】継承階層の複数のタイプのそれぞれは、名
前がこのようなタイプのすべてに共通する場合に専用の
メンバ関数の定義を含むことができる。その関数がプロ
グラマによって決定され、プログラマの制御下にある仮
想関数である場合、実行時に呼び出される関数は、その
関数が操作する対象となるオブジェクトを指定する宣言
済み名前のタイプではなく、関数の１次オペランドであ
るオブジェクトのタイプから決定される。仮想関数への
呼出しは、仮想関数テーブルというテーブルによる間接
呼出しとして実現することができる。仮想関数テーブル
は、そのインプリメンテーションがこのようなテーブル
を必要とするようなユーザ定義のタイプまたはクラスご
とにコンパイラによって作成される。

【０００６】Ｃ＋＋言語では、コンパイラは、各クラス
ごとにオブジェクト・データ構造を定義する。クラスが
仮想関数を取り入れるかまたは指定変更関数を有する場
合、コンパイラはそのクラス用の仮想関数テーブルを割
り振る。Ｃ＋＋言語における指定変更関数は、そのクラ
スの基本クラスの仮想キーワードで宣言されたメンバ関
数と同じ名前、同じ数、同じタイプのパラメータを有す
るクラスのメンバ関数である。クラス・オブジェクト・
データ構造は、データ・メンバのレイアウトと仮想関数
テーブル・ポインタとを含む。仮想関数テーブル・ポイ
ンタは、そのクラスに関連する仮想関数テーブルを指し
示すように、実行時中に初期設定される。

【０００７】あるクラス用の仮想関数テーブルは、その
クラスがその関数の１次オペランドであるオブジェクト
のタイプであるときに実行時に呼び出される仮想関数メ
ンバのアドレスを含む。コンパイラとリンカは、そのク
ラスに適したアドレスによる仮想関数テーブルの初期設
定を共同で担当する。仮想関数テーブルは、仮想関数を
間接的に呼び出すために実行時に使用する。仮想関数メ
ンバを備えた各基本クラスには、関連の仮想関数テーブ
ルがある。派生クラスは複数の仮想関数テーブルを有す
ることができる。というのは、各基本クラスにこのテー
ブルを１つずつ関連付けることができ、したがって、そ
のオブジェクト・データ構造は複数の仮想関数テーブル
・ポインタを含むことができるからである。オブジェク
ト用のメモリが割り振られた後、仮想関数テーブル・ポ
インタは、関連の仮想関数テーブルのアドレスで初期設
定される。したがって、同一クラス・タイプのすべての
オブジェクトは同一仮想関数テーブルを指し示す。仮想
関数の呼出しを実現するため、コンパイラは、仮想関数
テーブルにより仮想関数メンバにアクセスするためのコ
ードを生成する。

【０００８】Ｃ＋＋オブジェクト指向プログラミング言
語は、とりわけ、強力かつ評判のよい仮想関数機構を提
供する。言語に依存する特定の規則により、ある仮想関
数が別の関数を指定変更する。所与の状況下では、この
仮想関数機構を使用すると、比較的単純なプログラムで
なければならない場合に、非常に大規模な実行可能ファ
イルが生成されることがある。この結果、プログラムを
格納するためのディスク空間とそれを実行するためのメ
モリが不必要に使われることになる。

【０００９】このような状況は、一般に、仮想関数の実
行時ディスパッチの際に、オブジェクト内に組み込まれ
た仮想関数ポインタによって指し示される仮想関数テー
ブルを使用する方法が確立しているために発生する。一
般に、このようなテーブルは、そのオブジェクトを含む
アプリケーションでディスパッチされると思われるすべ
ての仮想関数への参照を含む。一部のアプリケーション
では、この結果、まったく呼び出されない仮想関数用の
定義で不必要なリンクが行われる恐れがあり、本発明が
解消を目指しているのはこの冗長性である。

【００１０】１９９３年９月２１日にテキサス・インス
ツルメンツ社に対して発行された米国特許第５２４７６
７８号には、拡張関数同士をリンクするマルチプロセッ
サ・システムが記載されている。同特許には、アプリケ
ーション・プログラムが必要としない活動メモリ内にロ
ードされた関数があるかどうかを判定し、ある場合には
それを活動メモリから廃棄する動的リンカが記載されて
いる。しかし、同特許では、本発明のように非活動関数
がプログラム自体から除去されるようなプロセスは教示
していない。

【００１１】１９９４年３月２２日にマイクロソフト社
に対して発行された米国特許第５２９７２８４号には、
オブジェクト指向プログラミング言語用にコンパイラで
仮想関数および仮想基本クラスを簡単に実現するための
方法が記載されている。同特許も、本発明が対処するよ
うな、コンパイルかつリンク済みプログラム内に呼出し
不能仮想関数への参照を維持することによって発生する
問題を考慮していない。

【００１２】１９９４年７月５日にマイクロソフト社に
対して発行された米国特許第５３２７５６２号には、オ
ブジェクト指向プログラミング言語用にコンパイラで仮
想関数を実現するための方法が記載されている。同特許
には、コンパイルかつリンク済みプログラム内の呼出し
不能仮想関数への参照を除去するための機構が記載され
ていない。

【００１３】

【発明が解決しようとする課題】本発明の主要目的は、
コンパイルかつリンク済みプログラムから呼出し不能仮
想関数を除去することにある。

【００１４】本発明の副次目的は、このような仮想関数
が呼出し不能であると判定できるときに、コンパイルか
つリンク済みプログラム内に仮想関数への呼出しを維持
することを回避することである。

【００１５】

【課題を解決するための手段】この目的およびその他の
目的を達成するため、本発明は、実行可能コードから未
使用の仮想関数への参照を識別し、除去することによ
り、Ｃ＋＋言語で仮想関数を使用することによるマイナ
スの影響を低減するための手段を提供する。これは、ア
プリケーション内で呼び出すことができない関数をリン
カが識別でき、そのような仮想関数の定義を無視または
除外できるような方法でコンパイル中に仮想関数の定義
と使い方にタグ付けすることによって達成される。

【００１６】したがって、オブジェクト指向ソース・プ
ログラムをオブジェクト・モジュールにコンパイルする
ためのコンパイラ手段と、オブジェクト・モジュールを
実行可能ファイルにリンクするためのリンカ手段であっ
て、実行時に仮想関数を呼び出すための仮想関数テーブ
ルを初期設定するための手段を含む手段が設けられたリ
ンカ手段とを有するコンピューティング環境において、
実行可能ファイルの実行効率を改善するための方法を提
供する。この方法は、コンパイル中に各仮想関数テーブ
ルを識別する制御データを生成するステップであって、
潜在的に呼出し可能なものとして仮想関数を識別するた
めに制御データがリンク中にアクセス可能なステップ
と、潜在的に呼出し可能なものとして識別された仮想関
数のみをリンクするステップとを含む。

【００１７】制御データを生成するステップは、ソース
・プログラムのコンパイル中に検出された各仮想関数の
ための定義済みイントロデューサのリストをコンパイル
することと、各被呼イントロデューサが実際に呼び出さ
れる関数を含む仮想関数のグループを識別する被呼イン
トロデューサのリストをコンパイルすることと、これら
のリストを制御データ・レコードとしてオブジェクト・
モジュールに組み込むことから構成されていることが好
ましい。また、潜在的に呼出し可能なものとして識別さ
れた仮想関数のみをリンクするステップは、仮想関数テ
ーブルによってのみ参照される仮想関数のリストを蓄積
することと、制御データ・レコードとして組み込まれる
定義済みイントロデューサと被呼イントロデューサのリ
ストとリンク中にコンパイルされた仮想関数のリストか
ら判定されるように潜在的に使用される仮想関数へのポ
インタをリンクすることから構成されていることが好ま
しい。

【００１８】オブジェクト指向言語で作成されたソース
・コードを実行可能ファイルに変換するための改良され
たシステムも提供する。この改良システムは、それぞれ
が仮想関数のグループを識別する定義済みイントロデュ
ーサのリストを生成する手段と、仮想関数テーブルによ
ってのみ参照される仮想関数のリストを維持する手段
と、それぞれが潜在的に呼び出される仮想関数のグルー
プを識別する被呼イントロデューサのリストを生成する
手段と、仮想関数テーブルによってのみ参照され、定義
済みイントロデューサ、被呼イントロデューサ、仮想関
数のリストでは識別されない仮想関数を実行するために
実行可能ファイルを生成する手段とから構成されてい
る。

【００１９】また、本発明は、コンパイル可能なオブジ
ェクト指向プログラミング言語で作成されたソース・プ
ログラムから派生したマシン実行可能コードの実行効率
を改善するための機構にも関する。この機構は、コンパ
イル中に仮想関数の定義と使い方にタグ付けを行えるよ
うになっているコンパイラと、タグ付き仮想関数を識別
し、呼び出すことができるタグ付き定義をリンクし、呼
び出すことができない前記タグ付き仮想関数の定義を無
効にすることができるようになっているリンク手段とを
有する。

【００２０】最後に、本発明は、コンピュータに上記の
方法を実行させるようにプログラミングしたコンピュー
タが読取り可能なプログラム・コード手段の新規かつ有
用な組合せを有する、コンピュータが使用可能な媒体を
含むコンピュータ・プログラム製品を提供する。

【００２１】

【発明の実施の形態】図１は、Ｃ＋＋言語で作成された
プログラムをコンパイルしリンクして実行可能ファイル
を作成する方法を示す概略図である。ソース・コード
は、このコードを複数のオブジェクト・モジュールにコ
ンパイルするＣ＋＋コンパイラ１０に供給される。各オ
ブジェクト・モジュールは、記号参照および定義の記
述、コードまたはデータをマシン・アドレスに割り振る
ときに行わなければならない再配置アクションの記述、
デバッグ情報を含むがそれらに限定されない制御情報と
ともに、供給されたソース・コードに対応するようにコ
ンパイラ１０によって生成されたマシン・コードとデー
タの表現を含む。コンパイル済みの各オブジェクト・モ
ジュールは、他のオブジェクト・モジュールとの組合せ
に適している。

【００２２】オブジェクト・モジュールの組合せは、リ
ンカ、リンク・ローダ、または同様のユーティリティ１
２によって行われる。このユーティリティは、オブジェ
クト・モジュールを組み合わせて実行可能プログラム１
６を形成し、それを行う際に１つのオブジェクト・モジ
ュールから別のオブジェクト・モジュールで検出された
記号への参照を解決する。記号は、サブルーチンおよび
データ定義を表す。

【００２３】関与するオブジェクト・モジュールは、オ
ブジェクト・モジュール＃１および＃２について示すよ
うにリンカに個別に指定するか、またはオブジェクト・
モジュール＃３および＃４に関して示すようにライブラ
リアンまたは同様のアーカイブ機構１４によってオブジ
ェクト・モジュール・ライブラリ（全体を１６で示す）
にグループ化することができる。このライブラリは、入
力としてリンカに供給することができる。この後者の場
合、リンカは、実行可能プログラムを完成するために必
要なオブジェクト・モジュールをライブラリから選択的
に抽出し、それをプログラムに取り入れる。この選択の
基準は、選択したオブジェクト・モジュールはすでにプ
ログラムに取り入れられた他のオブジェクト・モジュー
ルが参照する１つまたは複数の記号の定義を提供しなけ
ればならないということである。これについては、図１
０に関連して後で詳述する。

【００２４】リンカの役割は、すべてのモジュールをひ
とまとめに接続し、結合力があり効率のよい実行可能な
マシン読取り可能ファイルにすることである。先行技術
では、仮想関数テーブル内のポインタによってコンパイ
ラが仮想関数を参照した場合、リンカは、プログラムの
実行中に参照した関数が必要になるかどうかを判定する
ための手段を一切持っていなかった。したがって、仮想
関数を使用しない場合でも、その仮想関数をリンク済み
プログラム内に残しておく必要があった。

【００２５】本発明では、コンパイラは、その仮想関数
の使い方に関する情報をモジュール内に含んでいる。こ
の情報により、リンカは、その関数を呼び出す可能性の
ある呼出しがプログラム内に存在するかどうかを判定す
ることができる。その関数を呼び出す呼出しが存在し得
ない場合、リンカは、結果として得られる実行可能プロ
グラムからその仮想関数を除外することができる。

【００２６】どのように仮想関数を参照し、それを使用
しないかを示すために、以下のＣ＋＋言語用の単純な宣
言が役に立つはずである。

【００２７】

【００２８】この特定の例は十分に単純なので、コンパ
イラは、クラスＡへのaptrというポインタが指し示すオ
ブジェクトの実際のタイプを判定することができ、その
ため、どの関数f()を呼び出すべきかを判定することが
できるはずである。この場合、コンパイラは、A::f()、
B_A::f()、C_A::f()への直接呼出しを生成できるはずで
ある。Ｃ＋＋言語によりこの最適化が可能になる。しか
し、これは一般的なケースでは達成することができな
い。というのは、ポインタの値は、コンパイル時に予測
できない任意の複雑な計算によって決まる可能性がある
からである。このため、Ｃ＋＋言語のほとんどのコンパ
イラでは実行時インプリメンテーションを使用する。

【００２９】仮想関数の典型的な実行時インプリメンテ
ーションでは、そのクラスが仮想関数を含むかまたは継
承する各オブジェクトは、１つまたは複数の仮想関数テ
ーブルすなわち「ＶＦＴ」へのポインタを備えている。
ＶＦＴポインタは、オブジェクトの先頭に対して相対的
な既知の位置にあり、通常はユーザ定義のデータの前に
ある。該当のクラスのどのインスタンスも同じＶＦＴを
指し示す。オブジェクトのＶＦＴは、そのオブジェクト
に関して呼び出す必要がある関数へのポインタを含んで
いる。

【００３０】上記のクラスＡが導入する関数f()のよう
に、仮想関数がクラスによって導入されると、コンパイ
ラは、そのクラス用のＶＦＴ内のスロットをそれに割り
振る。ＶＦＴは、基本クラスから得た情報に基づいて、
同じ順序の仮想関数をいつでも備えている。Ａから派生
し、その関数を指定変更しないクラスも、それらのテー
ブル内の同じスロットにA::f()へのポインタを備えるこ
とになる。これについては、図９に概略を示す。さら
に、クラスＡによって導入された関数を指定変更するク
ラス（B_AやC_Aなど）は、そのスロット内の正しい指定
変更関数へのポインタを含むことになる。

【００３１】図９は、クラス・タイプＡ、Ｂ＿Ａ、Ｃ＿
Ａのそれぞれのオブジェクト「ａ」、「ｂ＿ａ」、「ｃ
＿ａ」とそのクラス用にコンパイラが構築したＶＦＴと
の関係を示している。各オブジェクト・データ構造は、
それに対応するＶＦＴへのポインタを含んでいる。上記
のように、各ＶＦＴには２つのスロットがあり、第１の
スロットはそのクラスのオブジェクトを呼び出すための
適切なf()関数へのポインタを含み、第２のスロットは
適切なg()関数へのポインタを含んでいる。仮想または
複数の基本クラスを備えたより複雑なクラスは、各種Ｖ
ＦＴへの複数のポインタを含むことができる。その場
合、様々なＶＦＴの各種スロットに所与の指定変更関数
が現れる可能性がある。

【００３２】図９に示す例では、クラスＡ用のＶＦＴ
は、その第１のスロットに関数A::f()へのポインタを含
み、その第２のスロットに関数A::g()へのポインタを含
んでいる。クラスＢ＿Ａは関数f()を指定変更するもの
である。したがって、関数B_A::f()によって関数A::f()
が指定変更されるので、クラスＢ＿Ａ用のＶＦＴは、そ
の第１のスロットに関数B_A::f()へのポインタを含んで
いる。しかし、クラスＢ＿Ａは関数g()を指定変更しな
いので、クラスＢ＿ＡのＶＦＴの第２のスロットも関数
A::g()へのポインタを含んでいる。これに対して、クラ
スＣ＿Ａは関数f()とg()の両方を指定変更するので、そ
のＶＦＴは、その第１のスロットに関数C_A::f()へのポ
インタを含み、その第２のスロットに関数C_A::g()への
ポインタを含んでいる。

【００３３】aptr->f()のような呼出しは、本質的に以
下のように実行することによって実現される。 (* aptr->_VFT[correctSlotNumber]) ();

【００３４】このため、クラスＡのインスタンスである
オブジェクトをaptrが現在指し示している場合、関数
A::f()または関数A::g()のいずれかが呼び出される。し
かし、生成されたコードが同じである場合、派生クラス
Ｃ＿Ａのインスタンスであるオブジェクトをaptrが現在
指し示していると、呼び出される関数はC_A::f()とC_
A::g()のうちの１つになる。

【００３５】aptrを使用する呼出しは、派生クラスＢ＿
ＡおよびＣ＿Ａの定義またはその存在すら気付いていな
いコンパイルに現れる可能性がある。さらに、すべての
派生クラスが既知である単一コンパイル・ユニットが存
在する必要はないので、コンパイラは、ポインタaptrを
使用する呼出しによって呼び出される可能性のある候補
関数のすべてを識別すらできない場合もある。

【００３６】クラスの定義をコンパイルするときも同様
のレベルの不確実性が存在する。コンパイラがクラスＢ
＿Ａの定義を処理する場合、そのクラスのオブジェクト
の潜在的な使い方のすべてまたは一部をすでに検出して
いる必要はない。これは、そのクラスの使い方を完全に
把握せずにクラスＢ＿Ａ用のＶＦＴを構築しなければな
らないことを意味する。したがって、完成したプログラ
ムが実際にいずれかを呼び出すかどうかにかかわらず、
そのクラスのすべての仮想メンバ関数への参照を含むＶ
ＦＴが構築される。図９に示す例では、プログラムが
g()への呼出しを含まなくても、各ＶＦＴにg()関数のポ
インタが存在する。プログラムをリンクする場合、これ
らのポインタを初期設定するために呼出し不能のA::g()
関数とC_A::g()関数の定義が使用可能になっていなけれ
ばならない。アプリケーションを静的にリンクする場
合、そのアプリケーションは、使用するクラス用に定義
したすべての仮想関数の本体を含むことになる。このよ
うな関数が他のクラスを使用する場合、リンカは、その
クラスのすべての仮想関数ならびに同様に参照する任意
の非仮想関数を過渡的に閉じる必要がある。

【００３７】このようにして、クラス・ライブラリ内の
ほとんどすべてのモジュールをこれらのＶＦＴ参照によ
って相互接続することが可能なので、ライブラリの一部
分を使用すると、結果的にすべてのモジュールのすべて
の部分でリンクが行われることになる。

【００３８】図１０は、上記の例の関数とＶＦＴを静的
ライブラリ内のモジュールに分散する方法を示してい
る。作成されたＶＦＴは関数A::g()およびC_A::g()への
参照を含むので、このアプリケーションの実行中にいず
れの関数も呼び出すことができない場合でも、リンカは
それが作成する実行可能ファイル内にこれらの関数を定
義するモジュールを含むことになる。これについては、
図１１に概略を示す。

【００３９】この例と図１０に示すように、ＶＦＴはモ
ジュール１、３、４で検出され、各モジュールは単一の
関数を含んでいる。任意の参照がモジュール１または３
のいずれかを必要とする場合はリンカもモジュール２を
ロードすることが必要になり、モジュール４への参照で
はモジュール５が必要になるはずである。というのは、
本発明以前は、リンカはどの関数が実際に呼び出される
かを判定できなかったからである。本発明では、コンパ
イラは、参照された関数用の定義済みイントロデューサ
と被呼イントロデューサを識別し、それにより、どの関
数ならびにそれによりどのモジュールが不要になり、そ
の結果、実行可能プログラムでリンクする必要があるか
を判定する機会をリンカに提供する。この概念について
は、以下に詳述する。

【００４０】本発明は、以下の３つのステップ・プロセ
スを実行することにより、リンカ出力から未使用の仮想
関数を除去する。１．ＶＦＴから参照されるすべての仮
想関数を識別する。２．参照された関数のうちのどれが
潜在的に呼出し可能であるかを判定する。３．ステップ
２で判定された関数に含まれない関数へのすべてのＶＦ
Ｔ参照を無効にする。

【００４１】図１１の先行技術の例とは対照的に、図１
２は、アプリケーションから呼び出すことができない仮
想関数を検出し、リンク操作の出力からそれを含むモジ
ュールを除去することにより、本発明のプロセスが実行
可能ファイルのサイズを低減する方法を示している。上
記のサンプル宣言を使用して、図１２のリンクが切断さ
れる。というのは、リンカは、プログラム内でいずれの
g()関数への呼出しも行われないことを検出することが
できるからである。

【００４２】仮想関数を呼び出す方法は、本質的に３通
りある。第１に、呼出しが以下のようになっているため
に、ＶＦＴにより仮想関数を呼び出すことができる。 aptr->f(); aref.f(); f(); ただし、「aptr」はクラス・オブジェクトへのポインタ
であり、「aref」はクラスのメンバ関数内で発生するク
ラス・オブジェクトへの参照である。これは、「this->
f();」と同等である。

【００４３】第２に、ＶＦＴ機構を完全に迂回すること
により、仮想関数を直接呼び出すことができる。オブジ
ェクトの実際のクラスをコンパイル時に判定できるか、
またはユーザがどの関数を呼び出すかを明示的に示すこ
とができる場合に、発生しうるものである。たとえば、
以下の通りである。 aptr->A::f();

【００４４】第３に、メンバへのポインタにより、仮想
関数を呼び出すことができる。このタイプのポインタ
は、A::fという形式の表現により生成されるＣ＋＋固有
のものである。関数が仮想関数である場合、メンバへの
ポインタは、ＶＦＴ内でそのスロットを検出する方法に
関する情報を含んでいる。したがって、このようなポイ
ンタの１つの作成は、ＶＦＴによる呼出しと同様に扱う
ことができる。

【００４５】ＶＦＴまたはポインタにより呼び出される
潜在的に呼出し可能な関数を判定するため、そのポイン
タまたは参照の宣言済みタイプは「明白なクラス」と定
義され、関連の仮想関数がまったくない場合に呼び出さ
れる関数は「明白な呼び出され側」と定義される。「明
白な呼び出され側」は、「明白なクラス」のメンバであ
るか、またはその基本クラスの１つのメンバである。呼
出しが正しい場合、明白な呼び出され側が明確でなけれ
ばならない。

【００４６】潜在的に呼出し可能な仮想関数は、リンク
されたオブジェクト・ファイル内のすべての明白な呼び
出され側のすべてのイントロデューサと、これらのイン
トロデューサのすべてのオーバーライダである。図１０
では、f()のイントロデューサは関数A::f()であり、オ
ーバーライダは関数B_A::f()と関数C_A::f()である。

【００４７】どの関数が潜在的に呼出し可能であるかに
関する実際の判定は、本発明のメイン・プロセスの第２
のステップであり、リンカによって行われる。リンカ
は、その入力としてオブジェクト・ファイルに組み込ま
れた制御データを使用する。この制御データは、Ｃ＋＋
コンパイラあるいは相俟ってＣ＋＋コンパイラを構成す
る一連のまたは１つの集合のプログラムによって供給さ
れる。コンパイラは、それが生成するオブジェクト・フ
ァイルに余分な制御データ・レコードを組み込む。その
結果、本発明は、コンパイラを使用してオブジェクト・
モジュールに制御データ・レコードを組み込むことと、
リンカを使用するリンク・プロセス中にこれらの制御レ
コードから情報を収集することと、情報を収集するステ
ップと同時にリンカを使用する後続のリンク・プロセス
の特定のアスペクトを制御するためにこの情報を使用す
ることを含む。このため、コンパイラとリンカは、先行
技術で従来行われていたものに加え、何らかの活動を行
うことが必要になる。

【００４８】図２および図３は、主要な２つの余分な制
御データを生成するために従来設計のＣ＋＋コンパイラ
が実行すると思われる追加の活動を示す図である。当然
のことながら、コンパイラは、完全なオブジェクト・モ
ジュールを開発するときに他の無数の活動を実行するも
のと思われる。このような活動の一部は本発明に関係す
る付随活動であるが、多くはＣ＋＋プログラムの通常の
コンパイルに使われるはずである。

【００４９】従来設計のＣ＋＋コンパイラは、関数の属
性が格納される記号テーブルを取り入れることになる。
格納される属性としては、関数を仮想関数として識別す
る「仮想関数」属性などがある。また、記号テーブルに
より、特定のクラスの基本クラスでのナビゲーションが
可能になり、それにより、特定の仮想関数を「イントロ
デューサ」または「オーバーライダ」として識別するこ
とができる。「オーバーライダ」とは、関連クラスで事
前に宣言された同様の関数を呼び出すためにソース・コ
ード内に現れる関数呼出しの結果として実行時に実行可
能な仮想関数である。指定変更が行われる時期に関する
具体的な規則は言語に依存する。他の関数を指定変更し
ない仮想関数は「イントロデューサ」である。したがっ
て、すべての仮想関数は、イントロデューサであるか、
または少なくとも１つのイントロデューサのオーバーラ
イダになる。前述のように、仮想関数A::f()とA::g()は
イントロデューサであり、関数B_A::f()、C_A::f()、C_
A::g()はオーバーライダである。

【００５０】Ｃ＋＋コンパイラが実行するもう１つの活
動は、仮想関数テーブルの作成と定義である。本発明を
実現するため、この活動は、図２に示すように仮想関数
テーブルを定義するときに実行すべき定義済みイントロ
デューサ・レコードを生成するための追加のアクション
によって増強される。この追加のアクションの目的は、
コンパイルによって生成されたオブジェクト・ファイル
に定義済みイントロデューサ制御データ・レコードを組
み込むことである。このような制御データ・レコード
は、仮想関数テーブルが指し示す各仮想関数ごとに、こ
の関数のイントロデューサ（複数も可）を識別する。本
明細書で説明し例示する好ましい実施例では、コンパイ
ラによって作成されたＶＦＴに基づく制御データの構築
を示しているが、このコンパイル中にＶＦＴが作成され
る限り、ＶＦＴの構築前に制御データ・レコードを構築
することができる。同様に、ＶＦＴの作成時ならびにそ
の後で制御データ・レコードを構築することもできる。
このような変形を可能にするための変更は、当業者には
本発明のこの開示に基づいて明らかであるはずである。

【００５１】ＶＦＴの内容はコンパイル中に既知のもの
になるので、図２に示す追加のコンパイル・ステップを
実行することができる。図２に示すように、コンパイラ
は、仮想関数テーブルが指し示す各関数を検査して、検
査中の関数が「イントロデューサ」であるか「オーバー
ライダ」であるかを判定する。本発明の好ましい実施例
によれば、この検査は、コンパイラがＶＦＴそのものま
たはコンパイラがＶＦＴを作成したときにその元になっ
たリストを検討することによって、行うことができる。

【００５２】関数がコンパイラによって「オーバーライ
ダ」として識別された場合、その「イントロデューサ」
は、検査中の関数と同じ名前、数、タイプのパラメータ
を有する現行クラスの基本クラスで「仮想」キーワード
によって宣言された関数であるが、それ自体が「オーバ
ーライダ」ではない。検査中の関数がそれ自体「イント
ロデューサ」である場合、それはそれ専用の唯一の「イ
ントロデューサ」である。

【００５３】コンパイラは、仮想関数テーブルを検査し
ている間に、仮想関数テーブルが指し示す各関数も検査
し、その関数がイントロデューサであるかまたはオーバ
ーライダであるかを判定する。これは、図２に示す論理
プロセスによって行われる。仮想関数テーブルが指し示
す第１の関数が検査される（ブロック２０、２２）。そ
れがすでにイントロデューサとして識別されている場
合、コンパイラは、仮想関数テーブルが指し示す次の関
数を検査する（ブロック３２、３４）。その関数がイン
トロデューサとして識別されていない場合、それはオー
バーライダでなければならないので、そのためのイント
ロデューサの空のリストが初期設定される（ブロック２
４）。

【００５４】現在検査中の関数のすべての「イントロデ
ューサ」を検出するために、仮想関数テーブルに関連す
るクラスの基本クラスがすべてナビゲートされる（ブロ
ック２６）。それ以上のイントロデューサがなくなるま
で、各「イントロデューサ」が見つかるたびにそれがリ
ストに追加される（ブロック２８）。現在検査中の関数
用のすべての「イントロデューサ」が識別されリストさ
れると、検査中の関数とそのリスト済みイントロデュー
サのそれぞれを識別する定義済みイントロデューサ・レ
コードがオブジェクト・モジュールに送られる（ブロッ
ク３０）。このレコードは、本発明を実行するために必
要な制御データの本質的部分の１つを含んでいる。オブ
ジェクト・モジュール内の制御データ・レコードの位置
は、システム固有の要件またはリンカの制約事項によっ
て決まる。たとえば、２パス・リンカでは、制御データ
・レコードがリンカ操作の第１のパス中に検査するオブ
ジェクト・モジュールの一部分に入っていなければなら
ない。

【００５５】定義済みイントロデューサの制御データ・
レコードは、「指定変更」とその「イントロデューサ」
との関係を指定するために必要なので、「イントロデュ
ーサ」である関数用には生成されない。関数が指定変更
であるためにイントロデューサではない場合、図２に示
すように、「定義済みイントロデューサ」の空のリスト
が初期設定または作成される。

【００５６】ただし、ほとんど場合、各指定変更関数用
の単一イントロデューサが存在するが、時には、指定変
更関数が複数の基本クラスから派生する場合もある。こ
の可能性があるので、各指定変更関数用のすべての基本
クラスでイントロデューサを検出することが必要であ
る。

【００５７】各関数ごとにその関数とそのイントロデュ
ーサのリストを指定するレコードがオブジェクト・モジ
ュールに供給されるように、仮想関数テーブル内の各関
数ごとに図２に示すプロセスが繰り返される。

【００５８】ＩＢＭ（商標）のＯＳ／２（商標）オペレ
ーティング・システム上で使用可能なオブジェクト・モ
ジュール・フォーマット（ＯＭＦ）での使用に適した定
義済みイントロデューサ制御データを収集するための具
体的なインプリメンテーションについては以下に示す。
このインプリメンテーションでは、特定の形式のＯＭＦ
ＣＯＭＥＮＴレコードを使用して、定義済みイントロ
デューサ制御データを収集する。その一例は以下の通り
である。

【００５９】 １ １ １または２ １または２ ［'ＡＢ'｜'０６'｜関数インデックス｜イントロデューサ・インデックス］ ＜反復＞

【００６０】レコードのヘッダにある'ＡＢ''０６'とい
う指定は、定義済みイントロデューサ制御データを表す
ものとしてこのレコードを識別するものである。

【００６１】関数インデックスとイントロデューサ・イ
ンデックスは、リンカが認識するコンパイラが検査中の
関数の名前を含むストリングを指し示すコードを含んで
いる。コンパイラは、メソッド名集合として知られる名
前ストリングの集合から関数インデックスを選択する。
この集合は、ＯＳ／２オペレーティング・システムにお
いて他の２次制御データ・レコードによって定義され
る。イントロデューサ・インデックスもメソッド名集合
インデックスである。この場合、イントロデューサ・イ
ンデックスは、関数インデックスによって識別される関
数のイントロデューサである基本クラス・メソッドの名
前を集合インデックスから選択する。

【００６２】本発明の他のインプリメンテーションは、
コンパイル・データベース内の再配置可能アドレスまた
は位置など、名前インデックスまたは関数名以外の手段
によって関数およびイントロデューサを識別できるはず
である。当業者にとって明白な他の識別手段は、本発明
に含まれるものとする。

【００６３】図３は、メンバ関数への呼出しをコンパイ
ルするときに本発明を実施するためにコンパイラが行う
追加のアクションを示している。具体的には。図３は、
メンバ関数への呼出しをコンパイルするときに実行すべ
き被呼イントロデューサ・レコードを生成するためのコ
ンパイラ・プロセスの流れ図である。この活動の目的
は、コンパイルによって生成されたオブジェクト・ファ
イルに被呼イントロデューサ制御データ・レコードを組
み込むことである。これらの被呼イントロデューサ制御
データ・レコードは、コンパイル中に検出された各仮想
関数呼出しごとに、その被呼仮想関数のイントロデュー
サ（複数も可）を識別するものである。被呼イントロデ
ューサ制御データ・レコードは、このようなレコードを
生成するために行ったコンパイルの回数に応じて、定義
済みイントロデューサ制御データと同じかまたは別個の
出力ファイル内に位置することができる。

【００６４】図３の活動は、明白に呼び出された関数が
仮想関数であるかどうかをコンパイラが判定することか
ら始まる（ブロック４０）。この判定は、当技術分野で
周知の方法でコンパイラ記号テーブルを検査することに
よって行われる。関数が仮想関数である場合、コンパイ
ラは関数のイントロデューサを検出する（ブロック４
２）。これは、実行時に実際にどの関数が呼び出される
かをコンパイラが一般に判定できない場合でも可能であ
る。コンパイラは、各イントロデューサ用の被呼イント
ロデューサ・レコードがすでにオブジェクト・モジュー
ルに送られているかどうかを判定する（ブロック４
４）。レコードがすでに送られている場合は、コンパイ
ラ操作は完了である。送られていない場合は、コンパイ
ラは、被呼イントロデューサを指定するレコードをオブ
ジェクト・モジュールに送る（ブロック４６）。被呼関
数用のすべてのイントロデューサがオブジェクト・モジ
ュールに供給されるまで、このプロセスが繰り返される
（ブロック４８、５０）。

【００６５】この設計の変形であって、当業者にとって
明白なものは、最終オブジェクト・モジュールが含む
「被呼イントロデューサ」レコードの数がより少なくな
り、そのそれぞれが含む被呼イントロデューサの数が増
えるように、単一コンパイル中にこの活動を繰り返し呼
び出すことにより生成される「被呼イントロデューサ」
レコードを統合することである。

【００６６】ＯＳ／２オペレーティング・システムで本
発明を実施するために、以下のフォーマットの被呼イン
トロデューサ・レコードを使用することができる。

【００６７】

【００６８】呼び出され側インデックスは、現行オブジ
ェクトのメソッド名集合へのインデックスである。

【００６９】前述の定義済みイントロデューサと被呼イ
ントロデューサの制御レコードは、本発明を実施するた
めにオブジェクト・モジュールに組み込まれる最も重要
な制御データを含んでいる。これらは、潜在的に呼出し
可能な関数を識別するステップを実行するためにリンカ
が使用する。この情報は、リンクされた実行可能ファイ
ルによって呼出し可能でなければならない関数をリンカ
が判定できるようにするために不可欠なものである。こ
れらとともにその他の補助制御レコードを使用し、メソ
ッド名集合を定義し、ＶＦＴでのみ参照される仮想関数
を識別する第１のステップと、呼出し不能の関数へのＶ
ＦＴ参照を無効にする第３のステップとをリンカが実行
できるようにする。

【００７０】関数の参照の無効化は、その関数が外部記
号によって表される場合のみ意味をなし、その定義がす
でに検出されている場合と同様に外部記号を取り扱うこ
とによって行われる。この定義のために想定した値は、
ゼロなどの従来の空白値か、または何らかのエラーによ
ってそれを呼び出すことができる場合に有用な診断情報
を生成するような何らかの位置またはライブラリ入口点
のアドレスになる。無効にした記号は、もはや未定義で
はないので、その解決のためにライブラリを探索させる
ことはなく、定義ライブラリ・メンバをリンクに含める
ようにすることもない。

【００７１】コンパイラは、無効化に使用する従来の値
を指定するために、補助制御レコードをオブジェクト・
ファイルに組み込むことができる。ＯＳ／２ ＯＭＦオ
ブジェクト・フォーマットでの使用に適した定義は以下
の通りである。

【００７２】

【００７３】ＥＸＴＤＥＦインデックス・フィールド
は、無効にしたＶＦＴ参照のためのデフォルト解決とし
て使用すべき外部記号へのインデックスである。ＯＳ／
２オブジェクト・モジュール・フォーマットでは、「Ｅ
ＸＴＤＥＦインデックス」が外部リンカ記号を参照する
ための標準的な方法である。特殊な場合として、インデ
ックス０は有効であり、無効にしたＶＦＴ参照のデフォ
ルトが仮想アドレス０になる（すなわち、ＦＬＡＴ：
０）。

【００７４】ＶＦＴから参照した関数を識別するステッ
プは、ＶＦＴを定義するオブジェクト・モジュールに補
助制御データを組み込むコンパイラによって可能にな
る。制御データは、定義済みイントロデューサと被呼イ
ントロデューサのレコードで使用したものと似ている表
記法を使用して、ＶＦＴから参照したこれらの関数を直
接識別することができる。

【００７５】より優れた代替方法であって、オブジェク
ト・モジュールで必要とする空間がより少ないものは、
ＶＦＴを識別する制御データを送ることである。リンカ
は、ＶＦＴデータを含みしかもその記号参照を記述する
オブジェクト・モジュール内のレコードを検査し、それ
により、ＶＦＴが参照する関数のリストを蓄積すること
ができる。適切なデータおよび記号参照レコードを設け
ることは、既存のオブジェクト・モジュール・フォーマ
ットではすでに一般的なやり方であり、唯一の必要な追
加部分はＶＦＴを識別するための制御レコード・データ
である。

【００７６】ＯＳ／２では、すべてのデータとコード
は、共通の属性と多くの場合は名前を備えた記憶域の論
理的集合である「セグメント」に明示的または暗示的に
関連付けられている。したがって、ＶＦＴのみを含む特
殊セグメントを作成することにより、ＶＦＴで参照され
た関数を識別する。これにより、すべてのＶＦＴが確実
に特殊セグメントに関連付けられ、この点でどのセグメ
ントが特殊なのかをリンカに示すことになる。

【００７７】

【００７８】セグメント・インデックスは、仮想関数テ
ーブルを含むセグメントを識別するものである。セグメ
ントを識別するためにインデックスを使用することは、
ＯＳ／２オブジェクト・モジュール・フォーマットでは
既存のやり方である。

【００７９】他の補助制御データ・レコードは、基本組
込み制御データ・レコードが使用するストリング、記
号、またはその他のデータのテーブルまたは集合を定義
するために、必要に応じてオブジェクト・モジュールに
組み込まれる。このようなテーブルおよび集合の使い方
は、当業者には十分理解されている。これらのテーブル
および集合は、記号またはストリングが基本制御データ
・レコードに直接含まれている場合に、より簡単なイン
プリメンテーションに対して相対的にオブジェクト・モ
ジュールのサイズを低減するように機能する。ＯＳ／２
インプリメンテーションでは、定義済みイントロデュー
サおよび被呼イントロデューサのレコード内の数値フィ
ールドによってメソッド名集合にインデックスが付けら
れ、２つの補助制御データ・レコードを使用してこの集
合を定義する。１つのレコードは文字のストリングとし
て名前を含み、もう１つのレコードはその名前がすでに
オブジェクト・モジュールに存在し、テーブルに含める
必要がある外部記号を参照する。

【００８０】第１のレコードは以下のフォーマットにな
っている。

【００８１】

【００８２】もう１つのレコードは以下のフォーマット
になっている。

【００８３】

【００８４】値１を有し、定義済みイントロデューサま
たは被呼イントロデューサのレコードに現れるメソッド
名集合インデックスが、第１のこのようなレコードによ
って追加された第１の名前を選択し、値２が第２の名前
を選択し、以下同様になるように、これらのレコードは
メソッド名集合に名前を追加していく。

【００８５】前述の制御データ・レコードは、図２およ
び図３に示す活動に従ってコンパイラによってオブジェ
クト・モジュールに組み込まれる。これにより、リンク
・ステップの出力から呼出し不能な仮想関数を除去また
は省略する本発明の第３のステップを実行できるように
するために十分な情報がリンカに供給される。このステ
ップを実現するリンカの活動については、以下に説明す
る。

【００８６】呼出し不能な仮想関数を除外するという作
業は、集成制御データから判定したように、アプリケー
ション・プログラムに現れる仮想関数テーブルによって
参照されるが、アプリケーションの実行中に呼び出され
ることがない仮想関数をアプリケーション・プログラム
から除外するために集成制御データを使用して、リン
カ、プレリンカ、または同様のユーティリティによって
達成される。

【００８７】ＶＦＴのみから参照される仮想関数を識別
するという作業は、前述のように、このような関数を識
別する制御レコードを明示的に組み込むことによって可
能にすることができる。しかし、同じく前述したよう
に、オブジェクト・モジュール・フォーマットによって
は、ＶＦＴそのものとその記号参照を検査することによ
って、参照する関数のリストのアセンブルが可能になる
ものもある。

【００８８】この改良にとって障害になっている点は、
ＶＦＴが外部記号の場合もあれば、そうではない場合も
あることである。すなわち、オブジェクト・モジュール
の外部では、ＶＦＴの名前が見える場合もあれば、見え
ない場合もある。したがって、ＶＦＴに特定の名前を与
えてもＶＦＴを認識することはできない。というのは、
それらが外部記号ではない場合、その名前をオブジェク
ト・モジュールに格納できないからである。本明細書に
記載するインプリメンテーションでは、すべてのＶＦＴ
を特殊セグメントに入れ、特殊セグメントをリンカに対
して識別する前述の制御レコードを組み込むことによっ
て、この問題が解決される。この場合、すべてのＣ＋＋
オブジェクトを検査し、ＶＦＴセグメント用のデータ・
レコードを探すことができる。１つ見つかるたびに、そ
の後に続くリンカ・レコードを検査しなければならな
い。このような直後のレコードは、リンカがその直前レ
コードでパッチをあてる必要がある外部参照を記述する
ものである。これらは、蓄積する必要がある仮想関数参
照である。内部参照、すなわち、同じオブジェクト内で
定義された仮想関数への参照は、おそらくこのようにし
て欠落してしまう。というのは、そのためのリンカ・レ
コードが存在するが、そのレコードは外部記号を参照し
ないからである。しかし、それらの完全セットより少数
の関数をこの作業で蓄積することは、いつでも安全なこ
とである。

【００８９】ＶＦＴセグメント用のデータ・レコードが
あるかどうかリンカ・レコードを検査することに加え、
他のデータおよびコード・レコードのためにリンカ・レ
コードを走査することも必要である。コードまたは非Ｖ
ＦＴデータ・レコードによって参照される仮想関数は、
蓄積したリストから除去しなければならない。最終的な
リストは、その参照がすべてＶＦＴセグメントからであ
るような仮想関数のみを含んでいる必要がある。

【００９０】図４〜８は、本発明のそれぞれの該当部分
を実施するためにリンカが実行する活動を示している。
したがって、これらの図で想定している本発明の実施例
は、図２および図３の活動を実行するコンパイラと、図
４〜８の活動を実行するリンカとの協調を含む実施例で
ある。

【００９１】図４〜８は、従来の２パス設計のリンカに
よって行われる活動を示し、コンパイラからリンク活動
に入力として供給されるオブジェクト・モジュールに組
み込まれた「定義済みイントロデューサ」および「被呼
イントロデューサ」レコードに含まれる余分な制御デー
タと、リンカがアクセスするライブラリまたは同様のア
ーカイブに含まれるオブジェクト・モジュールに含まれ
る制御データ・レコードとを収集するように、その挙動
の変更態様を構成する。また、リンカは、どの仮想関数
がＶＦＴのみから参照されるかを判定できるようにする
補助組込み制御データも収集する。次にリンカは、収集
した制御データを使用し、まったく呼び出されないとリ
ンカが判定できるＣ＋＋仮想関数を実行可能プログラム
から除外する。

【００９２】図４には、リンカの記号テーブルで記号を
「検出または入力する」という従来のリンカ活動の修正
が記載されている。従来の２パス・リンカは、リンクに
含まれるオブジェクト・モジュールで記号定義または参
照を検出すると、第１のパス中にこの活動を実行するも
のと予想される。このオブジェクト・モジュールは、リ
ンク操作への入力として明示的に命名されるか、または
オブジェクト・モジュールのライブラリまたは同様のア
ーカイブから抽出される。「記号」は、比較可能データ
項目の大規模セットの１つの要素であり、一般に印刷可
能文字のストリングの形態を取り、これらの文字にはタ
イプ、値、可視範囲を含みかつこれらに限定されない属
性が付加されている。記号はオブジェクト・モジュール
内で定義されるが、外部の可視範囲を有する場合、その
値を他のオブジェクト・モジュールが参照することがで
きる。参照による記号定義の突合せまたは「リンク」
は、リンカまたはリンク・ローダの基本活動である。

【００９３】「記号テーブル」は、リンカが維持する探
索可能テーブルであり、リンクに含まれるオブジェクト
・モジュールで定義または参照あるいはその両方が行わ
れる記号の項目を含んでいる。各項目は、記号そのもの
と、その関数を実行するためにリンカが必要とするその
記号に関する関連情報とを含む。通常、これは、記号の
タイプと、値と、可視範囲とを含むが、他の情報を含む
こともできる。

【００９４】リンカが第１のパス中にオブジェクト・モ
ジュールで記号を検出すると、リンカは通常、「記号テ
ーブルで記号を検出するかまたは記号テーブルに入力す
る」というアクションを実行する（ブロック５８、６
０）。これは、それがすでに記号テーブル内にある場合
に記号の項目を突き止めること、またはそれがまだテー
ブル内にない場合に新しい項目を作成することから構成
される。

【００９５】リンカが通常実行する「検出または入力」
アクションの修正については図４に示す。リンカは、第
１のパス中に、新たに作成した記号テーブル項目用の３
つの新しい関連情報の初期値を確立する（ブロック６
２）。第１の関連情報は「参照タイプ」である。この
「参照タイプ」は、「UNKNOWN」、「NONVFT」、「VFT」
という３つの値の１つを取ることができる。第２の情報
は「呼出し状況」であり、これは「CALLED」または「NO
TCALLED」という値の１つを取る。第３の関連情報は「O
VERRIDERS」リストである。これは、記号のリストであ
って、いつでも０個またはそれ以上の記号を含むことが
できる。

【００９６】当業者には明白と思われるこの設計の改善
点は、仮想関数を表す記号に対応する記号テーブル項目
についてのみ、この３つの余分な関連情報を提供するこ
とである。

【００９７】図５は、どの仮想関数がＶＦＴのみから参
照されるかを判定するのに必要な余分な活動を示してい
る。ＶＦＴは、仮想関数のアドレスを含むデータ構造で
あり、この包含は、仮想関数テーブルを含むデータ・レ
コードに適用され再配置の存在に反映される。「再配
置」とは、マシン・コードまたはデータ項目をリンカま
たはローダによってどのように修正すべきかを記載し
た、オブジェクト・モジュール内の制御情報の１項目で
ある。このような修正は、その項目あるいはその他の何
らかのコードまたはデータ項目の最終的な位置によって
決まるか、または何らかの記号の値によって決まる。Ｖ
ＦＴに適用される再配置により、リンカまたはローダ
は、仮想関数テーブルに外部仮想関数のアドレスを格納
するように指示される。このような仮想関数が他のオブ
ジェクト・モジュール内にある場合、再配置は必然的に
その仮想関数を表す記号を参照することになる。

【００９８】同様に、ＶＦＴを含まない他のコードまた
はデータ・レコードも、仮想関数を参照することができ
る。ＶＦＴを含む場合、これは、他のコードまたはデー
タ・レコードに適用される再配置を検査することによっ
て認識可能になる。

【００９９】図５に示すように、リンカは、コードまた
はデータ・レコードを検出すると、そのレコードに適用
される再配置を突き止める（ブロック５２）。次に、こ
の再配置を順にアクセスし、それぞれの再配置を検査し
て、それが記号を参照するかどうかを判定する（ブロッ
ク５４、５６）。それが記号を参照する場合、リンカ記
号テーブルを検査して、その記号がすでにテーブル内に
あるかどうかを判定する。記号がすでにリンカ記号テー
ブル内にある場合、リンカは次のステップに移行する。
記号がテーブル内にない場合、図４に示すように、リン
カはその記号をテーブルに追加し、次のステップに移行
する。次のステップでリンカは、再配置によって影響を
受ける現行コードまたはデータ・レコードの一部分がＶ
ＦＴを含むかどうかを判定する（図５のブロック６
４）。コードまたはデータ・レコードがＶＦＴではない
場合、記号参照タイプを「NONVFT」に設定する（ブロッ
ク６６）。コードまたはデータ・レコードがＶＦＴであ
る場合、リンカはまず、記号テーブル項目の「参照タイ
プ」フィールドの現在値が「UNKNOWN」という値を持っ
ているかどうかを検査する。参照タイプが「UNKNOWN」
である場合、記号参照タイプを「VFT」に設定する（ブ
ロック６８、７０）。この追加のリンカ活動が終了する
時点でそれ以上の再配置がなくなるまで、リンカはこの
サイクルを繰り返す（ブロック７２）。この活動の結果
として、仮想関数の記号テーブル項目は、まったく参照
されない場合には「UNKNOWN」、ＶＦＴではないコード
またはデータによって少なくとも１回は参照される場合
には「NONVFT」、少なくとも１回は参照され、すべての
参照がＶＦＴからのものである場合には「VFT」という
「最小タイプ」フィールド値を取ることになる。

【０１００】図５に記載する活動の場合、リンカは、検
出したコードまたはデータ・レコードが仮想関数テーブ
ルであるかどうかを判別できなければならない。ＯＳ／
２インプリメンテーションでは、これは、前述の補助制
御データ・レコードによって識別される特殊メモリ「セ
グメント」に仮想関数テーブルを関連させることによっ
て行われる。コードまたはデータ・レコードのセグメン
トとの関連は、すでにＯＳ／２のオブジェクト・モジュ
ール・フォーマットになっている。その他のシステムで
は、その値がコードまたはデータ・レコード内のコード
またはデータ・レコードのアドレスである認識可能記号
を定義することを含みかつそれに限定されないような他
の方法で仮想関数テーブルを区別することができる。Ｃ
＋＋インプリメンテーションによっては、仮想関数テー
ブルに仮想関数アドレスを格納せず、むしろ「サンク」
のアドレスを格納するものもある。「サンク」とは、実
際の仮想関数を呼び出すマシン・コードの小さい文字列
である。仮想関数テーブルから参照される記号について
作業する代わりに、このような仮想関数「サンク」から
参照される記号を処理するように、図５の活動を修正す
ることは、上記の技法の明白な変形である。具体的に
は、「現行コードまたはデータ・レコードが仮想関数テ
ーブルであるかどうか」というテストが「現行コードま
たはデータ・レコードが仮想関数サンクであるかどう
か」に修正されるはずである。

【０１０１】図６は、組み込まれた定義済みイントロデ
ューサ制御データ・レコードに含まれる情報を集成する
ためにリンカが行う追加の活動を示している。コンパイ
ラは、図２に示すプロセスによって定義済みイントロデ
ューサ制御データ・レコードを生成している。前述のよ
うに、これらの制御レコードは、関数と、そのイントロ
デューサの１つまたはそれ以上を識別するものである。
図６に示すように、リンカは、リンカ記号テーブル内の
関数を調べ、そこになければ、関数をテーブルに追加す
る（ブロック７４）。次にリンカは、検出または入力し
たばかりの記号テーブル項目の参照タイプを調べ、その
関数が「NONVFT」参照を備えていると判断されたかどう
かを判定する（ブロック７６）。その関数が「NONVFT」
参照タイプを備えている場合、それはＶＦＴ以外から参
照されているので、リンクから省略することができず、
その関数に関してそれ以上追加の活動は一切行われな
い。関数が「VFT」参照タイプを備えている場合、リン
カは、図４に関連して記載したやり方で定義済みイント
ロデューサ制御データ・レコードにリストされた第１の
定義済みイントロデューサをリンカ記号テーブルで検出
するかまたはリンカ記号テーブルに入力する。次にリン
カは、定義済みイントロデューサの記号テーブル項目に
関連する「呼出し状況」情報を検査する（ブロック７
８）。状況が「CALLED」である場合、関数の参照タイプ
を「NONVFT」に設定して、その関数をリンクから省略す
ることができないことを示し、リンカ活動は完了する
（ブロック８０）。

【０１０２】代わりに定義済みイントロデューサの呼出
し状況が「NOTCALLED」である場合、リンカは、定義済
みイントロデューサ記号のOVERRIDERSリストに定義済み
関数を追加する（ブロック８２）。次にリンカは、組み
込まれた定義済みイントロデューサ制御データ・レコー
ドにリストされた他の定義済みイントロデューサの処理
を続行する（ブロック８４）。まったく存在しない場
合、リンカ・パスは完了する。定義済みイントロデュー
サがそれ以上見つかった場合、そのイントロデューサは
リンカ記号テーブルで検出されるかまたはリンカ記号テ
ーブルに入力され（ブロック８６）、それ以上の定義済
みイントロデューサが一切検出されなくなるまで、呼出
し状況が判定され、定義済み関数がOVERRIDERSリストに
追加される。この時点で、このリンカ・パスは完了す
る。

【０１０３】図６および図２に示す結合アクションの影
響は、VFTまたはUNKNOWNという参照タイプを備えたどの
仮想関数についても、リンカがその関数の定義済みイン
トロデューサをすべて検査し、そのいずれかがCALLEDと
マークされているかどうかを判定することである。CALL
EDとマークされたものは、潜在的に呼出し可能であるの
で、現在の関数はそのイントロデューサの指定変更であ
り、同じく呼出し可能であり、その参照タイプをNONVFT
に変更してこれを反映する。その関数の定義済みイント
ロデューサのいずれもCALLEDとマークされていない場
合、その関数は、以下に記載し図７に示す活動を見越し
て、各定義済みイントロデューサのOVERRIDERSリストに
追加される。

【０１０４】図７は、「被呼イントロデューサ」レコー
ドを検出したときに第１のパス中にリンカが実行すべき
新しいアクションを示している。リンカはまず、各「被
呼イントロデューサ」を検出し、それをリンカ記号テー
ブルに入力する（ブロック９０、９２）。各「被呼イン
トロデューサ」の状況が判定され、すでに「CALLED」に
なっていなければ、「CALLED」に設定する（ブロック９
４、９６）。各「被呼イントロデューサ」の参照タイプ
も「NONVFT」に設定し（ブロック９８）、それをリンク
から省略できないことを示す。次に、各被呼イントロデ
ューサの「OVERRIDERS」リスト内の各記号を検出し、検
出した各記号の参照タイプも「NONVFT」に設定する（ブ
ロック１００〜１０８）。これは、レコード内のすべて
の被呼イントロデューサについて繰り返される（ブロッ
ク１１０、１１２）。

【０１０５】各被呼イントロデューサごとに、図７の活
動により、被呼イントロデューサの呼出し状況が確実に
CALLEDになり、したがって、図６のその後の実行におい
て同じ記号が定義済みイントロデューサであると判断さ
れた場合、それがイントロデューサになる仮想関数は、
潜在的に呼出し可能であると認識される。また、被呼イ
ントロデューサの参照タイプと、図６の活動の先行呼出
しによってその記号テーブル項目のOVERRIDERSリストに
蓄積された被呼イントロデューサのすべての指定変更側
の参照タイプにも、NONVFTという参照タイプが与えら
れ、それらも潜在的に呼出し可能であって、リンクから
省略できないことを示す。

【０１０６】図８は、第１のパス中にオブジェクト・モ
ジュールの静的ライブラリまたは同様のアーカイブを検
査するときに従来設計の２パス・リンカによって行われ
る活動の変更態様を示している。この活動の目的は、ど
のオブジェクト・モジュールをアーカイブからロードす
べきかを決定することと、図４〜７の実行によって蓄積
された呼出し可能性情報をこの判定の基礎とすることで
ある。

【０１０７】従来設計のリンカは、次のような基準に基
づいてこの決定を行う。すなわち、現在、リンカの記号
テーブルで検出され、参照済みとマークされたがまだ定
義されていないような、いずれかの外部可視範囲の記号
がオブジェクト・モジュールによって定義される場合
は、そのオブジェクト・モジュールをアーカイブからロ
ードすることである。

【０１０８】図８で実施されている変更態様は、上記の
基準が次のように変更されているものである。すなわ
ち、現在、リンカの記号テーブルで検出され、参照済み
とマークされたがまだ定義されておらず、その参照タイ
プがVFTではないような、いずれかの外部可視範囲の記
号がオブジェクト・モジュールによって定義される場合
は、そのオブジェクト・モジュールをアーカイブからロ
ードすることである（ブロック１１４〜１２６）。

【０１０９】この変更態様では、仮想関数を表す記号で
あって、それらを参照し、仮想関数テーブルに関連する
任意のオブジェクト・モジュール内の明示的な再配置を
備え（これは、図４で参照タイプをUNKNOWNからVFTに変
更する際の条件である）、仮想関数テーブルではないコ
ードまたはデータ・レコードに関連する再配置を備えて
いない（そうではない場合、図４で参照タイプがNONVFT
に変更されるはずである）ような記号と、被呼イントロ
デューサではなく（そうではない場合、図７で参照タイ
プがNONVFTに変更されるはずである）、被呼イントロデ
ューサのオーバーライダでもない（そうではない場合、
定義済みイントロデューサおよび被呼イントロデューサ
・レコードが検出された相対順序に応じて、図６または
図７で参照タイプがNONVFTに変更されるはずである）記
号を除外する。

【０１１０】リンカ・パス１の終了時には、図示してい
ないもう１つのステップが行われる。その参照タイプが
「VFT」ではない参照済み未定義記号が記号テーブルに
まったく含まれていない場合、または参照済み未定義記
号を解決せずにすべての使用可能ライブラリが探索され
た場合に、パス１が終了する。この時点では、参照タイ
プが「VFT」である残りの参照済み未定義記号にデフォ
ルト定義を与える必要があり、ここに記載するＯＳ／２
インプリメンテーションでは、定義として供給する値が
補助制御データ・レコードによって供給される。

【０１１１】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１１２】（１）オブジェクト指向ソース・プログラ
ムをオブジェクト・モジュールにコンパイルするための
コンパイラ手段と、前記オブジェクト・モジュールを実
行可能ファイルにリンクするためのリンカ手段とを有す
るコンピューティング環境において、前記リンカ手段が
実行時に仮想関数を呼び出すための仮想関数テーブルを
初期設定するための手段を含み、実行可能ファイルの実
行効率を改善するための方法であって、潜在的に呼出し
可能なものとして仮想関数を識別するために前記制御デ
ータがリンク中にアクセス可能で、コンパイル中に各仮
想関数テーブルを識別する制御データを生成するステッ
プと、潜在的に呼出し可能なものとして識別された仮想
関数のみをリンクするステップとを含むことを特徴とす
る方法。 （２）前記制御データを生成するステップが、前記ソー
ス・プログラムのコンパイル中に検出された各仮想関数
のための定義済みイントロデューサのリストをコンパイ
ルすることと、各被呼イントロデューサが実際に呼び出
される関数を含む仮想関数のグループを識別する被呼イ
ントロデューサのリストをコンパイルすることと、前記
リストを制御データ・レコードとしてオブジェクト・モ
ジュールに組み込むことを含み、潜在的に呼出し可能な
ものとして識別された仮想関数のみをリンクする前記ス
テップが、仮想関数テーブルによってのみ参照される仮
想関数のリストを蓄積するステップと、制御データ・レ
コードとして組み込まれる定義済みイントロデューサと
被呼イントロデューサの前記リストと、リンク中にコン
パイルされた仮想関数の前記リストから判定されるよう
に潜在的に使用される仮想関数へのポインタをリンクす
るステップとを含むことを特徴とする、上記（１）に記
載の方法。 （３）前記制御データを生成するステップが、各仮想関
数テーブル用の制御データを前記オブジェクト・モジュ
ールの１つに組み込むステップを含むことを特徴とす
る、上記（１）に記載の方法。 （４）前記制御データを生成するステップが、前記ソー
ス・プログラムのコンパイル中に検出された各仮想関数
のための定義済みイントロデューサのリストをコンパイ
ルするステップと、各オブジェクト・モジュール用の被
呼イントロデューサのレコードをコンパイルするステッ
プとを含み、潜在的に呼出し可能なものとして識別され
た仮想関数のみをリンクする前記ステップが、仮想関数
テーブルによってのみ呼出し可能な仮想関数のリストを
蓄積するステップと、前記コンパイル・ステップによっ
てコンパイルされた定義済みイントロデューサと被呼イ
ントロデューサの前記リストと、リンク中にコンパイル
された仮想関数の前記リストから判定されるように実際
に使用される仮想関数へのポインタをリンクするステッ
プとを含むことを特徴とする、上記（３）に記載の方
法。 （５）潜在的に呼出し可能なものとして識別された仮想
関数のみをリンクする前記ステップが、リンク中に仮想
関数テーブルを初期設定する前に、潜在的に呼出し可能
ではない仮想関数への参照を無効にするステップを含む
ことを特徴とする、上記（１）または（４）に記載の方
法。 （６）オブジェクト指向言語で作成されたソース・コー
ドを実行可能ファイルに変換するための改良されたシス
テムであって、前記改良されたシステムが、定義済みイ
ントロデューサのリストを生成し、前記定義済みイント
ロデューサのそれぞれが仮想関数のグループを識別する
手段と、仮想関数テーブルによってのみ参照される仮想
関数のリストを維持する手段と、被呼イントロデューサ
のリストを生成し、各被呼イントロデューサが潜在的に
呼び出される仮想関数のグループを識別する手段と、仮
想関数テーブルによってのみ参照され、定義済みイント
ロデューサ、被呼イントロデューサ、および仮想関数の
前記リストでは識別されない仮想関数を実行するために
前記実行可能ファイルを生成する手段とを含むことを特
徴とするシステム。 （７）コンパイル可能なオブジェクト指向プログラミン
グ言語で作成されたソース・プログラムから派生したマ
シン実行可能コードの実行効率を改善するための機構で
あって、コンパイル中に仮想関数の定義と使い方にタグ
付けを行えるようになっているコンパイラと、タグ付き
仮想関数を識別し、呼び出すことができるタグ付き定義
をリンクし、呼び出すことができない前記タグ付き仮想
関数の定義を無効にすることができるようになっている
リンク手段とを含むことを特徴とする機構。 （８）オブジェクト指向ソース・プログラムをオブジェ
クト・モジュールにコンパイルするためのコンパイラ手
段と、オブジェクト・モジュールを実行可能ファイルに
リンクするためのリンカ手段とを有するコンピューティ
ング環境において、前記リンカ手段が実行時に仮想関数
を呼び出すための仮想関数テーブルを初期設定するため
の手段を含み、実行可能ファイルの実行効率を改善する
ための方法ステップを実行するために、マシンが実行可
能な命令のプログラムを具体的に実施する、マシンが読
取り可能なプログラム記憶装置であって、前記方法ステ
ップが、コンパイル中に各仮想関数テーブルを識別する
制御データを生成し、潜在的に呼出し可能なものとして
仮想関数を識別するために前記制御データがリンク中に
アクセス可能なステップと、潜在的に呼出し可能なもの
として識別された仮想関数のみをリンクするステップと
を含むことを特徴とするプログラム記憶装置。

【図面の簡単な説明】

【図１】コンパイラとリンカが実行可能ファイルを作成
する方法を示す概略図である。

【図２】定義済みイントロデューサ・レコードを生成す
るためのコンパイラ・プロセスの流れ図である。

【図３】被呼イントロデューサ・レコードを生成するた
めのコンパイラ・プロセスの流れ図である。

【図４】記号を検出するかまたは記号を記号テーブルに
入力するためのリンカ・プロセスの流れ図である。

【図５】コードまたはデータ・レコードについて実行さ
れるリンカ・プロセスの流れ図である。

【図６】定義済みイントロデューサ・レコードについて
実行されるリンカ・プロセスの流れ図である。

【図７】被呼イントロデューサ・レコードについて実行
されるリンカ・プロセスの流れ図である。

【図８】静的ライブラリを読み取るときに実行されるリ
ンカ・プロセスの流れ図である。

【図９】オブジェクトと仮想関数テーブルと仮想関数と
の間に存在する参照を示す概略図である。

【図１０】仮想関数テーブルを含む複数のオブジェクト
・モジュールの概略表現である。

【図１１】本発明の使用によるリンカ出力の違いを示す
概略図である。

【図１２】本発明の使用によるリンカ出力の違いを示す
概略図である。

【符号の説明】

１０ コンパイラ １２ リンカ １４ アーカイバ／ライブラリアン １６ａ ライブラリ＃１ １６ｂ 他のライブラリ １８ 実行可能ファイル

Claims (8)

【特許請求の範囲】
1. 【請求項１】オブジェクト指向ソース・プログラムをオ
   ブジェクト・モジュールにコンパイルするためのコンパ
   イラ手段と、前記オブジェクト・モジュールを実行可能
   ファイルにリンクするためのリンカ手段とを有するコン
   ピューティング環境において、前記リンカ手段が実行時
   に仮想関数を呼び出すための仮想関数テーブルを初期設
   定するための手段を含み、実行可能ファイルの実行効率
   を改善するための方法であって、 潜在的に呼出し可能なものとして仮想関数を識別するた
   めに前記制御データがリンク中にアクセス可能で、コン
   パイル中に各仮想関数テーブルを識別する制御データを
   生成するステップと、 潜在的に呼出し可能なものとして識別された仮想関数の
   みをリンクするステップとを含むことを特徴とする方
   法。
2. 【請求項２】前記制御データを生成するステップが、 前記ソース・プログラムのコンパイル中に検出された各
   仮想関数のための定義済みイントロデューサのリストを
   コンパイルすることと、 各被呼イントロデューサが実際に呼び出される関数を含
   む仮想関数のグループを識別する被呼イントロデューサ
   のリストをコンパイルすることと、 前記リストを制御データ・レコードとしてオブジェクト
   ・モジュールに組み込むことを含み、 潜在的に呼出し可能なものとして識別された仮想関数の
   みをリンクする前記ステップが、 仮想関数テーブルによってのみ参照される仮想関数のリ
   ストを蓄積するステップと、 制御データ・レコードとして組み込まれる定義済みイン
   トロデューサと被呼イントロデューサの前記リストと、
   リンク中にコンパイルされた仮想関数の前記リストから
   判定されるように潜在的に使用される仮想関数へのポイ
   ンタをリンクするステップとを含むことを特徴とする、
   請求項１に記載の方法。
3. 【請求項３】前記制御データを生成するステップが、各
   仮想関数テーブル用の制御データを前記オブジェクト・
   モジュールの１つに組み込むステップを含むことを特徴
   とする、請求項１に記載の方法。
4. 【請求項４】前記制御データを生成するステップが、 前記ソース・プログラムのコンパイル中に検出された各
   仮想関数のための定義済みイントロデューサのリストを
   コンパイルするステップと、 各オブジェクト・モジュール用の被呼イントロデューサ
   のレコードをコンパイルするステップとを含み、 潜在的に呼出し可能なものとして識別された仮想関数の
   みをリンクする前記ステップが、 仮想関数テーブルによってのみ呼出し可能な仮想関数の
   リストを蓄積するステップと、 前記コンパイル・ステップによってコンパイルされた定
   義済みイントロデューサと被呼イントロデューサの前記
   リストと、リンク中にコンパイルされた仮想関数の前記
   リストから判定されるように実際に使用される仮想関数
   へのポインタをリンクするステップとを含むことを特徴
   とする、請求項３に記載の方法。
5. 【請求項５】潜在的に呼出し可能なものとして識別され
   た仮想関数のみをリンクする前記ステップが、リンク中
   に仮想関数テーブルを初期設定する前に、潜在的に呼出
   し可能ではない仮想関数への参照を無効にするステップ
   を含むことを特徴とする、請求項１または４に記載の方
   法。
6. 【請求項６】オブジェクト指向言語で作成されたソース
   ・コードを実行可能ファイルに変換するための改良され
   たシステムであって、前記改良されたシステムが、 定義済みイントロデューサのリストを生成し、前記定義
   済みイントロデューサのそれぞれが仮想関数のグループ
   を識別する手段と、 仮想関数テーブルによってのみ参照される仮想関数のリ
   ストを維持する手段と、 被呼イントロデューサのリストを生成し、各被呼イント
   ロデューサが潜在的に呼び出される仮想関数のグループ
   を識別する手段と、 仮想関数テーブルによってのみ参照され、定義済みイン
   トロデューサ、被呼イントロデューサ、および仮想関数
   の前記リストでは識別されない仮想関数を実行するため
   に前記実行可能ファイルを生成する手段とを含むことを
   特徴とするシステム。
7. 【請求項７】コンパイル可能なオブジェクト指向プログ
   ラミング言語で作成されたソース・プログラムから派生
   したマシン実行可能コードの実行効率を改善するための
   機構であって、 コンパイル中に仮想関数の定義と使い方にタグ付けを行
   えるようになっているコンパイラと、 タグ付き仮想関数を識別し、呼び出すことができるタグ
   付き定義をリンクし、呼び出すことができない前記タグ
   付き仮想関数の定義を無効にすることができるようにな
   っているリンク手段とを含むことを特徴とする機構。
8. 【請求項８】オブジェクト指向ソース・プログラムをオ
   ブジェクト・モジュールにコンパイルするためのコンパ
   イラ手段と、オブジェクト・モジュールを実行可能ファ
   イルにリンクするためのリンカ手段とを有するコンピュ
   ーティング環境において、前記リンカ手段が実行時に仮
   想関数を呼び出すための仮想関数テーブルを初期設定す
   るための手段を含み、実行可能ファイルの実行効率を改
   善するための方法ステップを実行するために、マシンが
   実行可能な命令のプログラムを具体的に実施する、マシ
   ンが読取り可能なプログラム記憶装置であって、前記方
   法ステップが、 コンパイル中に各仮想関数テーブルを識別する制御デー
   タを生成し、潜在的に呼出し可能なものとして仮想関数
   を識別するために前記制御データがリンク中にアクセス
   可能なステップと、 潜在的に呼出し可能なものとして識別された仮想関数の
   みをリンクするステップとを含むことを特徴とするプロ
   グラム記憶装置。