JPH06214884A - キャッシュを使用する繰り返し処理のシステムおよび方法 - Google Patents

キャッシュを使用する繰り返し処理のシステムおよび方法

Info

Publication number
JPH06214884A
JPH06214884A JP5286264A JP28626493A JPH06214884A JP H06214884 A JPH06214884 A JP H06214884A JP 5286264 A JP5286264 A JP 5286264A JP 28626493 A JP28626493 A JP 28626493A JP H06214884 A JPH06214884 A JP H06214884A
Authority
JP
Japan
Prior art keywords
cache
data
indexing device
iteration
entries
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.)
Granted
Application number
JP5286264A
Other languages
English (en)
Other versions
JP2735782B2 (ja
Inventor
Rodney Birch
バーチ ロドニー
Keith Holmes
ホームズ キース
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
Publication of JPH06214884A publication Critical patent/JPH06214884A/ja
Application granted granted Critical
Publication of JP2735782B2 publication Critical patent/JP2735782B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

(57)【要約】 【目的】 キャッシュ、メインメモリ、繰り返し処理が
行われるプロセサを含むデータ処理システムおよび方法
を提供する。 【構成】 メインメモリからデータを取り出し、これを
１連のエントリーとしてキャッシュに記憶させる書き込
み手段と、エントリーをアドレスする読み込み手段から
なる。さらに繰り返し処理の始まりと終わりを見つける
ようにプログラムされたディテクタがあり、ディテクタ
が新しい繰り返し処理の始まりを示すと、コントローラ
がキャッシュを初期化しインデクシング・デバイスをセ
ットする。インデクシング・デバイスは、新しい繰り返
し処理の最初の繰り返しの中でデータを求めるプロセサ
の要求に応答し、キャッシュのどこにデータを記憶する
かを書き込み手段に伝え、また、それに続く繰り返し処
理で要求されたデータをキャッシュの適切なエントリー
でアクセスするように読み取り手段を制御する。

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明はデータリトリーバルに関
する。具体的には、繰り返し処理を行う中間記憶装置即
ちキャッシュメモリを使ってのデータ処理システムの中
でのデータリトリーバルに関するものである。
【０００２】
【従来の技術】今日のデータ処理システムは、今日必要
とされる適用業務（以下アプリケーション）が求めるス
ピードで処理するためには、データへのアクセスを速く
行わなければならない。記憶されるデータの量が増加す
るにつれ、その種のデータへのアクセスをいかに速く行
うかについて多くの研究がなされてきた。その結果、多
くのアプリケーションでは、中間記憶装置即ちキャッシ
ュは、データアクセスにかかる時間を減らす有効な手段
となることがわかった。
【０００３】米国特許4,426,682は、メインメモリへの
アクセスを減らすためにキャッシュメモリを使い、その
結果、プロセスの実行を早めるデータ処理システムを開
示している。この開示により解決しようとしている課題
は、キャッシュにあるデータは、同一のあるいは異なる
ユーザプログラムによって頻繁に変更を受け、そのた
め、１つのプロセス用に供するキャッシュ上のデータ
は、別のプロセス用には役に立たなくなるという課題で
ある。この開示はキャッシュの中の各メモリロケーショ
ンをリセットせずにキャッシュを洗浄し、いま、キャッ
シュ上にあるデータを使えなくする技術の改善を開示し
ており、これにより、プロセス時間を短縮するものであ
る。この開示は、データリトリーバルにかかる時間をで
きるだけ短くするという一般的な要望を反映している。
【０００４】キャッシュ技術については多くの研究が行
われ、何種類かの違ったタイプのキャッシュが開発され
たが、その中で広く知られているのが「最近使用された
頻度が最も低い」（least recently used：LRU）という
タイプである。通常、データ処理システムはキャッシュ
の外に大きなメインメモリを持ち、キャッシュはメイン
メモリよりもずっとサイズが小さい。あるプロセスがあ
るデータを必要とするとき、通常先ずキャッシュの中に
求めるデータが既に入っているか否かをサーチする。キ
ャッシュの方がサイズが小さいから、メインメモリをサ
ーチするより、キャッシュをサーチする速度の方が速
い。求めるデータがキャッシュにないとわかった時だ
け、データはメインメモリからリトリーブされる。これ
は、冗長な処理手順であるから、データは再び使われる
と予想して、キャッシュにもコピーされる。キャッシュ
が既にフルに使われている場合には、新しいデータを入
れるために、あるデータはキャッシュから消す必要があ
る。ＬＲＵタイプのキャッシュでは、キャッシュから消
されるデータとは、最近使用された頻度が最も低かった
データである。
【０００５】
【発明が解決しようとする課題】いろいろな経験からわ
かったことは、同じ情報は何回も続けて使われ、長めの
プログラムでも、数少ない限られたデータエントリーだ
けをアクセスすることがあるということである。このよ
うな場合、上に述べたようなキャッシュの使い方は、大
きなデータベース全体をサーチするより、キャッシュの
中の情報だけをサーチする方がずっと処理が速いので、
オペレーションの速度に大きな差が出る。
【０００６】キャッシュを効果的に使用する１つの具体
的な環境はオブジェクト指向プログラミング（object o
riented programming:以下ＯＯＰと略す）の手法で使っ
ているメッセージに基づいた環境である。ＯＯＰはソフ
トウェア開発に関する１つのアプローチで、必要な機能
をインプリメントするのに、「オブジェクト」に送る
「メッセージ」の形で行うものである。キャッシュが、
特に価値が大きいのはキャッシュの中に入れるメッセー
ジの数が少なく、ループの短いプログラムの場合であ
る。
【０００７】「オブジェクト」とはソフトウェアのパッ
ケージのことで、関連する手順（以下「方法」と呼ぶ）
とデータ（以下「変数」と呼ぶ）を含む。さらに、オブ
ジェクトは「オブジェクトクラス」としてまとめられ
る。オブジェクトクラスとは、オブジェクトのある１つ
のタイプ用の方法と変数を定義する型板（template）で
ある。あるオブジェクトクラスの中のオブジェクトは全
て形式と行動が同じだが、変数には異なるデータが入っ
ている。
【０００８】「メッセージ」とは１つのオブジェクトか
ら別のオブジェクトに送られる信号で、これを受けたオ
ブジェクトが「方法」を実行するように要求するもので
ある。つまり、メッセージがオブジェクト送られると、
要求された機能をインプリメントするために方法が発動
される。
【０００９】メッセージが発動される機能として変形さ
れるのには具体的には２つあり、それはコンパイルタイ
ムまたはランタイムである。そのどちらかで、性能即ち
スピードと融通性のどちらかのトレードオフが要る。メ
ッセージがコンパイルタイムで変えられていれば、コン
パイラーによって呼ばれる機能呼び出し即ちファンクシ
ョンコールになるから処理は速い。しかしこのために
は、オブジェクトのタイプとメッセージがコンパイルタ
イムに決まっている必要がある。メッセージがランタイ
ムで変えられる場合は、どの機能（ファンクション）を
呼ぶのかを決めるために、メッセージとオブジェクトを
使って内部のテーブルをサーチする。この後者のタイプ
の機能変形を「遅い」または「動的な」バインディング
即ちダイナミック・バインディングという。
【００１０】機能変形では、ダイナミック・バインディ
ングの方がコードモジュール間の依存度が少ないので、
コンパイルタイムのアプローチよりもはるかに融通性が
ある。コードモジュールとはプログラムのコンポーネン
トでそれぞれが手順とデータを含んでいる。通常あるプ
ログラムの異なる複数のモジュールは、互いに出来る限
り独立しているように作られる。ダイナミック・バイン
ディングでは、１つのモジュールに使われるオブジェク
トタイプが変更されても、これに接続している他のモジ
ュールは、ランタイムまで機能変形しないのでリコンパ
イルする必要がない。しかし、ダイナミック・バインデ
ィングは、機能呼び出し毎に、テーブルルックアップを
してオーバヘッドがかかるから、全体の性能には不利に
はたらく。特に繰り返し処理がある場合には能率が悪く
なるので、これは、機能変形としては非常に能率の悪い
やり方と一般的に考えられている。プログラミングのロ
ジックで、ある条件に到達するまでにプロセスを何回も
繰り返すというループを使うことは頻繁に起こることで
ある。
【００１１】ＯＯＰのシステムでは、オブジェクトにメ
ッセージを送るときのテーブルルックアップを減らす試
みとして、最適化手法を使うのが良いとされている。そ
のような手法の１つは、ハッシュ法又はハッシングのア
ルゴリズムの使用で、もう１つのアプローチはあるオブ
ジェクトクラスのオブジェクトに送られるメッセージの
最後のｎ個のメッセージをキャッシュに入れることであ
る。
【００１２】これらの手法は両方とも価値ある方法だ
が、以下に述べるコストとメリットのトレードオフが必
要である。ハッシングはこの分野でよく知られている方
法だからここでは詳しく述べない。キャッシュに入れる
方法の例として、あるオブジェクトクラスのオブジェク
トに送るメッセージの最後の５個をキャッシュに入れた
場合を考えてみよう。さらに異なるメッセージが送られ
ると、テーブルルックアップを始める前に、キャッシュ
の中の５個のエントリーを調べて使えるのか否かチェッ
クする必要がある。キャッシュに入れたメッセージの数
が増えれば、エントリーをチェックするオーバヘッドも
増え、キャッシュが元のテーブルと同じサイズに達する
と、この時点でキャッシュのメリットがなくなる。逆
に、キャッシュのサイズ即ちキャッシュに入れるエント
リーを少なくすれば、ある具体的なメッセージと既にキ
ャッシュにあるエントリーとがマッチする率が減り、こ
れもメリットを減らす。さらに、オブジェクトクラスに
関係なく、最後のｎ個のメッセージをキャッシュに入れ
ることも良いだろう。ここでも適切なキャッシュのサイ
ズを定めるためにトレードオフが必要になる。適切なキ
ャッシュサイズとどうキャッシュを使うかについては多
くの文献が扱ってきた。キャッシュサイズとキャッシュ
の使い方を誤ると、ある場合には、キャッシュを持たな
い同等のシステムよりも性能が悪くなることもありう
る。
【００１３】
【課題を解決する手段】本発明は特に繰り返し処理の起
こるＯＯＰのアプリケーションで、ダイナミック・バイ
ンディングで表されるような環境下で使う時に、データ
リトリーバルのスピードが上がるような、キャッシュを
使ったデータ処理のシステムを提供することを目的とす
るものである。
【００１４】本発明はキャッシュ、メインメモリ、繰り
返し処理が行われるプロセサを含むデータ処理システム
を提供する。このシステムは、メインメモリからデータ
を取り出し、このデータを１連の連続したエントリーと
してキャッシュに記憶させる書き込み手段と、エントリ
ーをアドレスする読み込み手段とからなり、さらに繰り
返し処理の始まりと終わりを見つけるようにプログラム
されたディテクタと、上記ディテクタに応答しキャッシ
ュとインデクシング・デバイスを制御するコントローラ
があり、ディテクタが新しい繰り返し処理の始まりを告
げた時、このコントローラがキャッシュを初期化しイン
デクシング・デバイスをセットし、インデクシング・デ
バイスは新しい繰り返し処理の最初の繰り返しの中でデ
ータを求める上記プロセサの要求に応答しキャッシュの
どこにデータを記憶するかを書き込み手段に伝え、さら
にインデクシング・デバイスは、それに続く繰り返し処
理で、要求されたデータをキャッシュの適切なエントリ
ーでアクセス出来るように読み取り手段を制御する諸ス
テップを特徴とするシステムである。
【００１５】また、本発明は、キャッシュ、メインメモ
リ、繰り返し処理が行われるプロセサからなるデータ処
理システムを作動する方法を提供する。この方法は、メ
インメモリからデータをリトリーブし上記データをキャ
ッシュの中に１連のエントリーとして記憶するステップ
と、エントリーをアドレスするステップとからなり、さ
らに、新しい繰り返し処理の始まりを見つけ、キャッシ
ュを初期化し、新しい繰り返し処理の最初の繰り返しの
中でデータを求めるプロセサの要求に応答し、データを
キャッシュの中に１連のエントリーとして記憶すること
を制御し、新しい繰り返し処理の終わりを見つけ、その
後の繰り返しの中で要求されたデータを適切なエントリ
ーでキャッシュをアクセスできるようにアドレスの仕方
を制御する諸ステップを特徴とする。
【００１６】
【実施例】図１は本発明を具体化したデータ処理システ
ム１０を示す。システムの中にプロセサ２０があり、ソ
フトウェア・アプリケーションを動かすのに使われ、繰
り返し処理３０の実行を含むことが出来る。システム１
０の中には、プロセサ２０の中で実行される繰り返し処
理の始まりと終わりを見つけるためのディテクタ４０が
ある。ディテクタはいくつかの形をとりうるが、１つの
形としては、プログラマがどこでループを始めるのかを
わかっていて、プログラムコードの流れの中に、ループ
の始まりを示すコードを作っておくのが望ましい。
【００１７】ディテクタがループの始まりを見つける
と、コントローラ５０にそれを伝え、コントローラ５０
はキャッシュ７０を初期化し、インデクシング・デバイ
ス６０をゼロにリセットする。キャッシュを初期化する
方法はこの後で述べる。
【００１８】繰り返し処理が始まると、インデクシング
・デバイス６０は具体的な方法を求めるプロセサ２０の
要求に応答する。この種の要求があると、インデクシン
グ・デバイス６０は書き込み手段９０にメインメモリ８
０の中の方法をルックアップさせる。さらにインデクシ
ング・デバイス６０は書き込み手段に対して、キャッシ
ュ７０の中の、インデクシング・デバイスによって定め
られたロケーションにその方法のアドレスを記憶するよ
うに指示する。このロケーションは、インデクシング・
デバイス６０のカウンタの中にその時保持されている数
値に従って選択される。インデクシング・デバイスはカ
ウンタをインクリメントして、キャッシュの別のロケー
ションに、書き込み手段９０によって呼び出された次の
方法の番地が記憶されるようにする。この手順はループ
の１回目の繰り返しの中でプロセサが方法を要求する度
に繰り返され、ディテクタ４０によってループの終わり
が見つかるまでキャッシュは大きくなる。
【００１９】ディテクタがループの終わりを見つけ、そ
れをコントローラ５０に伝えると、コントローラはイン
デクシング・デバイス６０をリセットする。ディテクタ
がループの終わりを認知する方法にはいくつかの方法が
ある。第１の方法はキャッシュの中に入れるエントリー
の最大の数を示す「最大キャッシュサイズ」パラメータ
によってループの長さをプログラムコードの中で規定す
る方法である。インデクシング・デバイスの中のカウン
タがこの数に達した時に、書き込み処理が終了しインデ
クシング・デバイス６０がリセットされる。もう１つ
は、ディテクタがそれぞれの方法要求のエレメントとル
ープの第１の方法要求の同様のエレメントとを比較す
る。具体化としては、これらのエレメントは送られたメ
ッセージとこれを受け取るオブジェクトタイプとを含ん
でいることが望ましい。エレメントがマッチした時、デ
ィテクタ４０は、繰り返し処理の最初のループが完了し
たと想定する。
【００２０】ループを繰り返して行く間に、プロセサ２
０によって、受け取るオブジェクトタイプと送られたメ
ッセージが、インデクシング・デバイスのその時のカウ
ンタの数値によって決められたキャッシュエントリーに
記憶されている同様のエレメントと比較される。これら
のエレメントは、インデクシング・デバイス６０の制御
のもとに読み取り手段１００によってキャッシュからリ
トリーブされたものである。
【００２１】これらのエレメントがマッチした場合、キ
ャッシュ７０にエレメントと一緒に記憶されているメッ
セージのアドレスが、読み取り手段１００によってキャ
ッシュからリトリーブされ、そのメッセージをメインメ
モリ８０の中から直接見つけるためにプロセサによって
使われる。インデクシング・デバイスはカウンタを１つ
インクリメントして、キャッシュの次のエントリーが次
の比較のために使われる。エレメントがマッチしなけれ
ば、方法の番地を見つけるためにメインメモリ８０を直
接ルックアップする手順がとられる。
【００２２】この方法をとると、最初の繰り返しでキャ
ッシュを準備すると、キャッシュの中に記憶された情報
が使えるかどうかを定めるのに１回の比較だけで済む利
点があり、システム性能が大きく向上する。
【００２３】次に、図２で、キャッシュの取り扱いにつ
いて詳しく述べる。図２は、ＯＯＰの繰り返し処理にお
いてメッセージがオブジェクトクラスに送られた時の、
本発明でのデータ処理システムで遂行される主なステッ
プを示すフローチャートである。ステップ２００におい
て、メッセージがオブジェクトによって受け取られ、そ
のオブジェクトがそのオブジェクトクラス用の方法を実
行するように指示する。
【００２４】次にステップ２１０で、プロセサは、い
ま、キャッシュが書き込み手段９０によって満ちつつあ
るか否かを判断する。もしそうであれば、インデクシン
グ・デバイス６０は書き込み手段に対して、メインメモ
リのテーブルからその方法を探すように指示する。この
プロセスが図２のステップ２２０である。
【００２５】その方法が見つかると、インデクシング・
デバイス６０の制御の下で、書き込み手段９０がその方
法のアドレスをキャッシュのエントリーとして記憶する
（ステップ２３０）。ステップ２４０でインデクシング
・デバイスのカウンタがインクリメントされ、ステップ
２５０でその方法が実行される。
【００２６】ステップ２１０でキャッシュがまだ満ちて
いないと判断されれば、いまの方法要求と、インデクシ
ング・デバイス６０のカウンタの指すキャッシュロケー
ションに記憶されているエレメントとの比較が行われ
る。上述したが、この比較は、「受領するオブジェクト
タイプ」とプロセサ２０によって送られた「送られたメ
ッセージ」を、キャッシュエントリーに記憶されている
同様のエレメントとを比較するものである。この比較は
図２のステップ２６０に示すステップで、現在のインデ
クシング・デバイスのカウンタでのキャッシュエントリ
ーが「ヒット」つまりマッチするか否かを判断するもの
である。
【００２７】キャッシュエントリーが現在の方法要求と
マッチすれば、即ちヒットすれば、カウンタのインデッ
クスはインクリメントされ（ステップ２７０）、キャッ
シュエントリーのアドレスによって指定された方法が実
行される（ステップ２５０）。
【００２８】しかし、ステップ２６０で、現在のキャッ
シュエントリーのエレメントが、プロセサ２０の要求す
る方法のエレメントにマッチしない場合には、その要求
された方法を見つけるためにメインメモリ８０に直接ル
ックアップが行われ（ステップ２８０）、インデクシン
グ・デバイス６０のカウンタの中のインデックスはリセ
ットされて（ステップ２９０）、その方法が実行される
（ステップ２５０）。
【００２９】ある意味で、図２は簡略化してある。即ち
キャッシュは既に初期化され、キャッシングは選択され
たものと想定してある。さらに簡略化するために、「バ
ウンダリーチェキング」ルーチンが図２に示していな
い。特にキャッシュが満ちつつあるかというステップ２
１０はキャッシュが満ちたことを図示していない。この
条件は、ディテクタ４０によってループの終わりが見つ
かったか、または、キャッシュサイズの最大値が到達さ
れたかの条件で起こる。また、「インデックスをインク
リメント」（ステップ２４０とステップ２７０）は、こ
のステップに関連するロジック即ち"if index = CACHE
SIZE: index=0" を省略してある。
【００３０】図２の説明を終了したところで、具体例を
次に考えてみる。ループの殆どは、一定のパターンに従
い、１つの繰り返しで送られるメッセージの順序が同じ
である。１つの客先オブジェクトを生成し初期化するた
めに送られる次のようなメッセージのログを考えてみよ
う。（プログラムは翻訳せず、以下同様。） 受け取るオブジェクトタイプ 送られたメッセージ ーーーーーーーーーーーーー ーーーーーーーーー CustomerClass new customer setUniqueID customer setFirstName customer setSecondName customer setHouseAddress customer setStreetAddress customer setCityAddress このログは次のようなスードコードから作られる。 CASE : CUSTーLIST /* Fill Customer List :/ SEND INIT_CACHE(TRUE) /*Tell the cache to start*/ while ( i++ <NUM_CUSTS) SEND NEW(i) return CASE : NEW(i) SEND SetUniqueID(i) SEND SetFirstName(i) SEND SetSecondName(i) ..... etc. 典型的なケースでは、オブジェクトタイプに送られるメ
ッセージの１組のセットは、オペレーションを繰り返す
度に同一のものである。客先リストを作成（例えばデー
タベースからの情報を使って）する上記の例で、上記の
メッセージのセットを客先データの１個のセットに対し
て１回繰り返すループがある。
【００３１】本発明の望ましい形として、以下のステッ
プを使ってメッセージとオブジェクトタイプがキャッシ
ュに入れられる。 （１）ループの始まりを見つける。上述したように、プ
ログラマがどこでループが始まるかがわかっているな
ら、プログラマはルックアップ・ロジックに、あるメッ
セージからキャッシュに入れるように指示できる。これ
により、ロジックからループの繰り返しが分離できる。
ループの始まりから、送られたメッセージの数を数える
カウンタ（以下ループ・インデックス）は、それぞれの
繰り返しの始めで初期化され、１つメッセージが送られ
る度にインクリメントされる。 （２）１回めの繰り返しの時に、キャッシュ・テーブル
は、ループ・インデックス、受け取るオブジェクトタイ
プ、送られたメッセージ、方法のアドレスによって初期
化される。方法のアドレスは受け取るオブジェクトタイ
プと送られたメッセージに基づいて通常のテーブルルッ
クアップ手順で探す。客先リストを作成し初期化するル
ープの最初の繰り返しが終わると、キャッシュ・テーブ
ルは以下のようになる。 ループ 受け取る 送られた 方法の インデックス オブジェクトタイプ メッセージ アドレス ーーーーーー ーーーーーーーーー ーーーーーー ーーーーー 0 CustomerClass new ..... 1 customer setUniqueID ..... 2 customer setFirstName ..... 3 customer setSecondName ..... 4 customer setHouseAddress ..... 5 customer setStreetAddress ..... 6 customer setCityAddress ..... （" .... "はメインメモリ８０の中の方法のアドレスを表す。） （３）２回目およびそれに続く繰り返しで、受け取るオ
ブジェクトタイプと送られたメッセージが、ループ・イ
ンデックスの指すロケーションに記憶されている値と比
較される。マッチすればサーチは不要であり、方法のア
ドレスは判明している。マッチしなければ、方法のアド
レスを解決するために通常のルックアップ手順が使われ
る。
【００３２】上述からわかるように、ひとたびキャッシ
ュ・テーブルが初期化され作成されると、キャッシュに
記憶された情報が使えるか否かを決めるのに、ただ１回
の比較をすればよい。サーチの結果多くのメッセージが
記憶されても、最も本当らしいものしか使われないか
ら、ループが大きくなるとこの問題は重大な問題にな
る。例えば１つの繰り返しに１００個のメッセージがあ
るループでは、送られたメッセージの最後の１００個を
そのループの結果として記憶しなければならない。標準
的なキャッシュでは、ヒットか否かを決めるために記憶
された１００個のメッセージ全てを比較しなければなら
ない。これでは、標準的なテーブルサーチと同じか、よ
り悪い。上述した方法を使えば、繰り返し処理の条件下
では、キャッシュをループの行動に追随させ、１回のル
ープで１００％のヒット率を達成できるように作動さ
せ、従って、１回の比較で済ますことができる。これ
は、この処理の仕方で作動するキャッシュに、簡単なイ
ンデックスを使用することで達成できる。
【００３３】ＯＯＰ環境での、キャッシュを使わないデ
ータリトリーバルの簡単な例を次に示す。 ここでは、LOOKUP は不経済である。
【００３４】LOOKUPコマンドの結果はメッセージとクラ
スをマッチさせる方法機能がサーチされたメインメモリ
に記憶される。このメッセージ機能がランされその値が
リターンされる。
【００３５】これに較べて、本発明の具体化であるキャ
ッシュでの処理は次のようになる。 ｛ static CacheTable = AllocateCacheTable ( MAX_CACHE_ROWS ); static Index; if message = INIT_CACHE｛ Index = 0; if parm = TRUE｛ CacheON = TRUE; /* can have other parms - see variations */ ｝ else if CacheON = FALSE; ｝ if CacheOn = TRUE ｛ /*if Caching */ if message = CacheTable ( index++) -> message / if a hit */ return run (CacheTable (index -1) ->function /*run the function*/ else /* not a hit */ if CacheTable (index)->message == EMPTY ｛/*table not populated*/ function = LOOKUP (message, class) CacheTable(index) ->message = MESSAGE /* populate it*/ CacheTable(index ++)->function = function return run (function) ｝ else index=0; /* see asynchronous messages */ ｝ return(run( LOOKUP (message, class))) /* Cache was not on or failed*/ ｝ 上の例は説明を簡明にするために細かいことを省いてあ
る。例えば処理の結果ヒットがなければ処理はゼロにリ
セットし、ゼロでマッチがあるかどうかチェックすべき
である。即ちキャッシュ・テーブルを満たし続けないよ
うに、ループはリスタートするべきである。
【００３６】上記の具体例は効果的で、ループの繰り返
しを行うシステムで大きく性能向上に寄与する。しか
し、当業者には明らかなように、ある条件の下では、プ
ログラマはキャッシュを使用するのに使う情報にアクセ
スしたい場合がある。この修正はINIT_CACHEで初期化で
きる。修正する例を次に述べる。
【００３７】（１）非同期メッセージの送付。非同期メ
ッセージ送付とは処理するべきメッセージを、今実行し
ているタスクが終わってから処理するために記憶する方
法である。非同期メッセージ送付を行うには、キャッシ
ュの中のエントリーにマッチがなければインデックスを
リセットしなければならない。
【００３８】WinPostMsgを使って例えばIBM OS/2 プレ
ゼンテーション・マネジャの環境で、非同期メッセージ
送付を使ってループをコーディングすることもできる。
WinPostMsgは、非同期メッセージ送付ができるプレゼン
テーション・マネジャでアプリケーションを書く人が使
える機能である。この種のコーディングを使うとループ
が実行されている間に他のメッセージを処理することが
できる。以下のスードコードを参照されたい。 POSTはメッセージを非同期的に扱うための機能である。
この結果キャッシュは先に述べたのと同じ、下記の形を
した客先情報を持っている。 ループ 受け取る 送られた 方法の インデックス オブジェクトタイプ メッセージ アドレス ーーーーーー ーーーーーーーーー ーーーーーー ーーーーー 0 CustomerClass new ..... 1 customer setUniqueID ..... 2 customer setFirstName ..... 3 customer setSecondName ..... 4 customer setHouseAddress ..... 5 customer setStreetAddress ..... 6 customer setCityAddress ..... キャッシュに入っている別のメッセージを処理するため
にインタラプトされることはあっても、キャッシング自
体は動いている。
【００３９】（２）ループの中で繰り返されるメッセー
ジ。最初のメッセージを繰り返すループには、プログラ
マは、繰り返しがどう行われようと次に来る一定の数の
メッセージをキャッシュに入れるように指示するため
に、CACHE_SIZEパラメータを与えることができる。これ
は、キャッシュがテーブルを満たしつつあっても、現在
のエントリーが最初のエントリーにマッチするか否かチ
ックしなくても済むことを意味する。次の例を参照され
たい。 DO GET DO EVEN DO GET DO ODD プログラマがCACHE_SIZEパラメータを４にセットしてい
ればDO GETを繰り返しても問題ない。さもなければ、キ
ャッシュは２の長さで７５％のヒット率しか得られな
い。
【００４０】（３）不完全なループ。次の例は上で述べ
た一般的なシナリオにはうまく合わない。 システムがSetUniqueID でキャッシュに入れ始めると、
キャッシュ・テーブルのサイズは、たった２つのメッセ
ージが送られた時にMAX_CHARに達してしまう。このよう
な場合には、「積み重ね」(tiered approach)の方法を
使い、ネストするコールの深さでインデックスをインク
リメントする方法がある。SetUniqueIDを反復レベル１
でキャッシュに入れ、get_next_charをレベル２でキャ
ッシュに入れる。これによって、キャッシュのサイズを
反復の最大の大きさにできる。小さなキャッシュのサイ
ズでも１００％のヒットが得られる。
【００４１】このようなネストされた手続き呼び出しで
この種の完全な構造を作ることは滅多にない。例えばSe
tUniqueIDがメッセージを送り、そのメッセージがまた
メッセージを送るという例である。しかし、それぞれの
反復レベルでキャッシュのタイプやサイズに制限はな
い。どのレベルで、例えば最後のｎタイプでも上述のイ
ンデックスの方法でも、キャッシュを使ってよい。
【００４２】この方法は、各レベルのキャッシュサイズ
が反復レベルの数をかけた大きさで効果的に使えるの
で、反復の多いシステムでは極めて有効な方法である。
例えば５つの反復レベルを使い、それぞれ４つのメッセ
ージを使うなら２０即ち５Ｘ４のメッセージが実際にキ
ャッシュに入る。しかしそれぞれのキャッシュのサーチ
にはたった４つが使われる。プログラマはどのキャッシ
ングの仕方を混ぜて使うかを示すパラメータを使ってキ
ャッシュを使うタイプを決めることができる。
【００４３】上記に述べたことを組み合わせて、プログ
ラマが調整できる仕方で、キャッシュを満たすことがで
きる。深さが４でネストされたサイズが２の標準的キャ
ッシュを、ネストされた深さ１０のキャッシュとして使
えるようINIT_CACHEで定義できる。この範囲で、新しい
キャッシュ・テーブルを動的にとるために、もう１つの
INIT_CACHEを送って、もう１つのインデックスされたキ
ャッシュを使うことも可能である。
【００４４】キャッシュの使用の別の応用として、繰り
返し処理用に要求されたデータをキャッシュに逐次的に
記憶させるように、インデクシング・デバイスがずらす
（オフセット）ための詳細を書き込み手段に提供する方
法がある。応用としてさらに、読み込み手段がキャッシ
ュをアクセスする予め定められたアドレスを持ってい
て、上述のオフセットするための詳細が、予め定められ
たアドレスを修正し、読み込み手段が正確な位置で特定
のエントリーを読めるようにすることができる。
【００４５】
【発明の効果】本発明は、繰り返し処理の多いデータリ
トリーバルのアプリケーションにおいて、特にオブジェ
クト指向プログラミングの環境下でキャッシュを使用す
るシステムと方法を提供するもので、その効果として、
システムの性能を大きく向上させることができる。
【図面の簡単な説明】
【図１】本発明を具体化したデータ処理システムを示す
ブロックダイアグラム。
【図２】本発明を具体化したデータ処理システムでキャ
ッシュをどう作動させるかを示すフローチャート。
【符号の説明】
２０ プロセサ ３０ 繰り返し処理 ４０ ディテクタ ５０ コントローラ ６０ インデクシング・デバイス ７０ キャッシュ ８０ メインメモリ ９０ 書き込み手段 １００ 読み取り手段
───────────────────────────────────────────────────── フロントページの続き (72)発明者 キース ホームズ アイルランド国 ダブリン16 ラスファー ナム マーレイコート 28

Claims (7)

    【特許請求の範囲】
  1. 【請求項１】 キャッシュ、メインメモリ、繰り返し処
    理が行われるプロセサからなるデータ処理システムで、
    上記システムは、 メインメモリからデータをリトリーブし、上記データを
    キャッシュの中に１連のエントリーとして記憶する書き
    込み手段と、 特定のエントリーをアドレスする読み取り手段とからな
    り、 繰り返し処理の始まりと終わりを見つけるようにプログ
    ラムされたディテクタと、 上記ディテクタが新しい繰り返し処理の始まりを示した
    時に、上記ディテクタに応答しキャッシュを初期化しイ
    ンデクシング・デバイスをセットするコントローラと、 上記インデクシング・デバイスは、上記新しい繰り返し
    処理の最初の繰り返しの中で、データを求める上記プロ
    セサの要求に応答し、上記データを上記キャッシュのど
    こに記憶するかを上記書き込み手段に伝えることと、 上記インデクシング・デバイスは、上記繰り返し処理の
    その後の繰り返しの中で、適切なエントリーで要求され
    たデータに対してキャッシュをアクセスできるよう上記
    読み取り手段を制御することと、 を含むことを特徴とするデータ処理システム。
  2. 【請求項２】 上記インデクシング・デバイスが、繰り
    返し処理用に要求されたデータをキャッシュに逐次的に
    記憶するように、上記書き込み手段に対してオフセット
    するための詳細を提供する請求項１に記載のシステム。
  3. 【請求項３】 上記読み込み手段が上記キャッシュをア
    クセスする予め定められたアドレスを持ち、上記オフセ
    ットするための詳細が上記予め定められたアドレスを修
    正し、上記読み込み手段が正確な位置で特定のエントリ
    ーを読めるようにした請求項２に記載のシステム。
  4. 【請求項４】 上記ディテクタが、上記繰り返し処理の
    中に含まれたインディケータの存在を検知することによ
    り上記繰り返し処理の始まりを検知する請求項１に記載
    のシステム。
  5. 【請求項５】 上記ディテクタが、上記キャッシュに記
    憶されたエントリーの数が予め定められたキャッシュサ
    イズの最大値と等しいと判断することによって、繰り返
    し処理の終わりを検知する請求項１に記載のシステム。
  6. 【請求項６】 上記インデクシング・デバイスの制御の
    下でエントリーが異なる反復レベルで書き込まれるよう
    にキャッシュがネスト構造を持つ請求項１に記載のシス
    テム。
  7. 【請求項７】 キャッシュ、メインメモリ、繰り返し処
    理が行われるプロセサからなるデータ処理システムを作
    動する方法で、上記方法は、 メインメモリからデータをリトリーブし、上記データを
    キャッシュの中に１連のエントリーとして記憶するステ
    ップと、 エントリーをアドレスするステップからなり、 新しい繰り返し処理の始まりを見つけ、 キャッシュを初期化し、 上記新しい繰り返し処理の最初の繰り返しの中でデータ
    を求める上記プロセサの要求に応答し、上記データを上
    記キャッシュの中に１連のエントリーとして記憶するこ
    とを制御し、 新しい繰り返し処理の終わりを見つけ、 繰り返し処理のその後の繰り返しの中で、適切なエント
    リーで要求されたデータに対してキャッシュをアクセス
    できるように上記アドレスするステップを制御するステ
    ップ、 を含むことを特徴とする方法。
JP5286264A 1992-12-02 1993-10-22 キャッシュを使用する繰り返し処理のシステムおよび方法 Expired - Fee Related JP2735782B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB9225209.7 1992-12-02
GB9225209A GB2273179A (en) 1992-12-02 1992-12-02 Cache indexing in interative processes.

Publications (2)

Publication Number Publication Date
JPH06214884A true JPH06214884A (ja) 1994-08-05
JP2735782B2 JP2735782B2 (ja) 1998-04-02

Family

ID=10726009

Family Applications (1)

Application Number Title Priority Date Filing Date
JP5286264A Expired - Fee Related JP2735782B2 (ja) 1992-12-02 1993-10-22 キャッシュを使用する繰り返し処理のシステムおよび方法

Country Status (4)

Country Link
US (1) US5519845A (ja)
EP (1) EP0600649A3 (ja)
JP (1) JP2735782B2 (ja)
GB (1) GB2273179A (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5911068A (en) * 1995-03-30 1999-06-08 Microsoft Corporation Container independent control architecture
US6047338A (en) * 1997-07-30 2000-04-04 Ncr Corporation System for transferring a data directly from/to an address space of a calling program upon the calling program invoking a high performance interface for computer networks
JP2003186855A (ja) * 2001-12-20 2003-07-04 Fujitsu Ltd 型照合によるオブジェクト連携システムおよび方法
US7031977B2 (en) * 2002-02-28 2006-04-18 Plumtree Software, Inc. Efficiently storing indented threads in a threaded discussion application
US7529768B2 (en) * 2005-12-08 2009-05-05 International Business Machines Corporation Determining which objects to place in a container based on relationships of the objects

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4426682A (en) * 1981-05-22 1984-01-17 Harris Corporation Fast cache flush mechanism
US4633387A (en) * 1983-02-25 1986-12-30 International Business Machines Corporation Load balancing in a multiunit system
US4885680A (en) * 1986-07-25 1989-12-05 International Business Machines Corporation Method and apparatus for efficiently handling temporarily cacheable data
US4896264A (en) * 1986-09-08 1990-01-23 American Telephone And Telegraph Company Microprocess with selective cache memory
US5133061A (en) * 1987-10-29 1992-07-21 International Business Machines Corporation Mechanism for improving the randomization of cache accesses utilizing abit-matrix multiplication permutation of cache addresses
JPH01154261A (ja) * 1987-12-11 1989-06-16 Toshiba Corp 情報処理装置
IT1216086B (it) * 1988-03-15 1990-02-22 Honeywell Bull Spa Memoria tampone ad indirizzamento pseudo virtuale.
US5226146A (en) * 1988-10-28 1993-07-06 Hewlett-Packard Company Duplicate tag store purge queue
US5155824A (en) * 1989-05-15 1992-10-13 Motorola, Inc. System for transferring selected data words between main memory and cache with multiple data words and multiple dirty bits for each address
US5226133A (en) * 1989-12-01 1993-07-06 Silicon Graphics, Inc. Two-level translation look-aside buffer using partial addresses for enhanced speed
EP0446534A3 (en) * 1990-03-16 1992-08-05 John Fluke Mfg. Co., Inc. Method of functionally testing cache tag rams in limited-access processor systems
US5247653A (en) * 1990-08-17 1993-09-21 Seagate Technology, Inc. Adaptive segment control and method for simulating a multi-segment cache
JPH0799508B2 (ja) * 1990-10-15 1995-10-25 インターナショナル・ビジネス・マシーンズ・コーポレイション キャッシュ記憶機構を動的に区分する方法およびキャッシュ記憶機構システム
JPH04178731A (ja) * 1990-11-13 1992-06-25 Hitachi Ltd オブジェクト指向処理系におけるメソッド・キャッシュ情報の再利用方式
MX9200970A (es) * 1991-03-05 1993-08-01 Zitel Corp Memoria de deposito.
US5367653A (en) * 1991-12-26 1994-11-22 International Business Machines Corporation Reconfigurable multi-way associative cache memory

Also Published As

Publication number Publication date
EP0600649A3 (en) 1995-02-01
US5519845A (en) 1996-05-21
GB9225209D0 (en) 1993-01-20
EP0600649A2 (en) 1994-06-08
JP2735782B2 (ja) 1998-04-02
GB2273179A (en) 1994-06-08

Similar Documents

Publication Publication Date Title
US5555392A (en) Method and apparatus for a line based non-blocking data cache
US6115802A (en) Efficient hash table for use in multi-threaded environments
US6779187B1 (en) Method and system for dynamic interception of function calls to dynamic link libraries into a windowed operating system
KR100512665B1 (ko) 가비지 수집기들을 추적하는 공간 한정된 마킹 구조
US6052697A (en) Reorganization of collisions in a hash bucket of a hash table to improve system performance
US6782454B1 (en) System and method for pre-fetching for pointer linked data structures
US5546559A (en) Cache reuse control system having reuse information field in each cache entry to indicate whether data in the particular entry has higher or lower probability of reuse
US5991847A (en) Data pattern caching for speeding up write operations
CN100365577C (zh) 永久高速缓存装置和方法
US7493464B2 (en) Sparse matrix
JPH10254756A (ja) リファレンスされたオブジェクトを管理するための３状態リファレンスの使用
US6640285B1 (en) Method and apparatus for improving the efficiency of cache memories using stored activity measures
US6668307B1 (en) System and method for a software controlled cache
US6714991B1 (en) Method and apparatus for implementing fast subclass and subtype checks
US5659739A (en) Skip list data structure enhancements
TW200428210A (en) Memory management
US7406687B1 (en) Sharing runtime representation of software component methods across component loaders
US6687807B1 (en) Method for apparatus for prefetching linked data structures
US20050240716A1 (en) System and method for interfacing index based and interator based application programming interfaces
US8185693B2 (en) Cache-line aware collection for runtime environments
JP2735782B2 (ja) キャッシュを使用する繰り返し処理のシステムおよび方法
US20100268921A1 (en) Data collection prefetch device and methods thereof
US11853755B2 (en) Atomic range compare and modify operations
US6260045B1 (en) Method and apparatus for optimizing interface dispatching in an object-oriented programming environment
US7178139B2 (en) Executable file system for an embedded computer

Legal Events

Date Code Title Description
LAPS Cancellation because of no payment of annual fees