JPH09282167A - メソッド起動方法及びメソッド起動制御装置 - Google Patents

メソッド起動方法及びメソッド起動制御装置

Info

Publication number
JPH09282167A
JPH09282167A JP8087857A JP8785796A JPH09282167A JP H09282167 A JPH09282167 A JP H09282167A JP 8087857 A JP8087857 A JP 8087857A JP 8785796 A JP8785796 A JP 8785796A JP H09282167 A JPH09282167 A JP H09282167A
Authority
JP
Japan
Prior art keywords
selector
specified
code
class
dispatch table
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP8087857A
Other languages
English (en)
Inventor
Tamiya Onodera
民也 小野寺
Hiroaki Nakamura
宏明 中村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to JP8087857A priority Critical patent/JPH09282167A/ja
Priority to TW085116119A priority patent/TW331614B/zh
Priority to US08/832,655 priority patent/US5987529A/en
Publication of JPH09282167A publication Critical patent/JPH09282167A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented
    • G06F9/449—Object-oriented method invocation or resolution

Abstract

(57)【要約】 （修正有） 【課題】メモリ効率を向上させ、高速にメッセージ送信
を行えるようにする。 【解決手段】指定されたレシーバ・オブジェクトより、
そのクラス・オブジェクトＣを得る１１０。クラス・オ
ブジェクトＣには、そのクラスのディスパッチ表を指す
インスタンス変数が設けられており、ディスパッチ表Ｄ
を得る１２０。vmicall命令の引数であるcodeから、デ
ィスパッチ表のcode番目に格納されているアドレスのメ
ソッドＭを取り出す１３０。vmicall命令のもう１つの
引数であるcardと、ステップ１３０にて取り出されたメ
ソッドＭに格納されている札番とを比較する１４０。ca
rdと札番が不一致の場合、セレクタ不一致ハンドラを呼
び出し、呼び出そうとした正しいメソッドを探し出す１
５０。そして、このメソッドＭを起動する１６０。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、オブジェクト指向
プログラムにおけるメッセージ送信の実行に関し、より
詳しくは、少数の小さなディスパッチ表を用いて、メッ
セージ送信のコストを配列の参照と間接手続き呼び出し
のコストに軽減し且つメモリ効率を改善するメッセージ
送信の実装方法に関する。
【０００２】
【従来の技術】手続き言語では手続き呼び出しが基本的
な計算パラダイムであるように、オブジェクト指向言語
ではメッセージ送信が基本的な計算パラダイムである。
従って、メッセージ送信を効率的に実装することがオブ
ジェクト指向言語を効率的に実装する上で必要不可欠と
なる。ところが、オブジェクト指向言語では、メッセー
ジ送信の実行で起動されるメソッドは、レシーバ・オブ
ジェクトのクラスによって変化し、コンパイル時に決定
することはできない。これはメソッドの動的束縛（dyna
mic binding）と呼ばれ、実行時にメソッド探索という
作業を行わなければならない。このためメッセージ送信
の処理が重くなり、実行性能上の隘路となっている。
【０００３】メソッド探索とは、レシーバ・オブジェク
トのクラス（型）とセレクタ（メソッドの名前）の対か
ら実行すべきメソッドを探し出すことである。メソッド
探索の有力な実装方法の一つにディスパッチ表法があ
る。この方法の基本的なアイデアは、考えられるクラス
とセレクタの組み合わせに対して「予め」メソッド探索
を行っておき、結果をディスパッチ表と呼ばれる配列に
格納しておくというもので、メソッド探索のコストは配
列の参照のコストとなる。
【０００４】具体的には、セレクタに番号を振り、クラ
スごとにディスパッチ表を作成する。あるクラスＣが理
解できるセレクタｓごとに対応するメソッドを探索し、
クラスＣのディスパッチ表のＣＯＤＥ（ｓ）番目にその
アドレスを格納する（ＣＯＤＥは、セレクタの集合から
正整数への写像で、セレクタの番号付けを表してい
る。）。そして、オブジェクトのヘッダにアドレスを格
納する等して、オブジェクトからディスパッチ表が簡単
に辿れるようにしておく。このようにすると、メッセー
ジ送信を行うように命ずる高級言語での命令は、コンパ
イルされると、ほぼ以下のような擬似Ｃコードのように
なる。 (*receiver->dispatchTable[CODE(selector)]) (receiver, arg1, arg2,...);
【０００５】このように、メソッド探索は配列の参照に
帰着し、メッセージ送信のコストは配列の参照と間接手
続き呼び出しコストまで減少する。これはＣ＋＋の仮想
関数呼び出しのコストと同等である。
【０００６】単純なディスパッチ表法では、ＣＯＤＥ関
数として全てのセレクタにユニークな番号を振るものを
用いる。一例として、図１１のようなクラス階層を考え
る。全体では６個の異なるセレクタがあり、４個のクラ
スに８個のメソッドが定義されている。図１１におい
て、クラスに対応するノードの右に書かれているのが、
そのクラスで定義されているメソッドのセレクタであ
る。この図１１のようなクラス階層の場合に作成され
る、単純法でのディスパッチ表及びセレクタの付番の例
を図１２に示す。
【０００７】この単純法のメモリ効率を考えてみると、
セレクタ数の大きさのディスパッチ表がクラス数だけ存
在することになる。ディスパッチ表のエントリの大きさ
が４バイトとすると、図１１の例では６×４×４バイト
＝９６バイトのメモリ消費量となる。図１１の例では単
純法でも問題ないように見えるが、巨大な商用システム
に適用した場合には、表１が示すようにメモリ消費量の
観点から実用的ではない。
【０００８】
【表１】
【０００９】ところで商用システム等の大きなシステム
に適用した場合のディスパッチ表はいわゆる疎な配列
（sparse array）で、ほとんどのエントリは使用されて
いない。システムに存在するセレクタ全部を１つのクラ
スが理解できるわけではなく、一般にはその小さな部分
集合でしかないからである。従って表１に示されている
ように充填率、すなわち「ディスパッチ表のメモリ消費
量」に対する「空でないエントリのメモリ消費量」の割
合は数％であり、かなり低くなってしまう。
【００１０】このような観点から、メモリ効率の改善の
余地は大いに残されており、実際幾つかの方法が提案さ
れている。代表的な圧縮方法として、行転位法（row di
splacement）とセレクタ彩色法（selector coloring）
が知られている。
【００１１】行転位法の基本的考え方は、複数の疎な配
列を１つの長い配列に詰め込むというものである。例え
ば、図１２のディスパッチ表は図１３のように詰め込ま
れる。商用システムに単純法を適用し且つ行転位法にて
圧縮した場合の充填率を表２の「行転位法（クラス
毎）」の欄に示す。
【００１２】
【表２】
【００１３】セレクタ彩色法は、「全部のセレクタにユ
ニークな番号を割り当てる必要はない」という洞察に基
づいている。ここでは、２つのセレクタがある同一のク
ラスによって理解される時、２つのセレクタは衝突（co
nflict）するというが、衝突する場合に限り異なる番号
を割り当てればよい。具体的な番号付けを行う手順は、
いわゆるグラフ彩色の問題に還元することができる。す
なわち、セレクタをノードとし、衝突するセレクタ間に
アークを引いて得られるグラフをできる限り少ない色数
で彩るという問題である。このようにしてセレクタに割
り当てられた番号は、セレクタの色又は色番号と呼ばれ
る。図１１のセレクタに対する彩色の一例と、それに基
づいて構成されるディスパッチ表を図１４に示す。（こ
の彩色は実は最適なものである。）
【００１４】セレクタ彩色法では、ディスパッチ表の大
きさは色数に等しくなる。そして、最適な色数は、１つ
のクラスが理解できるセレクタ数よりも小さくならな
い。このことから、メモリ消費量の下限や充填率の上限
を求めることができる。この充填率の上限を表２の「セ
レクタ彩色法（上限）」の欄に示す。
【００１５】ところで、行転位法には発想の転換ともい
える変形が存在する。それは、セレクタに付番し且つク
ラス毎にディスパッチ表を作るのではなく、クラスに付
番し、そしてセレクタ毎にディスパッチ表を作るという
ものである。できあがったディスパッチ表は同様に１つ
の長い配列に詰め込まれるものである。表２の「行転位
法（セレクタ毎）」の欄に示されているように、この変
形を商用システムに適用すると充填率はほぼ１００％近
くにまで上昇することが報告されている。理由は、行転
位法で使用される詰め込みのためのアルゴリズムが、少
数の長い配列よりは多数の短い配列を好むからである。
表１でクラスの数とセレクタの数を比較してみれば分か
るように、セレクタ毎にディスパッチ表を作った方が多
数の短い配列が最初に作成される。
【００１６】以上、３つの圧縮方法を示したが、ディス
パッチ表にとって問題なのは、たとえ１００％の充填率
でもメモリ効率は満足のいくようなものではないという
ことである。表３に充填率１００％の場合のメモリ効率
を示すが、結果的に仮想イメージを５０％以上も増大さ
せるようであれば、やはり実用的であるとはいえない。
（Smalltalkは、ハードウエアと連携してシステム全体
を制御する仮想マシーンと、アプリケーション・プログ
ラム等を含む仮想イメージとにより構成される。）
【００１７】
【表３】
【００１８】すなわち、ディスパッチ表法は、メッセー
ジ送信の実装方法として時間効率の点においては優れて
いるが、メモリ効率に問題があり、実用的なものとは考
えられなくなる。
【００１９】なお、以下に述べる本願発明との差異を明
確にするために、ディスパッチ表法に圧縮技法を用いた
場合の問題について説明しておく。すなわち、行転位法
又はセレクタ彩色法を用いるにせよ、セレクタ不一致
（selector mismatch）という現象が発生し、これに対
する処置を行わなければならない。
【００２０】セレクタ彩色法の場合を例に説明する。ま
ず、メッセージ送信式「aNumber quo: 7」という、aNum
ber というオブジェクトにquo:というセレクタのメッセ
ージを７を引数にして送信する場合を考える。セレクタ
が図１４のように彩色されている場合、このメッセージ
送信式のコンパイル結果は、擬似Ｃコードにて次のよう
になる。 // quo:の色番は３ （*aNumber->dispatchTable[3])(aNumber,7)
【００２１】ここで変数aNumberが「誤って」Collectio
nオブジェクトを指していたとすると、quo:セレクタはC
ollectionクラスでは理解できないのにもかかわらずdo:
セレクタのメソッドを起動させてしまうことになる。こ
れがセレクタ不一致という現象で、当然見過ごすことは
できない。この対処方法としては、札番照合というもの
を用いるとよい。まず、各セレクタに色番とは別に札番
（card）というユニークな番号を振り、メソッドにはそ
のメソッドのセレクタの札番を格納しておく。そして、
メッセージ送信が発生した場合には、「送信式中のセレ
クタの札番」と「起動されるメソッドのセレクタの札
番」を比較照合するのである。札番照合を用いた場合、
上のメッセージ送信式のコンパイル結果は、次のような
擬似Ｃコードにて表される。 // quo: の色番は３、札番は２６ method = aNumber->dispatchTable[3]; if (method->selectorCard == 26) (*method)(aNumber,7) else SelectorMismatchHandler(...);
【００２２】なお、札番の維持管理はさほど高価なもの
となならない。例えば、セレクタ表というハッシュ・テ
ーブルにすべてのセレクタを登録し、このテーブルの索
引を札番として用いればよいのである。セレクタ表の大
きさはセレクタ数の２倍ほどで十分である。
【００２３】上で述べたセレクタ不一致ハンドラSelect
orMismatchHandlerは、例外DoesNotUnderstandを発生す
る。しかし、誤って他のオブジェクトを示したり、何等
かのエラーが生じない限り、セレクタ不一致は発生する
ものではない。
【００２４】また、他の従来技術として特開平５−２０
０８２号には、上述の単純法に近い方法が記載されてい
る。
【００２５】さらに、特開平６−２１４８８４号には、
メッセージ送信に用いる表のエントリ数を制限すること
が記載されている。
【００２６】しかし、このような文献には、上述したよ
うなディスパッチ表法の時間効率の良さを保持したま
ま、メモリ効率を向上させる方法は記載されていない。
【００２７】
【発明が解決しようとする課題】よって、本願発明は以
上述べたような従来技術の欠点を改善するものであり、
オブジェクト指向プログラムにおいて、ディスパッチ表
法の時間効率の良さを保持しつつ、メモリ効率を向上さ
せる方法を提供することを目的とするものである。
【００２８】
【課題を解決するための手段】以上述べた目的を達成す
るために本願発明では、セレクタに番号（コード番号）
を振り、クラスに対してディスパッチ表を作成し、セレ
クタの番号で参照することによりメソッド探索を高速化
する。但し、全てのセレクタを付番の対象とするのでは
なく、また、全てのクラスに対してディスパッチ表を作
るのではない。プログラムの持つ参照局所性を利用し、
いわゆる"ホット"なセレクタのみを付番し、いわゆる"
ホット"なクラスにだけディスパッチ表を作るようにす
る。具体的には、ディスパッチ表の大きさを第１の所定
数のエントリに制限し、ディスパッチ表の数も同様に第
２の所定数に制限する。すなわち、新たに作成されたデ
ィスパッチ表をディスパッチ表のためのキャッシュ（第
２の所定数の表を収納可能）にキャッシュし、新たに使
用されたメソッドをディスパッチ表（第１の所定数のメ
ソッドを収納可能である。）にキャッシュするようなも
のである。メモリ消費量はシステムの大小にかかわらず
一定であり、先の例のようにディスパッチ表のエントリ
１つにつき４バイトであり、例えば、第１及び第２の所
定数を双方６４とした場合には、メモリ消費量は１６Ｋ
バイトとなる。表１における商用システムにおける仮想
イメージの１％にも満たない量に減少させることができ
る。
【００２９】ディスパッチ表は、通常のキャッシュと同
様に扱われる。すなわち、新しいディスパッチ表を作成
するにあたって、空いている領域があればその領域を用
い、空いている領域がなければ、ＦＩＦＯ（First In F
irst Out）や、ＬＲＵ（Least Recently Used）などの
アルゴリズムに従い、既存のディスパッチ表内のエント
リを追い出して用いるようにする。
【００３０】アプリケーション・プログラムなどの実行
が進むにつれて、新しいメソッド（のアドレス）がディ
スパッチ表に入っていくが、その場合、そのメソッドの
セレクタに番号（コード）が割り当てられてからそのコ
ードのインデックスの所に入れられる。よって、ディス
パッチ表の大きさは使用する番号の数（第１の所定数に
等しい）となり、メソッドが次々に用いられると番号が
不足するが、その場合には先に述べたようにＦＩＦＯや
ＬＲＵ等のアルゴリズムで使用中のコードから廃棄する
コードを選択する。この廃棄により、セレクタへのコー
ドの割当が取り消され（cancelation）、仮想イメージ
のあちこちに矛盾（inconsistencies）が生じる。これ
らの矛盾箇所は一括して修正されるのではなく、以下で
説明するセレクタ不一致ハンドラを通じて必要に応じて
段階的に修正される。すなわち、このセレクタ不一致ハ
ンドラは、メソッド探索を実行し、コードの割当てを受
けると共に、適切なメソッドのアドレスを適切なディス
パッチ表のコード番号の所に記憶し、次にこのメソッド
を使用する際には、このディスパッチ表のこのコード番
号の所を参照するようにしておく。
【００３１】このようなセレクタ不一致ハンドラの動作
により、ディスパッチ表の数及びそのエントリの数を制
限し、随時更新しても、矛盾の一括回復処理を回避で
き、メソッド起動の時間を高速化し、且つメモリ効率を
向上させることができる。
【００３２】以上をまとめると、オブジェクト指向プロ
グラムにおいて指定されたレシーバ・オブジェクトのク
ラスの指定されたメソッドを探索・起動する方法であっ
て、メソッドの名前であるセレクタには予め札番号が割
り当てられ、各々所定数のエントリを有するディスパッ
チ表がオブジェクトのクラスごとに必要に応じて設けら
れ、ディスパッチ表においては実行されるメソッドのア
ドレスを当該メソッドのセレクタに割り当てられるコー
ド番号のエントリに記憶するようになっており、（ａ）
指定されたレシーバ・オブジェクトのクラスと、指定さ
れたメソッドのアドレスを記憶しているとされるエント
リのコード番号と、指定されたメソッドのセレクタの札
番号とを指示する指示ステップと、（ｂ）指示されたク
ラス及びコード番号により特定されるディスパッチ表の
エントリに記憶されたアドレスが指すメソッドを取り出
すステップと、（ｃ）取り出されたメソッドのセレクタ
の札番号と指定されたメソッドのセレクタの札番号とを
比較する比較ステップと、（ｄ）札番号が不一致である
場合、指定されたレシーバ・オブジェクトのクラスと指
定されたメソッドのセレクタの札番号に適合するメソッ
ドを検出する検出ステップと、（ｅ）指定されたメソッ
ドのセレクタにコード番号を割り当て、検出されたメソ
ッドのアドレスを指定されたレシーバ・オブジェクトの
クラス用のディスパッチ表の割り当てられたコード番号
のエントリに記憶する表修正ステップと、（ｆ）指示ス
テップで指示されるコード番号と割り当てられたコード
番号とを一致させるステップと、（ｇ）検出ステップに
より検出されたメソッドを起動するステップとを含むも
のである。
【００３３】また、先の表修正ステップが、割り当て可
能なコード番号のうち用いられていないコード番号が存
在する場合には、当該用いられていないコード番号の１
つを前記指定されたメソッドのセレクタに割り当てるス
テップを含むようにすることも考えられる。
【００３４】また、先の表修正ステップが、未使用のコ
ード番号がなければ、使用されたのが最も古いコード番
号を、前記指定されたメソッドに割り当てるステップを
含むようにすることも考えられる。
【００３５】さらに、先の表修正ステップが、用いられ
ていないコード番号がなければ、既にコード番号が割り
当てられているセレクタのうちで、コード番号を割り当
てようとするセレクタと衝突していないセレクタを検出
し、当該検出されたセレクタのコード番号を割り当てる
ステップを含むようにすることも考えられる。
【００３６】また、表修正ステップが、指定されたレシ
ーバ・オブジェクトのクラス専用にディスパッチ表が用
意されているかを判断するステップと、指定されたレシ
ーバ・オブジェクトのクラス専用にディスパッチ表が用
意されていない場合には、ディスパッチ表の割り当てを
受ける表割当ステップを含むようにすることも考えられ
る。
【００３７】さらに、ディスパッチ表の数が所定数に限
定されており、先の表割当ステップが、所定数のディス
パッチ表が使用されているかを判断するステップと、所
定数のディスパッチ表が使用されている場合には、使用
されたのが最も古いディスパッチ表を廃棄し、当該指定
されたレシーバ・オブジェクト用に割り当てるステップ
とを含むようにすることも考えられる。
【００３８】また、比較ステップにおいて、札番号が一
致する場合には、取り出されたメソッドを起動するよう
にすることは通常行われることである。
【００３９】以上、本発明の一形態を示したが、このよ
うな機能を有する専用を装置を作成すること及び、この
ような機能をコンピュータに実施させるプログラム・コ
ードを格納した記憶デバイスを作成することは、以下の
実施例を理解した当業者により通常実施できるものであ
る。
【００４０】
【発明の実施の形態】本発明を準備段階から順に説明す
る。 （１）準備ステップ 通常、メッセージ送信では、指定されたレシーバ・オブ
ジェクトに指定されたメソッドのセレクタが指定された
引数と共に送られる。この送信の実装において先に述べ
たようなディスパッチ表法を用いることとする場合、図
１のような構造となる。すなわち、ｆｏｏというメソッ
ドにあるメッセージ送信は、レシーバ・オブジェクトに
向けられ、このレシーバ・オブジェクトにはそのクラス
・オブジェクトへのポインタが置かれている。そして、
このクラス・オブジェクトには、dispatchTableという
インスタンス変数が追加されており、このクラスのディ
スパッチ表を指すようになっている。ここで、指定され
たメソッドのセレクタに付されたコード番号から、この
ディスパッチ表のエントリを取り出せば、指定されたメ
ソッドのアドレスを得ることができる。初期的には、di
spatchTableインスタンス変数は、デフォルトのディス
パッチ表を示すようになっている。このデフォルトのデ
ィスパッチ表は、システムに１つ設けられており、全て
のエントリは、selectorMismatchRaiserという特殊メソ
ッドのアドレスを格納している。すなわち、最初のメッ
セージ送信においては、かならずselectorMismatchRais
erメソッドが取り出され、後に詳しく述べるが、セレク
タ不一致ハンドラselectorMismatchHandlerが起動され
る。
【００４１】また、ユーザが高級言語にてメッセージ送
信命令を記述する場合、レシーバ・オブジェクトと、セ
レクタと、必要な場合には引数を指定する。このような
メッセージ送信命令をコンパイルすると、レシーバ・オ
ブジェクトと、指定された場合には引数をスタックに積
み、先に述べた札番号とコード番号を引数とするvmical
l命令に置換する（バイトコードの場合）。このvmicall
命令の内容は、後に詳しく述べるのでここでは省略す
る。マシン語にコンパイルする場合であっても、このvm
icall命令と同様の動作を行うようなコードを生成する
ようにする。
【００４２】また、有限個のコードの割当てを統括する
コード・マネージャを設ける。このコード・マネージャ
の動作についても後に説明するので、ここでは存在のみ
を示しておく。同様に、ディスパッチ表の数も制限され
るのでディスパッチ表の割り当ても変更されることがあ
る。よってディスパッチ表マネージャも必要である。
【００４３】また、メソッドの各セレクタには、生成さ
れた時にユニークな札番が付される。これは従来技術と
同様である。
【００４４】以上のような準備がなされた後に、高級言
語にて記述されたメッセージ送信命令が、どのような動
作にて処理されるかを、以下に示す。
【００４５】（２）実行処理 あるオブジェクトにて、初めてメッセージ送信を行わな
ければならない状態になったとする。このオブジェクト
のメッセージ送信命令は、バイトコードであれば、以下
のようなコードとなっている。 push 345 push 3 vmicall(26,1) ここで、３４５は、レシーバ・オブジェクトであり、３
は引数である。また、先に述べたvmicall命令が続いて
おり、この命令の引数である２６はメソッドのセレクタ
の札番であり、同様に１はコード番号である。但し、初
めてのメッセージ送信であるから、一度もメソッド探索
が行われておらず、このコード番号は初期的に入れられ
た意味のない番号である。よって、バイトコードのイン
タプリタは、vmicall命令を以下のように解釈する。
（擬似Ｃコードによる記述。）
【００４６】 void vmicall(card,code){ //Get the receiver from the stack receiver=....; //Perform a quick method lookup by array idexing Method method = receiver->Klass->dispatchTable[code]; //Check cards to see if a selector mismatch does not happen. if (method ->card!=card) method = selectorMismatchHandler(receiver->Klass,card,code); //Invoke the method invoke(method) }
【００４７】このvmicall命令の解釈を図２を用いて説
明する。ステップ１００にて処理を開始し、指定された
レシーバ・オブジェクトより、そのクラス・オブジェク
トＣを得る（ステップ１１０）。これは、レシーバ・オ
ブジェクトをvmicallの前にスタックに入れているの
で、それを取り出せばよい。また、レシーバ・オブジェ
クトにはそのクラス・オブジェクトへのポインタが置か
れているので、それを手繰ると、クラス・オブジェクト
Ｃを得ることができる。
【００４８】そして、準備ステップで述べたように、ク
ラス・オブジェクトＣには、そのクラスのディスパッチ
表を指すインスタンス変数が設けられており、ディスパ
ッチ表Ｄを得ることができる（ステップ１２０）。この
例では、最初のメッセージ送信であるから、ディスパッ
チ表Ｄはデフォルトのディスパッチ表Ｄが得られる。そ
して、vmicall命令の引数であるcodeから、ディスパッ
チ表のcode番目に格納されているアドレスのメソッドＭ
を取り出す（ステップ１３０）。但し、ディフォルトの
ディスパッチ表Ｄには、すべてselectorMismatchRaiser
メソッドのアドレスが置かれている。そして、vmicall
命令のもう１つの引数であるcardと、ステップ１３０に
て取り出されたメソッドＭに格納されている札番とを比
較する（ステップ１４０）。この例では、取り出された
selectorMismatchRaiserメソッドは特殊メソッドである
から、呼び出そうとするメソッドとは異なる。よって、
引数であるcardとselectorMismatchRaiserメソッドの札
番は等しくない。よって、後に述べるセレクタ不一致ハ
ンドラを呼び出し、呼び出そうとした正しいメソッドを
探し出す。これをメソッドＭとする（ステップ１５
０）。そして、このメソッドＭを起動すると、当初の目
論見通りのメソッドが起動されたこととなる（ステップ
１６０）。また、ステップ１４０で、取り出されたメソ
ッドＭの札番と引数のcardが等しい場合には、その取り
出されたメソッドＭを起動しても何等問題ないので、ス
テップ１４０からステップ１６０にすぐに移行する。
【００４９】以上のような解釈がなされる訳であるが、
セレクタ不一致ハンドラが、正しいメソッドを起動する
上で重要な役割を担っていることが明瞭になったであろ
う。次に、このセレクタ不一致ハンドラの動作を説明す
る。
【００５０】（３）セレクタ不一致ハンドラ セレクタ不一致ハンドラのバイトコードのインタプリタ
における解釈を擬似Ｃコードで記述すると、以下のよう
になる。 Method selectorMismatchHandler(klass,card,code){ //Allocate a dispatch table if necessary if(klass->dispatchTable==defaultDispatchTable) klass->dispatchTable=allocDispatchTable(klass); //Perform a general lookup. Method method; if((method=lookupByCard(klass,card))==0){//Does not understand the messa ge} //Ask getSelectorCode() for the code of the selector. currentCode = getSelectorCode(card); //Stores the method into the dispacth table at the selector code. Klass->dispatchTable[currentCode]=method; //Backpatch the code argument of the icall instructioin if necessary. if (currentCode!=code) instructionPointer[-1]=currentCode. return method; }
【００５１】このセレクタ不一致ハンドラの解釈を図３
を用いて説明する。処理はステップ２００にて開始さ
れ、クラスＣのディスパッチ表Ｄはデフォルトのものか
を確認する（ステップ２１０）。もし、デフォルトのデ
ィスパッチ表であれば、クラスＣ用のディスパッチ表を
割り当てる（ステップ２２０）。ここで割り当てられた
ディスパッチ表をディスパッチ表Ｄとする。このディス
パッチ表割り当て処理（ディスパッチ表マネージャ）に
ついては後に述べる。先の例では、最初のメッセージ送
信であるから、デフォルトのディスパッチ表が示されて
おり、ステップ２２０に移行し、このクラス用のディス
パッチ表を割り当ててもらう。
【００５２】そして、クラスＣとセレクタ不一致ハンド
ラselectorMismatchHandlerの引数であるcardに対応す
るメソッドを探し出す（ステップ２３０）。この探し出
されたメソッドをメソッドＭとする。当然、このメソッ
ドＭのアドレスを得る。この探索処理は、従来から行わ
れてきたメソッド探索処理であるから、本願ではこれ以
上述べない。そして、このcardのセレクタにコード番号
を割り当てる。このコード番号の割り当て処理（コード
・マネージャ）についても後に述べる。新たに割り当て
られたコードをnewcodeとする（ステップ２４０）。こ
のように、呼び出すべき正しいメソッドのアドレス及び
メソッドのセレクタに割り当てられたコード番号が得ら
れたので、先に用意したディスパッチ表Ｄのnewcode番
目にメソッドＭのアドレスを格納する（ステップ２５
０）。
【００５３】ここで、このセレクタ不一致ハンドラsele
ctorMismatchHandlerの引数であるcodeとnewcodeが等し
いかを判断する（ステップ２６０）。もし、codeとnewc
odeが異なっている場合、vmicall命令の引数であるcode
をnewcodeで置換する（ステップ２７０）。先の例で
は、codeは１であった。ステップ２４０にて割り当てら
れたnewcodeが３であれば、vmicall(26,1)をvmicall(2
6,3)に書替える。このようにすることによって、何等の
変更がなく、もう一度同一のメッセージ送信を行う場合
には、ディスパッチ表Ｄから正しいメソッドＭのアドレ
スを直ちに得ることができるようになる。
【００５４】またステップ２６０で、新たに割り当てら
れたnewcodeがcodeと同一であれば、vmicallを書き直す
ことなく、次には正しいメソッドＭのアドレスを得るこ
とができる。そして、取り出したメソッドＭをvmicall
に戻す（ステップ２８０）。vmicallは先に述べたよう
に、メソッドＭを起動する。
【００５５】（４）ディスパッチ表の割り当て処理（デ
ィスパッチ表マネージャ） 図３のステップ２２０において説明したように、クラス
Ｃ用のディスパッチ表を用意する必要がある。しかし、
課題を解決するための手段の項にて説明したようにディ
スパッチ表の数には制限がある。よって、クラスＣ用に
ディスパッチ表を割り当てるといっても、ディスパッチ
表が不足する場合もある。ディスパッチ表が不足すれ
ば、どこかのクラスが用いていたディスパッチ表をとり
あげて、クラスＣ用のディスパッチ表としなければなら
ない。
【００５６】この場合には、ハードウエアのキャッシュ
を参考にするとよい。例えば、空きエリアがあるなら
ば、その空きエリアを用いるという事項や、最も用いら
れていないデータを無効として新たに書き込みを行った
り、という処理を応用できる。すなわち、ディスパッチ
表を作成することができる上限の数に到るまでは、必要
なクラスのディスパッチ表を割り当てる。そして、上限
数に到った場合には、最も用いられていないクラスのデ
ィスパッチ表を無効として、新たに必要になったクラス
用にそのディスパッチ表を割り当てたり、そのクラスに
割り当てられてから最も長い間、維持されているディス
パッチ表を無効にし、新たに必要になったクラス用にそ
のディスパッチ表を割り当てる等の処理が可能である。
このような処理の形態の選択は任意であり、必要に応じ
て変更することも可能である。
【００５７】図４は、このディスパッチ表割り当てステ
ップの概要を示すフローを示す。まず、処理はステップ
３００にて開始され、ディスパッチ表を上限数作成した
かを判断する（ステップ３１０）。そして、上限数作成
されていないのであれば、空きディスパッチ表をクラス
Ｃに割り当てる（ステップ３２０）。また、上限数ディ
スパッチ表が作成されており、空がなければ、適当なク
ラスのディスパッチ表を無効とする（ステップ３３
０）。この適当なクラスのディスパッチ表とは、先に述
べたような方法にて選択される。そして、ディスパッチ
表を無効とされたクラスのクラス・オブジェクトのdisp
atchTableインスタンス変数がデフォルトのディスパッ
チ表を指すようにする（ステップ３４０）。これによ
り、ディスパッチ表を無効にしたクラスのオブジェクト
にメッセージ送信がなされた場合には、図３のステップ
２１０からステップ２２０への遷移が行われるようにな
り、後に必要になってから、新たなディスパッチ表が割
り当てられる。
【００５８】そして、無効とされたディスパッチ表をク
ラスＣ用のディスパッチ表として割り当て、このクラス
Ｃのクラス・オブジェクトのdispatchTableインスタン
ス変数が、このディスパッチ表を指すようにする（ステ
ップ３５０）。このようにすれば、あるクラス用のディ
スパッチ表の割り当てがない場合であっても、新たな割
り当てがスムーズに行われ、他のクラスへの影響はな
い。
【００５９】（５）コード番号割り当て処理（コード・
マネージャ） 図３のステップ２４０では、単にcardのセレクタにコー
ド番号を割り当てるとしたが、ディスパッチ表と同様に
コード番号の数は制限されているため、割り当てるため
のコード番号がないという問題を生じる場合がある。当
然、割り当てのなされていないコード番号が存在するな
らば、そのコード番号をそのセレクタに割り当てればよ
い。しかし、ディスパッチ表の割り当ての場合と同様
に、割り当てるためのコード番号がない場合には、どの
コード番号を新たなセレクタに振り替えるかが問題とな
る。一番簡単なのは、先にも述べたようにハードウエア
のキャッシュを参考にして、最も用いられていないコー
ド番号を新たなセレクタに振り替えることである。ま
た、最も古いセレクタ-コード番号対を探し出し、その
コード番号を振り替えることもできる。高速にコード番
号の割り当てができるならば、このような振り替え用の
コード番号選択処理は任意であり、実施する者が適切な
態様を選択可能である。
【００６０】但し、先のディスパッチ表とは異なり、同
一のコード番号に多数のセレクタを割り当てても問題な
い場合もある。例えば、図１１のようなクラス構造を有
するプログラムの場合、セレクタquo:とセレクタselec
t:の双方を受信できるクラスは存在しないので、衝突し
ていない。今、割り当て可能なコード番号が存在せず、
セレクタselect:にはコードが既に割り当てられてお
り、新たにセレクタquo:にコードの割り当てを行う場
合、あるセレクタのコードを振り替えても良いが、セレ
クタselect:とセレクタquo:の関係より、同一のコード
番号をセレクタselect:及びセレクタquo:に割り当てて
も、ディスパッチ表内では十分区別できる。
【００６１】コード番号割り当ての一例を、図５を用い
て説明する。この図５は、未使用のコード番号がないこ
とを前提にしている。未使用のコード番号が存在するな
らば、それを用いればよい。処理はステップ４００にて
開始し、既にセレクタＳにコード番号が付されているか
を判断する（ステップ４１０）。付されていれば、その
コード番号を割り当てとして出力すればよい（ステップ
４２０）。しかし、付されていない場合、専用のディス
パッチ表を有しているクラスのみから構成される「ミ
ニ」クラス階層の該当するクラスに、そのセレクタＳを
登録する（ステップ４３０）。先にも用いたが、衝突す
るとは、「ミニ」クラス階層上で２つのセレクタを両方
受信できるクラスが存在する場合をいう。この「ミニ」
クラス階層は、セレクタの衝突を検知するために設ける
ものである。よって、クラスが新たに使用されるとディ
スパッチ表が新たに割り当てられ、それに応じてクラス
を「ミニ」クラスに登録する。また、クラスのディスパ
ッチ表が廃棄された場合には、そのクラスを「ミニ」ク
ラス階層から除去する。セレクタは、それにコード番号
が振られた時にそのクラスに登録する。コード番号の割
り当てが取り消されると、そのコード番号のセレクタ
を、全てのクラスから除去する。
【００６２】そして、セレクタＳと衝突しないセレクタ
が１つでも存在するかを判断する（ステップ４４０）。
もし、存在するならば、衝突しないセレクタのコード番
号をセレクタＳの割当として出力する（ステップ４５
０）。また、衝突しないセレクタが１つもない場合に
は、使用中のコード番号から１つ選択し、その割当を取
り消す（ステップ４６０）。この取り消されたコード番
号を用いていたセレクタは、「ミニ」クラス階層から除
去される。取り消されるコード番号の選択は、先に述べ
たような任意の方法を使用できる。そして、取り消され
たコード番号をセレクタＳの割当として出力する（ステ
ップ４７０）。
【００６３】以上は一例であって、未使用コード番号が
存在しても、同一セレクタが既に登録されていれば、そ
のコードを使用するようにしてもよい。
【００６４】以上述べたようなセレクタ不一致ハンドラ
等により、ディスパッチ表の一貫性がどのように保持さ
れるかを以下に述べる。先に述べたように、ディスパッ
チ表及びそのエントリの数は制限されている。よって、
セレクタへのコード番号の取消しが通常は発生し、ディ
スパッチ表の内容及びディスパッチ表のエントリを指し
示すコード番号を引数としているvmicall命令を含む仮
想イメージは、あちこちで矛盾を有するようになる。一
般的には、システムは直ちに一貫性の回復を図らなけれ
ばならない。しかし、一貫性回復のために実行が有意に
中断することは、本発明のシステムにおいては許されな
い。その理由は、矛盾を招来するコード番号割り当ての
取り消しはコード番号割り当て要求の際に起こり、コー
ド番号割り当ての要求は実行の真最中において発生する
からである。矛盾個所を見つけ出すために、システム中
のすべてのメソッドを走査するような処理を行うのは好
ましくない。
【００６５】よって、本発明では一貫性を全体的に一括
して回復するようなことはしない。多数の矛盾個所の中
で、必要なもののみ必要な時にセレクタ不一致ハンドラ
等にて回復処理を実行する。例えば、図６のように、コ
ード３がセレクタquo:及びdo:に割り当てられていた
が、do:への割り当てを取り消した場合、*)が付された
部分には矛盾が生じたことになる。しかし、クラスColl
ectionのディスパッチ表の第３エントリの値が変わらな
い限り、これらの矛盾状態は実害はない。よって、*)の
付されたvmicall命令がクラスCollectionのオブジェク
トをレシーバ・オブジェクトとして実行されても、正し
いメソッドが起動される。
【００６６】また、図６のＦのvmicall命令は、一度も
実行されたことのない命令であり、レシーバ・オブジェ
クトのクラス又はそのスーパークラスのメソッドであっ
てセレクタがdo:であるものの起動を命じるものであ
る。そして、この度クラスCollectionのオブジェクトを
レシーバ・オブジェクトとして実行され、セレクタ不一
致ハンドラを介してコード番号割り当てが先の説明のよ
うに実行されて、セレクタdo:のコード番号が５とされ
ると、図７のＦのように、vmicall命令の引数が５と変
更される。また、クラスCollectionのディスパッチ表の
５番目にセレクタdo:を有するメソッドのアドレスが格
納される。このクラスCollectionには、２つのエントリ
にメソッドdo:に対するアドレスが入力されているが、
これも実害はない。
【００６７】さらに、図６のＤのvmicall命令も一度も
実行されたことのない命令であり、レシーバ・オブジェ
クトのクラス又はスーパークラスのメソッドでセレクタ
select:を有するものの起動を命じるものである。このv
micall(42,1)がクラスCollectionのオブジェクトをレシ
ーバ・オブジェクトとして実行されると札番の不一致が
生じ、セレクタ不一致ハンドラが起動され、コード番号
割り当てが行われる。図８のように、セレクタselect:
にcode３を割り当てたとする。そうすると、最初の図６
にてセレクタdo:にcode３が割り当てられていたため
に、図８の**)の部分に矛盾が生じる。しかし、この**)
のvmicall(37,3)が実行されても実害はない。なぜな
ら、札番の検査にてセレクタ不一致ハンドラが起動さ
れ、正しいメソッドが探し出されるからである。また、
この**)のvmicall命令は、セレクタ不一致ハンドラによ
って正しく書き直される。
【００６８】以上は、ディスパッチ表は存在するがその
内容に矛盾が生じても、セレクタ不一致ハンドラが必要
に応じて必要なディスパッチ表のエントリ及びvmicall
命令を修正する場合を示した。これに対し、ディスパッ
チ表が不足することにより、あるクラスのディスパッチ
表がデフォルトのディスパッチ表となって矛盾が生じる
場合も同様である。必ず、札番検査によってセレクタ不
一致ハンドラが起動され、必要なクラスについてディス
パッチ表が割り当てられ、必要なコード番号の割り当て
及びディスパッチ表内のエントリへのアドレスの格納、
そして正しいメソッドの起動がなされる。
【００６９】以上の作業をSmalltalk言語によるコンピ
ュータ・プログラムにおいて実施する場合には、図９の
ような構造を採ることができる。Smalltalkでは、コン
ピュータ・プログラムは大きく仮想イメージと仮想マシ
ンに分けられる。本願におけるオブジェクト及びディス
パッチ表は仮想イメージに属する。一方、メソッド探索
やコードマネージャ及びディスパッチ表マネージャ等を
含むセレクタ不一致ハンドラ、及びオブジェクトの起動
を行うメソッド起動部は、仮想マシンに属する。このよ
うな構造にてプログラムを実行するコンピュータは、図
１０のような通常のコンピュータでよい。
【００７０】また、本発明を実施するために専用の装置
を設けることもできる。これは、図９におけ仮想マシン
の機能をそのままハードウエアにすることで実現可能で
ある。仮想マシンはそもそもハードウエアと仮想イメー
ジの間を取り持つものであるから、ハードウエアにて同
様の機能を実現するという事項は当業者には周知の事項
である。
【００７１】以上、本発明の一実施例を示したが、本発
明は上記の実施例に限定されるものではない。先に述べ
たように、ディスパッチ表の割り当て及びコードの割り
当てには様々な態様が考えられる。さらに、ディスパッ
チ表の数を制限したが、ディスパッチ表のエントリ数の
みを制限することもできる。すなわち、クラスに１つの
ディスパッチ表を割り当てるものである。ディスパッチ
表の数が増えれば仮想イメージ内のメモリ消費量は増加
するが、先に述べたディスパッチ表の自体の管理は必要
なくなり、その分処理は簡単になる。このような変形
は、メモリ効率及び実行速度のドレードオフで決まる。
【００７２】
【効果】オブジェクト指向プログラムにおいて、ディス
パッチ表法の時間効率の良さを保持しつつ、メモリ効率
を向上させる方法を提供することができた。
【図面の簡単な説明】
【図１】本発明のメッセージ送信の様子を示す模式図で
ある。
【図２】vmicall命令の処理を説明するためのフロー図
である。
【図３】セレクタ不一致ハンドラの処理を説明するため
のフロー図である。
【図４】ディスパッチ表割り当て処理の一例を示す図で
ある。
【図５】code割り当て処理の一例を示す図である。
【図６】ディスパッチ表及び仮想イメージの一貫性回復
の様子を説明するための図である。
【図７】ディスパッチ表及び仮想イメージの一貫性回復
の様子を説明するための図である。
【図８】ディスパッチ表及び仮想イメージの一貫性回復
の様子を説明するための図である。
【図９】システム構造を説明するための図である。
【図１０】一般のコンピュータの模式図である。
【図１１】クラス階層の一例を示す図である。
【図１２】単純なディスパッチ表法を説明するための図
である。
【図１３】行転位法によるディスパッチ表の圧縮を説明
するための図である。
【図１４】セレクタ彩色法によるディスパッチ表の圧縮
を説明するための図である。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 中村 宏明 神奈川県大和市下鶴間1623番地14 日本ア イ・ビー・エム株式会社 東京基礎研究所 内

Claims (9)

    【特許請求の範囲】
  1. 【請求項１】オブジェクト指向プログラムにおいて指定
    されたレシーバ・オブジェクトのクラスの指定されたメ
    ソッドを起動する方法であって、 前記メソッドの名前であるセレクタには予め札番号が割
    り当てられ、各々所定数のエントリを有するディスパッ
    チ表が前記オブジェクトのクラスごとに必要に応じて設
    けられ、前記ディスパッチ表においては前記メソッドの
    アドレスが当該メソッドのセレクタに割り当てられるコ
    ード番号のエントリに記憶されるようになっており、
    （ａ）前記指定されたレシーバ・オブジェクトのクラス
    と、前記指定されたメソッドのアドレスを記憶している
    とされるエントリのコード番号と、前記指定されたメソ
    ッドのセレクタの札番号とを指示する指示ステップと、
    （ｂ）指示された前記クラス及び前記コード番号により
    特定されるディスパッチ表のエントリに記憶されたアド
    レスが指すメソッドを取り出すステップと、（ｃ）前記
    取り出されたメソッドのセレクタの札番号と前記指定さ
    れたメソッドのセレクタの札番号とを比較する比較ステ
    ップと、（ｄ）前記札番号が不一致である場合、前記指
    定されたレシーバ・オブジェクトのクラスと前記指定さ
    れたメソッドのセレクタの札番号に適合するメソッドを
    検出する検出ステップと、（ｅ）前記指定されたメソッ
    ドのセレクタにコード番号を割り当て、前記検出された
    メソッドのアドレスを前記指定されたレシーバ・オブジ
    ェクトのクラス用のディスパッチ表の前記割り当てられ
    たコード番号のエントリに記憶する表修正ステップと、
    （ｆ）前記指示ステップで指示される前記コード番号と
    前記割り当てられたコード番号とを一致させるステップ
    と、（ｇ）前記検出ステップにより検出されたメソッド
    を起動するステップとを含むメソッド起動方法。
  2. 【請求項２】前記表修正ステップが、 割り当て可能なコード番号のうち用いられていないコー
    ド番号が存在する場合には、当該用いられていないコー
    ド番号の１つを前記指定されたメソッドのセレクタに割
    り当てるステップを含む請求項１記載のメソッド起動方
    法。
  3. 【請求項３】前記表修正ステップが、 前記用いられていないコード番号がなければ、使用され
    たのが最も古いコード番号を前記指定されたメソッドに
    割り当てるステップを含む請求項２記載のメソッド起動
    方法。
  4. 【請求項４】前記表修正ステップが、 前記用いられていないコード番号がなければ、既にコー
    ド番号が割り当てられているセレクタのうちで、コード
    番号を割り当てようとするセレクタと衝突していないセ
    レクタを検出し、当該検出されたセレクタのコード番号
    を割り当てるステップを含む請求項２記載のメソッド起
    動方法。
  5. 【請求項５】前記表修正ステップが、 前記指定されたレシーバ・オブジェクトのクラス専用に
    前記ディスパッチ表が用意されているかを判断するステ
    ップと、 前記指定されたレシーバ・オブジェクトのクラス専用に
    前記ディスパッチ表が用意されていない場合には、ディ
    スパッチ表の割り当てを受ける表割当ステップとを含む
    請求項１記載のメソッド起動方法。
  6. 【請求項６】前記ディスパッチ表の数が所定数に限定さ
    れており、 前記表割当ステップが、 前記所定数のディスパッチ表が使用されているかを判断
    するステップと、 前記所定数のディスパッチ表が使用されている場合に
    は、使用されたのが最も古いディスパッチ表を廃棄し、
    当該指定されたレシーバ・オブジェクト用に割り当てる
    ステップとを含む請求項５記載のメソッド起動方法。
  7. 【請求項７】前記比較ステップにおいて、前記札番号が
    一致する場合には、前記取り出されたメソッドを起動す
    るステップとをさらに含む請求項１記載のメソッド起動
    方法。
  8. 【請求項８】オブジェクト指向プログラムにおいて指定
    されたレシーバ・オブジェクトのクラスの指定されたメ
    ソッドの起動を制御する装置であって、 前記メソッドの名前であるセレクタには予め札番号が割
    り当てられており、 各々所定数のエントリを有するディスパッチ表を前記オ
    ブジェクトのクラスごとに必要に応じて作成し、前記デ
    ィスパッチ表において前記メソッドのアドレスを当該メ
    ソッドのセレクタに割り当てるコード番号のエントリに
    記憶するディスパッチ表管理手段と、 前記指定されたレシーバ・オブジェクトのクラスと、前
    記指定されたメソッドのアドレスを記憶しているとされ
    るエントリのコード番号と、前記指定されたメソッドの
    セレクタの札番号とを含む命令に応答して、当該クラス
    及び当該コード番号により特定されるディスパッチ表の
    エントリに記憶されたアドレスが指すメソッドを取り出
    すメソッド探索手段と、 前記取り出されたメソッドに格納されている札番号と前
    記指定されたメソッドのセレクタの札番号とを比較する
    比較手段とを有し、 前記メソッド探索手段は、前記比較手段から不一致を表
    す信号を受信した場合、前記指定されたレシーバ・オブ
    ジェクトのクラスと前記指定されたメソッドのセレクタ
    の札番号に適合するメソッドを検出し、 前記ディスパッチ表管理手段は、前記指定されたメソッ
    ドのセレクタにコード番号を割り当て、前記検出された
    メソッドのアドレスを前記指定されたレシーバ・オブジ
    ェクトのクラス用のディスパッチ表の前記割り当てられ
    たコード番号のエントリに記憶し、 前記命令中の前記コード番号と前記割り当てられたコー
    ド番号とを一致させ、前記メソッド探索手段により検出
    されたメソッドを起動させる制御手段をさらに有するメ
    ソッド起動制御装置。
  9. 【請求項９】コンピュータに、オブジェクト指向プログ
    ラムにおいて指定されたレシーバ・オブジェクトのクラ
    スの指定されたメソッドを起動させるプログラム・コー
    ドを含む記憶デバイスであって、 前記メソッドの名前であるセレクタには予め札番号が割
    り当てられ、各々所定数のエントリを有するディスパッ
    チ表が前記オブジェクトのクラスごとに必要に応じて設
    けられ、前記ディスパッチ表においては前記メソッドの
    アドレスが当該メソッドのセレクタに割り当てられるコ
    ード番号のエントリに記憶されるようになっており、 前記プログラム・コードは、 前記指定されたレシーバ・オブジェクトのクラスと、前
    記指定されたメソッドのアドレスを記憶しているとされ
    るエントリのコード番号と、前記指定されたメソッドの
    セレクタの札番号とを含む命令に応答して、指示された
    前記クラス及び前記コード番号により特定されるディス
    パッチ表のエントリに記憶されたアドレスが指すメソッ
    ドをコンピュータに取り出させるプログラム・コード
    と、 コンピュータに、前記取り出されたメソッドのセレクタ
    の札番号と前記指定されたメソッドのセレクタの札番号
    とを比較させる比較プログラム・コードと、 前記札番号が不一致である場合、コンピュータに、前記
    指定されたレシーバ・オブジェクトのクラスと前記指定
    されたメソッドのセレクタの札番号に適合するメソッド
    を検出させる検出プログラム・コードと、 コンピュータに、前記指定されたメソッドのセレクタに
    コード番号を割り当てさせ、前記検出されたメソッドの
    アドレスを前記指定されたレシーバ・オブジェクトのク
    ラス用のディスパッチ表における、当該メソッドのセレ
    クタに割り当てられたコード番号のエントリに記憶させ
    る表修正プログラム・コードと、 コンピュータに、前記命令の前記コード番号と前記割り
    当てられたコード番号とを一致させるプログラム・コー
    ドと、 コンピュータに、前記検出プログラム・コード及びコン
    ピュータにより検出されたメソッドを起動させるコード
    とを含む記憶デバイス。
JP8087857A 1996-04-10 1996-04-10 メソッド起動方法及びメソッド起動制御装置 Pending JPH09282167A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP8087857A JPH09282167A (ja) 1996-04-10 1996-04-10 メソッド起動方法及びメソッド起動制御装置
TW085116119A TW331614B (en) 1996-04-10 1996-12-27 Process and system of method invocation.
US08/832,655 US5987529A (en) 1996-04-10 1997-04-04 Invoking a method in an object-oriented computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP8087857A JPH09282167A (ja) 1996-04-10 1996-04-10 メソッド起動方法及びメソッド起動制御装置

Publications (1)

Publication Number Publication Date
JPH09282167A true JPH09282167A (ja) 1997-10-31

Family

ID=13926564

Family Applications (1)

Application Number Title Priority Date Filing Date
JP8087857A Pending JPH09282167A (ja) 1996-04-10 1996-04-10 メソッド起動方法及びメソッド起動制御装置

Country Status (3)

Country Link
US (1) US5987529A (ja)
JP (1) JPH09282167A (ja)
TW (1) TW331614B (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2796178A1 (fr) * 1999-07-06 2001-01-12 Schlumberger Systems & Service Procede de realisation de liens dynamiques dans une machine virtuelle

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6317796B1 (en) * 1997-10-06 2001-11-13 Sun Microsystems, Inc. Inline database for receiver types in object-oriented systems
US6385660B2 (en) * 1997-10-06 2002-05-07 Sun Microsystems, Inc. Site specific message dispatch in object-oriented systems
US6393491B1 (en) * 1999-04-26 2002-05-21 Sun Microsystems, Inc. Method and apparatus for dispatch table construction
US7100153B1 (en) * 2000-07-06 2006-08-29 Microsoft Corporation Compiler generation of a late binding interface implementation
US7150010B1 (en) 2000-07-06 2006-12-12 Microsoft Corporation Unification of a programming language and a definition language
JP4365148B2 (ja) * 2002-07-19 2009-11-18 株式会社リコー 画像形成装置及びラッピング処理方法並びにプログラム
US7296257B1 (en) * 2002-08-01 2007-11-13 Tymesys Corporation Techniques for exception handling by rewriting dispatch table elements
US6947955B2 (en) * 2002-09-23 2005-09-20 International Business Machines Corporation Run-time augmentation of object code to facilitate object data caching in an application server
US7496897B1 (en) 2004-03-17 2009-02-24 Timesys Corporation Multiple code sets for multiple execution contexts
US8291395B2 (en) * 2006-03-31 2012-10-16 Apple Inc. Fast function call dispatching
US7925640B2 (en) * 2008-02-14 2011-04-12 Oracle America, Inc. Dynamic multiple inheritance method dispatch data structure including an m-table size, i-table containing one or more holder addressor regions and type extension testing by frugal perfect hashing

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5379426A (en) * 1991-01-25 1995-01-03 Sun Microsystems, Inc. Method and apparatus for object oriented interprocess message switching
US5481708A (en) * 1992-06-05 1996-01-02 Borland International, Inc. System and methods for optimizing object-oriented compilations
US5581760A (en) * 1992-07-06 1996-12-03 Microsoft Corporation Method and system for referring to and binding to objects using identifier objects
US5600838A (en) * 1994-01-18 1997-02-04 Sybase, Inc. Object oriented dispatch and supercall process and arrangement
AU1747395A (en) * 1994-03-30 1995-10-23 Apple Computer, Inc. Object oriented message passing system and method

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2796178A1 (fr) * 1999-07-06 2001-01-12 Schlumberger Systems & Service Procede de realisation de liens dynamiques dans une machine virtuelle

Also Published As

Publication number Publication date
US5987529A (en) 1999-11-16
TW331614B (en) 1998-05-11

Similar Documents

Publication Publication Date Title
KR100506522B1 (ko) 자바 프로그램에서 바이트 코드의 컴파일 시간 단축시스템 및 방법
KR100512665B1 (ko) 가비지 수집기들을 추적하는 공간 한정된 마킹 구조
US6351794B1 (en) Computer resource management system
US6499095B1 (en) Machine-independent memory management system within a run-time environment
US6601235B1 (en) Method and apparatus for dynamically deoptimizing compiled activations
US8104034B2 (en) Purpose domain for in-kernel virtual machine for low overhead startup and low resource usage
US7225439B2 (en) Combining write-barriers within an inner loop with fixed step
US6757890B1 (en) Methods and apparatus for enabling local Java object allocation and collection
US6449626B1 (en) Reduced-cost remembered-set processing in a train-algorithm-based garbage collector
US6701520B1 (en) Preventing garbage collection of objects in object oriented computer programming languages
US5903899A (en) System and method for assisting exact Garbage collection by segregating the contents of a stack into sub stacks
US4991088A (en) Method for optimizing utilization of a cache memory
EP0700000A2 (en) System and method combining a global object identifier with a local object address in a single object pointer
US8429629B2 (en) In-kernel virtual machine for low overhead startup and low resource usage
US6112280A (en) Method and apparatus for distinct instruction pointer storage in a partitioned cache memory
US6604182B1 (en) Methods for managing memory in a run-time environment including activation and deactivation of objects
AU773940B2 (en) Method and apparatus for allocating stack slots
JPH09282167A (ja) メソッド起動方法及びメソッド起動制御装置
US6434685B1 (en) Paged memory management system within a run-time environment
US7406687B1 (en) Sharing runtime representation of software component methods across component loaders
US7620943B1 (en) Using class properties to segregate objects in a generation managed by the train algorithm
US7107430B2 (en) Mechanism to reduce the cost of forwarding pointer aliasing
US6681234B2 (en) Method and apparatus for storing long-lived objects in a virtual machine
US6581077B2 (en) Method and apparatus for storing short-lived objects in a virtual machine
US8176286B2 (en) Memory recycling in computer systems