JPH07271667A - 情報管理方式 - Google Patents

Abstract

(57)【要約】 【目的】 アドレスリロケーション方式による仮想記憶
管理をしているシステムにおいても、管理できる情報量
の制限を無くし、情報検索の効率を低下させないように
することを目的とする。 【構成】 ステップＳ１で検索対象の情報のノードの先
頭絶対アドレスを収得する。次いで、ステップＳ２でこ
の収得した先頭絶対アドレスを用い、マップウインドウ
Ａに現在マッピングされているブロック内に検索対象の
情報のノードがあるかどうか判断する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、アドレスリロケーシ
ョン方式でアクセスする拡張メモリ方式を採用するＣＰ
Ｕを用いた情報管理方式に関する。

【０００２】

【従来の技術】従来の情報管理方式に一般に利用されて
いるツリー構造を用いた方式がある。その一例として、
特開平２−１８８８７２号公報に記載されている情報検
索方式がある。この方式は、まず、記憶されている管理
対象となる各情報に関連する情報に対して、各情報にそ
の情報に関連する他の情報に対するポインタを付随させ
ることによりネットワーク構造の管理ツリー状態となっ
たデータベースを実現する。

【０００３】そして、それぞれの情報と１対１に対応し
た情報間の接続関係を記述したポインタを有するインデ
ックスによりなる管理サブツリーを、高速にアクセス
（接続）可能なメモリ上に別に用意し、この管理サブツ
リーをインデックスとして管理ツリー状態のデータベー
スの検索を行うようにしている。このようにすること
で、データベースが記憶されている記録媒体に対するア
クセス回数を減らすことが可能となり、情報検索の高効
率を実現している。特に、大容量の記憶容量を持ちアク
セスが低速な記憶媒体に大量の情報（データベース）が
記憶されている場合に有効である。

【０００４】

【発明が解決しようとする課題】ここで、管理サブツリ
ーを用いたツリー構造の情報管理方式を、アドレスリロ
ケーション方式による仮想記憶管理をしているシステム
に対応させようとすると、管理ツリー状態のデータベー
スとこのインデックスとなる管理サブツリーを配置する
メモリ（主メモリ）に容量制限がある場合、対象とする
情報量に制限が発生するという問題があった。

【０００５】アドレスリロケーション方式は、セグメン
ト方式を用いて主メモリにてアクセスするＣＰＵにおい
て、その主メモリのサイズに例えば１Ｍバイトという制
限がある場合、これ以上の記憶領域を得るために、論理
的な記憶装置である仮想記憶（仮想空間）を用いるよう
にしたものである。例えば、仮想空間の所定の領域を１
６Ｋバイト毎のブロックに分け、主メモリ上の所定の１
６Ｋバイトの領域に、それらのブロックをページングに
より切り替えて当てはめるように（マッピング）して用
いる。

【０００６】ここで、アクセスのためのアドレスの変換
は、以下に示すように行う。まず、切り替えて当てはめ
るためのアドレスの変換のための変換テーブルを用意
し、主メモリの１Ｍバイトにアクセスするための２０ビ
ットの物理アドレスの上位６ビットにより、拡張アドレ
スが２⁶ ＝６４エントリある変換テーブルにアクセスす
る。そして、６４エントリあるどれかの１０ビットの拡
張アドレスに置き換えれば、物理アドレスの下位１４ビ
ットはそのままなので、アクセスするために合計２４ビ
ットのアドレスを用いることができる。

【０００７】すなわち、物理アドレスの下位１４ビット
でアクセスできる２¹⁴＝１６Ｋバイトの空間が、変換テ
ーブルによる６４ページ（エントリ）のページングによ
り２²⁴＝１６Ｍバイトの空間に広がって、これを用いる
ことができるようになる。このように仮想記憶を用いる
ことで、１６Ｍバイトまでメモリ空間を広げることがで
きる。

【０００８】以上説明したように、アドレスリロケーシ
ョン方式では、ＣＰＵが直接アクセスできる主メモリの
記憶容量に制限があるシステムにおいては、使用可能な
メモリ容量の制限を受けないという特徴がある。ここ
で、このようなシステムにおいて、前述した情報検索方
式を用いようとする場合、比較的容量の小さい管理サブ
ツリーを主メモリ上に配置し、容量の大きい管理ツリー
状態のデータベースを論理的な仮想空間である拡張メモ
リ上へ配置して行う方式が考えられる。

【０００９】しかし、管理サブツリーは格納したい情報
量とともに増加することになり、これを配置する主メモ
リはメモリ容量の使用制限があり、従って、管理できる
情報量にも制限ができてしまうという問題があった。ま
た、管理しようとする情報量の増加にともない、管理サ
ブツリーが大きくなるので、主メモリを管理サブツリー
で占有してしまうようになり、他のアプリケーションの
動作のための場所が減少してしまうという問題もあっ
た。

【００１０】また、アドレスリロケーション方式では、
前述したように、ページの切り換えを行うことで、仮想
空間内にメモリの拡張を行っている。このため、主メモ
リ上の管理サブツリーから仮想空間にある管理ツリー状
態のデータベースの親情報へのアクセスや、その親情報
から各子情報へのアクセスの移動を行う度に、主メモ
リ，拡張メモリ空間の対応切り換えを発生することにな
り、情報検索の効率を低下させるという問題があった。

【００１１】この発明は、以上のような問題点を解消す
るためになされたものであり、アドレスリロケーション
方式による仮想記憶管理をしているシステムにおいて
も、管理できる情報量の制限を無くし、情報検索の効率
を低下させないようにすることを目的とする。

【００１２】

【課題を解決するための手段】この発明の情報管理方式
は、拡張窓領域に張り付けられたブロックの拡張メモリ
上における先頭絶対アドレスが保持するマッピング値格
納領域を主メモリに配置し、登録，削除，変更などを行
う検索動作対象となる各情報を２分木による管理ツリー
構造としたデータベースを拡張メモリに格納し、絶対ア
ドレス収得手段により検索動作対象の情報の拡張メモリ
における絶対アドレスを収得し、存在判断手段を用い、
絶対アドレス収得手段により収得された絶対アドレス
と、マッピング値格納領域に格納されている先頭絶対ア
ドレスとを比較することで、拡張窓領域に張り付けられ
ているブロック内における検索動作対象の情報の存在・
不在を判断し、張り付け切り替え手段により、存在判断
手段により不在と判断されたとき、拡張窓領域に張り付
けるブロックを検索動作対象の情報が存在するブロック
への切り替えを行うことを特徴とする。

【００１３】

【作用】主メモリの拡張窓領域に現在張り付けられてい
るブロック内に検索動作対象の情報が存在する場合は、
この拡張窓領域に対するブロックの切り替え動作は行わ
れない。

【００１４】

【実施例】以下この発明の１実施例を図を参照して説明
する。この発明を、ネットワークを管理するための管理
情報の管理に用いた場合について説明する。また、この
実施例においては、アドレスリロケーション方式による
仮想記憶管理をしているシステムとして、マイクロプロ
セッサ（ＣＰＵ）と１Ｍバイトの容量の主メモリと、１
６Ｍバイトの容量の仮想空間である拡張メモリとを備え
たものについて説明する。

【００１５】ネットワークでは、ネットワークに接続す
るためのＩＤや、接続しているノード自身の動作・非動
作状態の情報など、接続している各ノード毎にネットワ
ークを管理するための管理情報を保持しておく必要があ
る。この発明においては、まず、この管理情報を２分木
アルゴリズムを採用する管理ツリー状態のデータベース
とするところに特徴がある。

【００１６】２分木アルゴリズムを採用する管理ツリー
状態では、まずデータベース化するそれぞれの管理情報
にインデックスとして番号を付け、図１に示すように、
２分木状態の管理ツリーとして管理する。図１に示すよ
うに、２分木アルゴリズムでは、１つの親情報の下に来
る子情報は２つあり、そして例えば左側に親情報より大
きい数字のインデックス番号の子情報が配置され、右側
には親より小さな数字のインデックス番号の子情報が配
置されるようにするものである。なお、親の左側に配置
される子が親より小さな数字のインデックス番号であっ
てもよい。

【００１７】このような管理ツリー状態で管理されてい
るデータベースにおいて、番号「８」がインデックス番
号として付いている情報を検索する場合、まず、管理ツ
リーの先頭の番号と検索対象のインデックス番号「８」
とが比較される。検索対象のインデックス番号「８」は
先頭情報のインデックス番号「１０」より小さいので、
次に右側の子情報のインデックス番号「５」と比較され
る。

【００１８】ここで、検索対象のインデックス番号
「８」はこの「５」とは異なり、かつ大きいので、今度
は左の子情報のインデックス番号「６」と比較される。
検索対象のインデックス番号「８」はこの「６」とは異
なり、かつ大きいので、この下の左の子情報のインデッ
クス番号「７」と比較される。そして、やはり検索対象
のインデックス番号「８」は、この「７」とは異なりか
つ大きいので、この下の左の子情報のインデックス番号
「８」と比較され、今度は一致するので、ここの情報が
取り出される。

【００１９】このように、２分木アルゴリズムにより構
築された管理ツリー状態のデータベースでは、子情報へ
移動する際の分岐している枝の選択が極めて簡単に行わ
れるので、検索時間があまりかからないという特徴を持
つ。そして、この発明においては、２分木の管理ツリー
状態のデータベースを拡張メモリ上に配置するようにし
たものである。なお、図１において「＊」は、２分木ア
ルゴリズムにより、情報が配置されない所である。

【００２０】そして、この実施例においては、以下に示
すように主メモリ、拡張メモリを構成したものである。
まず、図２に示すように、ＣＰＵ１から直接アクセス可
能な主メモリ２には、１６Ｋバイトの容量の２つのマッ
プウインドウＡ２１ａ，Ｂ２１ｂ（拡張窓領域）と、こ
のマッピング値が保持されているマッピング値格納領域
Ａ２２ａ，Ｂ２２ｂが配置されている。

【００２１】また、ＣＰＵ１がアドレスリロケーション
方式でアクセスする拡張メモリ３には、マップウインド
ウＡ２１ａ，Ｂ２１ｂに張り付ける１６Ｋバイト毎のブ
ロックＡ３１ａ〜Ｚ３１ｚが配置され、これらに２分木
の管理ツリー状態のデータベースが配置されていく。そ
して、主メモリ２には、拡張メモリ３におけるブロック
Ａ３１ａ〜Ｚ３１ｚの配置状態や情報格納状況などの情
報が格納されているブロック情報領域２３も配置されて
いる。

【００２２】そして、拡張メモリ３には、図３に示すよ
うに、図１に示した２分木アルゴリズムにより形成され
る管理ツリー状態のデータベースが、インデックス番号
を付けられて格納されている。例えば、拡張メモリ３の
ブロックＡ３１ａには、インデックス番号「１０」が付
けられたルート情報と、インデックス番号「５」が付け
られたルート情報の右につながる子情報と、インデック
ス番号「１１」が付けられたルート情報の左につながる
子情報と、インデックス番号「４」が付けられたインデ
ックス番号「５」の右側につながる子情報が格納されて
いる。

【００２３】以下、図４のフローチャートを用いて動作
を説明する。まず、検索したい管理情報のインデックス
番号「８」が入力されると、始めに、ルート情報が格納
されているブロックＡ３１ａが、マップウインドウＡ２
１ａ，Ｂ２１ｂのどちらかにマッピングされているかど
うかを確認する。ブロックＡ３１ａがどちらかにマッピ
ングされている場合は、そのマップウインドウを用い、
ブロックＡ３１ａがどちらにもマッピングされていない
場合は、ブロックＡ３１ａをマップウインドウＡ２１ａ
にマッピングする。

【００２４】以上のことにより、ＣＰＵ１は拡張メモリ
３のブロックＡ３１ａにあるデータとアクセスすること
が可能になり、まず、ルート情報の格納されているノー
ドの絶対アドレスが、ＣＰＵ１が認識できる論理アドレ
スに変換され、このルート情報のノードにＣＰＵ１がア
クセスする。そして、ルート情報であるインデックス番
号「１０」が、検索対象の管理情報のインデックス番号
「８」と比較される。ここで、「８」は「１０」とは異
なり小さいので、次には、図１に示した２分木の管理ツ
リーに従い、右側の子情報のインデックス番号「５」と
比較されることになる。

【００２５】インデックス番号が付けられている各ノー
ドは、図５に示すように、管理情報本来のインデックス
と、格納している管理情報の状態と、２分木アルゴリズ
ムにおけるインデックス番号とが格納され、加えて、２
分木の分木先である２つの子情報それぞれの拡張メモリ
３におけるアドレス情報が格納されている。たとえば、
インデックス番号「１０」のノードには、分木先の子情
報としてインデックス番号「５」のノードの絶対アドレ
スが「右」として格納され、インデックス番号「１１」
の絶対アドレスが「左」として格納されている。

【００２６】従って、上述の場合、インデックス番号
「１０」との比較の後には、インデックス番号「５」の
ノードがある絶対アドレスを収得して（ステップＳ
１）、このアドレスにアクセスしに行くことになる。イ
ンデックス番号「５」のノードがある絶対アドレスが収
得されると、まず、マップウインドウＡ２１ａに張り付
けられているブロックＡ３１ａ内にこのノードがあるか
どうかが確認される（ステップＳ２）。

【００２７】この確認は、インデックス番号「５」のノ
ードの絶対アドレスの上位１０ビットと、ブロックＡ３
１ａの先頭絶対アドレスの上位１０ビットが同じかどう
かで判断される。拡張メモリ３における絶対アドレスは
２４ビットで表され、この上位１０ビットをとった下位
１４ビットで、２¹⁴＝１６Ｋバイト分の絶対アドレスを
示すことができる。すなわち、ブロックＡ３１ａ内では
どこであっても、その絶対アドレスの上位１０ビットは
同じものとなる。

【００２８】ここで、インデックス番号「５」のノード
は、ブロックＡ３１ａ内にあるので、マップウインドウ
Ａ２１ａの新たなマッピングは行わず、このままマップ
ウインドウＡ２１ａを用いる（ステップＳ３）。そし
て、インデックス番号「５」のノードの絶対アドレス
が、ＣＰＵ１の認識できる論理アドレスに変換され（ス
テップＳ４）、検索対象の管理情報のインデックス番号
「８」との比較がなされる。

【００２９】今度は、「８」が「５」と異なりかつ大き
いので、インデックス番号「５」につながる左の子情報
のノードの絶対アドレスが収得される（ステップＳ
１）。そして、前述と同様にして、そのノードがマップ
ウインドウＡ２１ａにマッピングされているブロックＡ
３１ａ内にあるかどうかが判断される（ステップＳ
２）。今度は、このインデックス番号「６」のノードが
ブロックＡ３１ａ内に無いので、もう一方のマップウイ
ンドウＢ２１ｂにマッピングされているブロック内に、
このインデックス番号「６」のノードがあるかどうかが
確認される（ステップＳ５）。

【００３０】ここでは、マップウインドウＢ２１ｂにマ
ッピングされているブロック内にもインデックス番号
「６」のノードが無いので、ついで、マップウインドウ
Ａ２１ａとマップウインドウＢ２１ｂとで、前回マッピ
ングが行われた以外のマップウインドウが選ばれる（ス
テップＳ７）。マップウインドウＡ２１ａは、前回のマ
ッピングが行われたマップウインドウなので、今回はマ
ップウインドウＢ２１ｂが選択され（ステップＳ７）、
ここにインデックス番号「６」のノードがあるブロック
Ｂ３１ｂがマッピングされる（ステップＳ８）。

【００３１】このマッピングは、前述したように、イン
デックス番号「６」のノードの絶対アドレスの上位１０
ビットの部分と同一のブロックを選択することで行われ
る。そして、今度はブロックＢ３１ｂがマッピングされ
たマップウインドウＢ２１ｂにあるインデックス番号
「６」のノードの絶対アドレスがＣＰＵ１が認識可能な
論理アドレスに変換され、このノードのデータが取り込
まれインデックス番号「８」との比較がなされる。

【００３２】上述と同様にして、インデックス番号
「６」の次は、マップウインドウＢ２１ｂのマッピング
状態をそのまま保持し（ステップＳ１，Ｓ２，Ｓ５，Ｓ
６）、インデックス番号「７」のノードを検証する。そ
して、今度はマップウインドウＡ２１ａにブロックＣ３
１ｃをマッピングし（ステップＳ１，Ｓ２，Ｓ５，Ｓ
７，Ｓ８）、目的とするインデックス番号「８」のノー
ドにたどり着き、この情報を取り出す。

【００３３】以上、検索におけるこの発明によるマッピ
ング動作を説明したが、管理情報の管理における登録や
削除における拡張メモリへのアクセスにおいても、ブロ
ック情報領域２３を用い、同様にマッピング動作を行
う。ここで、登録や、削除においては、上述した拡張メ
モリ３におけるブロックＡ３１ａ〜Ｚ３１ｚの配置状態
や情報格納状況などの情報が格納されているブロック情
報領域２３の内容の参照や変更が行われる。

【００３４】なお、上記実施例では、マップウインドウ
とマッピング値格納領域とを２つ用意するようにした
が、これは１つでも良い。しかし、それらを２つ用意す
ることで、２分木の管理ツリー状態のデータベースにお
ける２つの管理情報に同時に修正を加えたい場合など、
この２つの管理情報のノードが同一のブロック内に存在
しなくても、それぞれが存在するブロックを２つのマッ
プウインドウにマッピングしておけるので、マップウイ
ンドウの切り替えを最小限にとどめられる。

【００３５】

【発明の効果】以上説明したように、この発明によれ
ば、データベースを２分木アルゴリズムに基づく管理ツ
リー状態にし、これを拡張メモリ上に配置し、主メモリ
に設けたマップウインドウに拡張メモリ上に形成したブ
ロックを切り替えてマッピングするようにした。そし
て、マッピングされているブロック内にアクセスしたい
情報があるときには、マッピングの切り替えを行わない
ようにした。このことにより、主メモリの容量をあまり
減らすこと無く、また、複雑な検索アルゴリズムを用い
ること無く、拡張メモリに配置した情報の管理ができる
という効果がある。

【図面の簡単な説明】

【図１】 この発明の実施例における２分木状態の管理
ツリーを示す説明図である。

【図２】 メモリ管理の状態を説明するためのメモリブ
ロック図である。

【図３】 メモリ管理の状態を説明するためのメモリブ
ロック図である。

【図４】 この発明におけるマッピング動作の説明のた
めのフローチャートである。

【図５】 ２分木の管理ツリー状態のデータベースの１
つのノードの状態を示すブロック図である。

【符号の説明】

１…ＣＰＵ、２…主メモリ、３…拡張メモリ、２１ａ…
マップウインドウＡ、２１ｂ…マップウインドウＡ、２
２ａ…マッピング値格納領域Ａ、２２ｂ…マッピング値
格納領域Ｂ、２３…ブロック情報領域、３１ａ〜ｂ…ブ
ロックＡ〜Ｚ。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 １クロックで処理できるビット数以上の
   アドレスを有する主メモリに対して、この絶対アドレス
   を直接認識できる論理アドレスに変換することで前記主
   メモリにアクセスし、前記主メモリ上の任意のところに
   配置した拡張窓領域に、この拡張窓領域と同一の大きさ
   に区切られた拡張メモリ上のブロックを、自身が有する
   変換テーブルを用いて切り替えて張り付けることで、前
   記ＣＰＵが直接スアクセスできる主メモリ以上のメモリ
   容量を前記拡張メモリ上に確保する、アドレスリロケー
   ション方式を用いた拡張メモリ管理を行うＣＰＵを有し
   た情報管理装置において、 前記拡張窓領域に張り付けられたブロックの前記拡張メ
   モリ上における先頭絶対アドレスが保持するマッピング
   値格納領域を前記主メモリに配置し、 登録，削除，変更などを行う検索動作対象となる各情報
   を２分木による管理ツリー構造としたデータベースを前
   記拡張メモリに格納し、 絶対アドレス収得手段により検索動作対象の情報の前記
   拡張メモリにおける絶対アドレスを収得し、 存在判断手段を用い、前記絶対アドレス収得手段により
   収得された絶対アドレスと、前記マッピング値格納領域
   に格納されている先頭絶対アドレスとを比較すること
   で、前記拡張窓領域に張り付けられているブロック内に
   おける前記検索動作対象の情報の存在・不在を判断し、 張り付け切り替え手段により、前記存在判断手段により
   不在と判断されたとき、前記拡張窓領域に張り付けるブ
   ロックを前記検索動作対象の情報が存在するブロックへ
   の切り替えを行うことを特徴とする情報管理方式。
2. 【請求項２】 請求項１記載の情報管理方式において、 前記拡張メモリにおける前記ブロックの配置状態や、前
   記データベースの状況などの情報が格納されているブロ
   ック情報領域を、前記主メモリに配置することを特徴と
   する情報管理方式。
3. 【請求項３】 請求項１または２記載の情報管理方式に
   おいて、 前記拡張窓領域と前記マッピング値格納領域とをそれぞ
   れ２つ配置するようにしたことを特徴とする情報管理方
   式。