JP4036257B2 - 共有ライブラリ生成方法およびシステム - Google Patents
共有ライブラリ生成方法およびシステム Download PDFInfo
- Publication number
- JP4036257B2 JP4036257B2 JP2002114223A JP2002114223A JP4036257B2 JP 4036257 B2 JP4036257 B2 JP 4036257B2 JP 2002114223 A JP2002114223 A JP 2002114223A JP 2002114223 A JP2002114223 A JP 2002114223A JP 4036257 B2 JP4036257 B2 JP 4036257B2
- Authority
- JP
- Japan
- Prior art keywords
- modules
- module
- memory
- objects
- linked
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理に係り、複数のロードモジュールから成るプログラムシステムにおいて、ロードモジュールの起動パターン、すなわち各時点で起動されているロードモジュールの種類や起動数に依存せず、プログラムシステム全体が消費するメモリの総計を最小にする技術に関する。
【０００２】
【従来の技術】
従来技術では、ライブラリに含めるべきオブジェクトを、参照関係ではなく機能の類似性で分け、類似機能を提供するオブジェクト群をまとめてひとつのアーカイブライブラリとして提供していた。
また、複数のロードモジュールが同じライブラリをリンクする場合、オブジェクトが多重にメモリ空間を占有してメモリ消費量が増大するのを防ぐために、共有ライブラリが使用されているが、共有ライブラリもアーカイブライブラリと同じオブジェクトから構成されていた。
すなわち、各共有ライブラリが含むオブジェクト集合は、その計算機システムの提供時点で静的に決まっており、ユーザーが作成する実行可能モジュールがどのライブラリ内のどのオブジェクトを参照するかというオブジェクト間の参照関係は、ライブラリを構成する際のオブジェクト集合の選択に影響を与えることはなかった。
【０００３】
【発明が解決しようとする課題】
一般に、共有ライブラリは複数のオブジェクトを結合したものであり、共有ライブラリ単位で仮想メモリ上にローディングされる。このため、共有ライブラリ中のただひとつの関数のみが使用される場合でも、その共有ライブラリ全体がローディングされ仮想メモリ空間を占有することとなり、ライブラリ中で実際には使用されないオブジェクトが無駄なメモリを占有していた。
【０００４】
この状況を図３を用いて説明する。
図３は、三個のロードモジュールＸ，Ｙ，Ｚを構成するオブジェクト間の参照関係を表している。
図３左側の網掛けしてあるオブジェクトは、ロードモジュールの実行開始点を含むという意味で特別なオブジェクトであり、これをメインオブジェクトと呼んで区別する。
各オブジェクトから出ている矢印は、矢印が出ているオブジェクト内から、矢印が指し示すオブジェクトに存在する関数への呼び出しあるいはデータの参照があることを意味する。
共有ライブラリ31および32は、それが含むオブジェクトをまとめて単一の共有ライブラリを構成していることを表す。
この場合、オブジェクトxを含むロードモジュールXには、オブジェクトa,b,c,fおよびオブジェクトp,q,sが含まれる。したがって、ロードモジュールXを実行する場合、前記オブジェクト群のみを仮想空間上にローディングすれば必要十分である。
しかし、ローディングは共有ライブラリ単位で行われるため、共有ライブラリ31と32が仮想空間上にローディングされる。その結果、実際には呼ばれることのない無駄なオブジェクトd,eおよびrも同時にローディングされ、仮想記憶の利用効率が低下する。
【０００５】
これは、限られた実装メモリ量の範囲で可能な限り多くのプロセスを同時に処理することを求められる基幹系サーバーシステムにおいて特に問題となっていた。
基幹系サーバーシステムにおいては、システム上で動作する可能性のあるロードモジュールの種類はあらかじめ決定されており、一般の計算機システムに見られるようにユーザーが任意の時点で新たなロードモジュールを作成し実行することはない。
本発明の目的は、このロードモジュールの決定性に着目して、ロードモジュールがどのようなタイミングでいくつ起動されても、常に必要なオブジェクトのみが仮想空間上に存在するようなオブジェクト群の分割を求め、その分割に基づき共有ライブラリを生成しロードモジュールを再リンクすることで、メモリの使用効率を高めることにある。
【０００６】
【課題を解決するための手段】
上記の問題を解決するために、本発明は、メモリにコンパイラが生成した個々のオブジェクトモジュール(オブジェクト)と実行可能な複数のモジュール(ロードモジュール)を格納し、
処理装置において、前記個々のオブジェクトがどの前記ロードモジュールにリンクされるかを解析し、個々のオブジェクトと各ロードモジュール間の参照関係を取得し、該取得した参照関係に基づき、前記ロードモジュールにリンクする全てのオブジェクトについて、オブジェクトを参照するロードモジュールの集合をキーとして全てのオブジェクトを分類してオブジェクトをグループ化し、該グループ化により得られたオブジェクトの各グループを基にメモリ空間への配置単位とする共有ライブラリを生成する。
【０００７】
【発明の実施の形態】
図１を用いてまず実施形態の概要を説明する。
オブジェクト関係解析部では、ロードモジュールを入力対象および解析対象とし、入力した各ロードモジュールに含まれるすべてのオブジェクトを調べて、オブジェクトをキーとしてそのオブジェクトが含まれるロードモジュール(群)を検索可能な、オブジェクト−ロードモジュール集合対応表を作成・出力する。
オブジェクト分類部では、オブジェクト−ロードモジュール集合対応表を入力して、処理対象とするすべてのオブジェクトについて、各オブジェクトが属するロードモジュールの集合が等しいもの同士をグループ化し、その結果をロードモジュール集合−オブジェクト集合対応表として出力する。
ライブラリ生成部では、ロードモジュール集合−オブジェクト集合対応表を入力し、オブジェクト分類部で判明した各々のオブジェクトグループ毎に、そこに含まれるすべてのオブジェクトをリンクして単一の共有ライブラリを生成し出力する。
最後に、共有ライブラリ化されずに残ったオブジェクト(これにはメインオブジェクトも含む)と、前記ライブラリ生成部により生成した共有ライブラリを入力として、リンケージエディタを実行し、個々のロードモジュールを作成する。
【０００８】
図２は本発明が適用される計算機システムの概略構成を示す。
２１はＣＰＵ、２２は入出力装置、２３はメモリ、２４はディスクである。
メモリ２３はコンパイラが生成した個々のオブジェクトモジュール(オブジェクト)と実行可能な複数のモジュール(ロードモジュール)を格納し、ＣＰＵ２１はメモリ２３に格納されたオブジェクトとロードモジュールを基に共有ライブラリを生成する処理を行い、ディスク２４は生成した共有ライブラリを格納する。
【０００９】
次に、本実施例の詳細について説明する。
最初に、前提とするロードモジュールの構成について説明する。
本実施例では、図３に示すオブジェクト参照関係を持つ３個のロードモジュールが最初に存在するものとする。
図４は、それら３個のロードモジュールをそれぞれ静的にリンクした場合に、各ロードモジュールに含まれるオブジェクトを示す。
本発明の適用にあたっては、実際には図４のように静的にリンクされたすべてのロードモジュールが存在すれば十分であり、図３のように各オブジェクト間のすべての参照関係を明らかにしておく必要はない。
次に、本実施例を通じて使用する集合の表現方法を説明する。
計算機上で集合を表現する方法は複数知られているが、ここではビットベクトルを用いる。
ビットベクトルとは、ある固定長サイズの整数型データに含まれる各々のビット位置を各要素に対応させることにより、各ビットのオン(１)・オフ(０)を、当該要素がその集合に含まれる・含まれないという二状態として表現する方法である。
ビット位置を要素に一対一に対応させるため、集合を表す整数型データに含まれるビット数(ビット幅)は、少なくともその集合に含まれうる全要素数以上でなければならない。これを図８を用いて説明する。
図８はa,b,cを要素とする集合をビットベクトルで表したものである。
左側の“含まれる要素”として示された集合状態の列は、a,b,cの三要素で表しうるすべての集合パターンを表現しており、中央のa,b,cの各列は左側の各集合にそれぞれの要素が含まれるかどうかを有／無で表現しており、右側の二進表現の列は「有」を１とし、「無」を０として、各集合をそれぞれ二進数に置換したものを表現している。
例えば、図８において、左側の“含まれる要素”として示された集合パターンが“b,c”の場合、中央のa,b,cの各列は“無，有，有”となり、右側の２進表現の列は“0b011”となる。
このビットベクトルで表現した集合に対する各種の操作方法を図９に示す。
図９におけるandおよびorは、ビットごとのANDおよびOR演算を意味する。このビットベクトル表現により、計算機上で扱いやすい形で集合を表現できる。
【００１０】
次に、本実施例の動作について説明する。
まず、図１０を用いてオブジェクト関係解析部の動作を説明する。
カウンタとして、モジュールカウンタMCとオブジェクトカウンタOCを設ける。
最初にステップ1001において、モジュールカウンタMCおよびオブジェクトカウンタOCをゼロに初期設定する。そして、オブジェクト名称を格納する配列ObjectNameおよび、ロードモジュール集合を格納する配列LoadSetの領域を確保する。
両方の配列の要素数はともに、本発明を適用するすべてのロードモジュール(本実施例では、X,Y,Zの3個)に含まれるオブジェクトの総数(本実施例では、a,b,c,d,e,f,p,q,r,x,y,zの13個)とする。
次に、ステップ1002に移り、最初のロードモジュールをオープンする。ロードモジュールのオープン順序は任意であるが、ここではX,Y,Zの順にオープンするものと仮定する。したがって最初のロードモジュールとしてXをオープンし、モジュールカウンタMCを1にする。
ステップ1003では、現在オープンしているロードモジュール（この場合、ロードモジュールX）に含まれるオブジェクトの中からオブジェクト名称をひとつ取り出す。オブジェクト名称の取り出し順序も任意であるが、ここでは図４の記載のとおり上から下に順に取り出されるものと仮定する。したがって、ここでは最初にオブジェクトxの名称が取り出される。
【００１１】
ステップ1004では、取り出したオブジェクト名称xをキーとして配列ObjectNameを検索しステップ1005の判定へ移る。
この時点では配列ObjectNameにはまだひとつも名称が登録されていないため、オブジェクト名称xは見つからず、ステップ1005の判定はNoとなりステップ1007へ行く。
ステップ1007では、OCを0から1に増やし、ObjectName[OC]に名称文字列xを格納する。格納した名称文字列xにはインデックスを付ける。このインデックスは図５のオブジェクト−ロードモジュール集合対応表のオブジェクト番号に相当する。
また、ステップ1005の判定の結果、Yesであればステップ1006に進み、ステップ1006では配列中で見つかった要素のインデックスをオブジェクト番号(OC)とし、ステップ1007に進む。
ステップ1008では、配列要素LoadSet[1]の最下位からMC番目(ここでは1番目)のビットをオンにする。ここでは、モジュールカウンタMCの値は1であるので、最下位から1番目のビットをオンにする。この操作は、オブジェクトxが属するロードモジュールの集合にXを要素として追加したことを意味する。
判定1009では、オープンしたロードモジュールXにはまだオブジェクトが残っているので、ステップ1003に戻って、次のオブジェクトa以降の処理を続ける。
ロードモジュールX内のすべてのオブジェクトを処理し終えた場合は、判定1009の結果がNoとなり、ステップ1010に移ってオープンしていたロードモジュールXをクローズする。
ステップ1011の判定では、まだYとZのロードモジュールが残っているので、結果はYesとなり、ステップ1002に移って処理を続ける。
すべてのロードモジュールを処理し終えた場合は、判定1011の結果がNoとなり、オブジェクト関係解析部が終了する。
【００１２】
図５のオブジェクト−ロードモジュール集合対応表が示すとおり、この時点で配列LoadSetの各要素は、各オブジェクトがどのロードモジュールに属するかをビットベクトルで表している。オブジェクト関係解析部における出現順序に従って、各オブジェクトには1から連続する整数値が割り振られており、それが図５のオブジェクト番号である。
図５を用いて任意のオブジェクトに対してそれを含むロードモジュール集合を求めるには以下のようにする。
まず、例えば、名称文字列dをキーにして配列ObjectNameを検索する。その結果、ObjectName[10]の内容がdであることが判明し、このインデックス10がオブジェクトdのオブジェクト番号であることがわかる。次に、この10をインデックスとして配列LoadSetを参照すると、LoadSet[10]=(110)２である。これは集合のビットベクトル表現であり、各ビットは最下位から順にX,Y,Zというロードモジュールを意味しているので、結局、オブジェクトdはYとZに含まれることがわかる。
以上のとおり、本例では、オブジェクト関係解析部により、オブジェクト−ロードモジュール集合対応表がこの時点でLoadSet配列の形で求められたことになる。
【００１３】
次に、図１１を用いてオブジェクト分類部の動作を説明する。
最初にステップ1101において、配列ObjectSetを確保する。この配列は、ロードモジュールの包含パターンごとに、そのようなパターンを持つオブジェクトをまとめて集合表現するものであるので、ロードモジュール数をαとすると、確保すべき配列要素数は2αとなり、α＝3とすれば、配列要素数は8となり、オブジェクトの総数は13個なので、要素型は最低でも13ビット以上の幅を持つ整数型である必要がある。また、オブジェクトカウンタOCはゼロに初期化しておく。
ステップ1102において、オブジェクトカウンタOCを0から1に増やす。
ステップ1103において、OCが1であるので、オブジェクト番号(OC)＝1におけるLoadSet[OC]は(001)２であり、その１０進値は1であるので、LoadSet[OC]の１０進値が1であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち1番目のビットを1にする。その結果、ObjectSetの内容は(0000000000001)になる。
判定1104では、オブジェクト総数が13であるのに対し、OCは現在1であるので、結果はNoとなり、ステップ1103へ戻って順次オブジェクトを処理する。
【００１４】
ステップ1103においてOC＝2の場合には、オブジェクト番号(OC)＝2におけるLoadSet[OC]は(101)２であり、その１０進値は5であるので、LoadSet[OC]の１０進値が5であるエントリのObjectSet（ObjectSet[LoadSet[OC]]）の最下位から数えてOC番目のビット、すなわち2番目のビットを1にする。その結果、ObjectSetの内容は(0000000000010)になる。
OC＝3の場合には、オブジェクト番号(OC)＝3におけるLoadSet[OC]は(011)２であり、その１０進値は3であるので、LoadSet[OC]の１０進値が3であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち3番目のビットを1にする。その結果、ObjectSetの内容は(0000000000100)になる。
OC＝4の場合には、オブジェクト番号(OC)＝4におけるLoadSet[OC]は(011)２であり、その１０進値は3であるので、LoadSet[OC]の１０進値が3であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち4番目のビットを1にする。その結果、ObjectSetの内容は(0000000001100)になる。
OC＝5の場合には、オブジェクト番号(OC)＝5におけるLoadSet[OC]は(101)２であり、その１０進値は5であるので、LoadSet[OC]の１０進値が5であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち5番目のビットを1にする。その結果、ObjectSetの内容は(0000000010010)になる。
以下、同様にして、オブジェクト番号(OC)＝13までの処理をする。
【００１５】
図５によれば最大の番号を持つオブジェクトはzであるので、ｚの処理を終えた後、判定1104がYesとなり、オブジェクト分類部を終了する。
図６が示すとおり、この時点で配列ObjectSetの各要素は、ロードモジュールのそれぞれの包含パターンを持つオブジェクトの集合を表している。
例えば、モジュールXおよびYのみに含まれるオブジェクト集合を求めることを考えると、集合{X,Y}に対応するビットベクトルは(011)２である。これは10進表現で3であるので、ObjectSet[3]を参照すると、内容は(0000001101100)２である。 これを最下位ビットから順に、オブジェクト番号順に並べたオブジェクトx,a,b,c,f,p,q,s,y,d,e,r,zに対応付けて見ると、結局、XとYのみに含まれるオブジェクトは、b,c,p,qであることがわかる。
以上のとおり、本例では、オブジェクト分類部により、ロードモジュール集合−オブジェクト集合対応表がこの時点でObjectSet配列の形で求められたことになる。
【００１６】
次に、図１２を用いてライブラリ生成部の動作を説明する。
最初にステップ1201において、単一の共有ライブラリを作成するために一括してリンケージエディタに渡すオブジェクト群の名称文字列を格納する文字配列LinkBufを確保し、空文字列を初期設定する。また、オブジェクト集合カウンタOSCを設け、これをゼロに初期化しておく。
ロードモジュールの総数をαとした場合、OSCは1〜2α-1（α＝3の場合、1〜7）まで1ずつ変移するカウンタであり、各々のカウント値は、それを2進表現したビットベクトル（OSC＝3の場合、(011)２）が各ロードモジュールの包含パターンを意味するものである。
ステップ1202において、OSCを0から1に増やし、オブジェクトカウンタOCをゼロに初期設定する。
ステップ1203において、OCを0から1に増やす。
判定1204において、ObjectSet[1]は(0000000000001)２であり、最下位ビットがオンなので、結果はYesとなり判定1205へ行く。
判定1205では、ObjectName[1]はxであり、これはメインオブジェクトなので、結果はYesとなりステップ1207へ行く。
ステップ1207では、ObjectSet[1]を1ビット右シフトした結果、すべてのビットがゼロとなる。
ステップ1208の結果はYesなので、ステップ1209へいく。
ステップ1209では、LinkBufに何も格納されていないので、リンケージエディタは起動されず、ObjectSet[1]に対応する共有ライブラリは作成されない。
ステップ1210では、OSCは1であり、配列ObjectSetの最大インデックスは7(すなわち2３-1：3はロードモジュールの総数)なので、結果はNoとなりステップ1202へ行く。
上記をOSCが7になるまで繰り返すと、判定1210がYesとなり、ライブラリ生成部は終了する。この時点で、生成されている共有ライブラリは、図６が示すように、オブジェクトb,c,p,qから成るもの、オブジェクトa,f,sから成るもの、および、オブジェクトd,e,rから成るものの３個である。
例えば、OSC＝3の場合、OC＝3,4,6,7のときにステップ1206においてObjectName[OC]が示すオブジェクト名称がLinkBufに追加書きで出力される。
【００１７】
最後に、リンケージエディタでロードモジュールを作成する。ロードモジュールXを作成する場合は、オブジェクトx、ロードモジュールYを作成する場合はオブジェクトy、ロードモジュールZを作成する場合は、オブジェクトzと、構成したすべての共有ライブラリを引数に与えてリンケージエディタをそれぞれ起動すればよい。
【００１８】
以上のようにして生成したロードモジュールと各共有ライブラリの参照関係を示したものが図７である。
71、72、および73が前記ライブラリ生成部により生成された共有ライブラリである。図７における矢印の意味は、左側のメインモジュールを実行する場合は、そこから出ているすべての矢印が指す右側の共有ライブラリをローディングする必要があるという意味である。
図７が示すように、ロードモジュールXを実行する場合は、共有ライブラリ71と73、ロードモジュールYを実行する場合は共有ライブラリ71と72、ロードモジュールZを実行する場合は、共有ライブラリ72と73をそれぞれローディングすれば、必要十分なオブジェクトが仮想空間上に存在する。
さらに、無駄なオブジェクトがローディングされないという特長は、ロードモジュールの組み合わせには依存せず、いかなるローディングパターンにおいても維持される。
【００１９】
【発明の効果】
以上述べたように、本発明によれば、特に、実行されるロードモジュールがあらかじめ決定されているシステムにおいて、オブジェクトが含まれるロードモジュール集合をキーにしてオブジェクトをグループ化および共有ライブラリ化することにより、無駄なオブジェクトをローディングすることなく、計算機システムの仮想記憶の利用効率を常に最大にすることができる。
【図面の簡単な説明】
【図１】実施形態の概要を説明するための図である。
【図２】計算機システムの構成を示す図である。
【図３】実施例で用いるオブジェクト間の参照関係を示す図である。
【図４】ロードモジュールのオブジェクト構成を示す図である。
【図５】オブジェクト−ロードモジュール集合対応表を示す図である。
【図６】ロードモジュール集合−オブジェクト集合対応表を示す図である。
【図７】生成したライブラリを示す図である。
【図８】ビットベクトルによる集合表現を示す図である。
【図９】ビットベクトル集合への操作を示す図である。
【図１０】オブジェクト関係解析部のフローを示す図である。
【図１１】オブジェクト分類部のフローを示す図である。
【図１２】ライブラリ生成部のフローを示す図である。
【符号の説明】
２１ ＣＰＵ
２２ 入出力装置
２３ メモリ
２４ ディスク
【発明の属する技術分野】
本発明は、情報処理に係り、複数のロードモジュールから成るプログラムシステムにおいて、ロードモジュールの起動パターン、すなわち各時点で起動されているロードモジュールの種類や起動数に依存せず、プログラムシステム全体が消費するメモリの総計を最小にする技術に関する。
【０００２】
【従来の技術】
従来技術では、ライブラリに含めるべきオブジェクトを、参照関係ではなく機能の類似性で分け、類似機能を提供するオブジェクト群をまとめてひとつのアーカイブライブラリとして提供していた。
また、複数のロードモジュールが同じライブラリをリンクする場合、オブジェクトが多重にメモリ空間を占有してメモリ消費量が増大するのを防ぐために、共有ライブラリが使用されているが、共有ライブラリもアーカイブライブラリと同じオブジェクトから構成されていた。
すなわち、各共有ライブラリが含むオブジェクト集合は、その計算機システムの提供時点で静的に決まっており、ユーザーが作成する実行可能モジュールがどのライブラリ内のどのオブジェクトを参照するかというオブジェクト間の参照関係は、ライブラリを構成する際のオブジェクト集合の選択に影響を与えることはなかった。
【０００３】
【発明が解決しようとする課題】
一般に、共有ライブラリは複数のオブジェクトを結合したものであり、共有ライブラリ単位で仮想メモリ上にローディングされる。このため、共有ライブラリ中のただひとつの関数のみが使用される場合でも、その共有ライブラリ全体がローディングされ仮想メモリ空間を占有することとなり、ライブラリ中で実際には使用されないオブジェクトが無駄なメモリを占有していた。
【０００４】
この状況を図３を用いて説明する。
図３は、三個のロードモジュールＸ，Ｙ，Ｚを構成するオブジェクト間の参照関係を表している。
図３左側の網掛けしてあるオブジェクトは、ロードモジュールの実行開始点を含むという意味で特別なオブジェクトであり、これをメインオブジェクトと呼んで区別する。
各オブジェクトから出ている矢印は、矢印が出ているオブジェクト内から、矢印が指し示すオブジェクトに存在する関数への呼び出しあるいはデータの参照があることを意味する。
共有ライブラリ31および32は、それが含むオブジェクトをまとめて単一の共有ライブラリを構成していることを表す。
この場合、オブジェクトxを含むロードモジュールXには、オブジェクトa,b,c,fおよびオブジェクトp,q,sが含まれる。したがって、ロードモジュールXを実行する場合、前記オブジェクト群のみを仮想空間上にローディングすれば必要十分である。
しかし、ローディングは共有ライブラリ単位で行われるため、共有ライブラリ31と32が仮想空間上にローディングされる。その結果、実際には呼ばれることのない無駄なオブジェクトd,eおよびrも同時にローディングされ、仮想記憶の利用効率が低下する。
【０００５】
これは、限られた実装メモリ量の範囲で可能な限り多くのプロセスを同時に処理することを求められる基幹系サーバーシステムにおいて特に問題となっていた。
基幹系サーバーシステムにおいては、システム上で動作する可能性のあるロードモジュールの種類はあらかじめ決定されており、一般の計算機システムに見られるようにユーザーが任意の時点で新たなロードモジュールを作成し実行することはない。
本発明の目的は、このロードモジュールの決定性に着目して、ロードモジュールがどのようなタイミングでいくつ起動されても、常に必要なオブジェクトのみが仮想空間上に存在するようなオブジェクト群の分割を求め、その分割に基づき共有ライブラリを生成しロードモジュールを再リンクすることで、メモリの使用効率を高めることにある。
【０００６】
【課題を解決するための手段】
上記の問題を解決するために、本発明は、メモリにコンパイラが生成した個々のオブジェクトモジュール(オブジェクト)と実行可能な複数のモジュール(ロードモジュール)を格納し、
処理装置において、前記個々のオブジェクトがどの前記ロードモジュールにリンクされるかを解析し、個々のオブジェクトと各ロードモジュール間の参照関係を取得し、該取得した参照関係に基づき、前記ロードモジュールにリンクする全てのオブジェクトについて、オブジェクトを参照するロードモジュールの集合をキーとして全てのオブジェクトを分類してオブジェクトをグループ化し、該グループ化により得られたオブジェクトの各グループを基にメモリ空間への配置単位とする共有ライブラリを生成する。
【０００７】
【発明の実施の形態】
図１を用いてまず実施形態の概要を説明する。
オブジェクト関係解析部では、ロードモジュールを入力対象および解析対象とし、入力した各ロードモジュールに含まれるすべてのオブジェクトを調べて、オブジェクトをキーとしてそのオブジェクトが含まれるロードモジュール(群)を検索可能な、オブジェクト−ロードモジュール集合対応表を作成・出力する。
オブジェクト分類部では、オブジェクト−ロードモジュール集合対応表を入力して、処理対象とするすべてのオブジェクトについて、各オブジェクトが属するロードモジュールの集合が等しいもの同士をグループ化し、その結果をロードモジュール集合−オブジェクト集合対応表として出力する。
ライブラリ生成部では、ロードモジュール集合−オブジェクト集合対応表を入力し、オブジェクト分類部で判明した各々のオブジェクトグループ毎に、そこに含まれるすべてのオブジェクトをリンクして単一の共有ライブラリを生成し出力する。
最後に、共有ライブラリ化されずに残ったオブジェクト(これにはメインオブジェクトも含む)と、前記ライブラリ生成部により生成した共有ライブラリを入力として、リンケージエディタを実行し、個々のロードモジュールを作成する。
【０００８】
図２は本発明が適用される計算機システムの概略構成を示す。
２１はＣＰＵ、２２は入出力装置、２３はメモリ、２４はディスクである。
メモリ２３はコンパイラが生成した個々のオブジェクトモジュール(オブジェクト)と実行可能な複数のモジュール(ロードモジュール)を格納し、ＣＰＵ２１はメモリ２３に格納されたオブジェクトとロードモジュールを基に共有ライブラリを生成する処理を行い、ディスク２４は生成した共有ライブラリを格納する。
【０００９】
次に、本実施例の詳細について説明する。
最初に、前提とするロードモジュールの構成について説明する。
本実施例では、図３に示すオブジェクト参照関係を持つ３個のロードモジュールが最初に存在するものとする。
図４は、それら３個のロードモジュールをそれぞれ静的にリンクした場合に、各ロードモジュールに含まれるオブジェクトを示す。
本発明の適用にあたっては、実際には図４のように静的にリンクされたすべてのロードモジュールが存在すれば十分であり、図３のように各オブジェクト間のすべての参照関係を明らかにしておく必要はない。
次に、本実施例を通じて使用する集合の表現方法を説明する。
計算機上で集合を表現する方法は複数知られているが、ここではビットベクトルを用いる。
ビットベクトルとは、ある固定長サイズの整数型データに含まれる各々のビット位置を各要素に対応させることにより、各ビットのオン(１)・オフ(０)を、当該要素がその集合に含まれる・含まれないという二状態として表現する方法である。
ビット位置を要素に一対一に対応させるため、集合を表す整数型データに含まれるビット数(ビット幅)は、少なくともその集合に含まれうる全要素数以上でなければならない。これを図８を用いて説明する。
図８はa,b,cを要素とする集合をビットベクトルで表したものである。
左側の“含まれる要素”として示された集合状態の列は、a,b,cの三要素で表しうるすべての集合パターンを表現しており、中央のa,b,cの各列は左側の各集合にそれぞれの要素が含まれるかどうかを有／無で表現しており、右側の二進表現の列は「有」を１とし、「無」を０として、各集合をそれぞれ二進数に置換したものを表現している。
例えば、図８において、左側の“含まれる要素”として示された集合パターンが“b,c”の場合、中央のa,b,cの各列は“無，有，有”となり、右側の２進表現の列は“0b011”となる。
このビットベクトルで表現した集合に対する各種の操作方法を図９に示す。
図９におけるandおよびorは、ビットごとのANDおよびOR演算を意味する。このビットベクトル表現により、計算機上で扱いやすい形で集合を表現できる。
【００１０】
次に、本実施例の動作について説明する。
まず、図１０を用いてオブジェクト関係解析部の動作を説明する。
カウンタとして、モジュールカウンタMCとオブジェクトカウンタOCを設ける。
最初にステップ1001において、モジュールカウンタMCおよびオブジェクトカウンタOCをゼロに初期設定する。そして、オブジェクト名称を格納する配列ObjectNameおよび、ロードモジュール集合を格納する配列LoadSetの領域を確保する。
両方の配列の要素数はともに、本発明を適用するすべてのロードモジュール(本実施例では、X,Y,Zの3個)に含まれるオブジェクトの総数(本実施例では、a,b,c,d,e,f,p,q,r,x,y,zの13個)とする。
次に、ステップ1002に移り、最初のロードモジュールをオープンする。ロードモジュールのオープン順序は任意であるが、ここではX,Y,Zの順にオープンするものと仮定する。したがって最初のロードモジュールとしてXをオープンし、モジュールカウンタMCを1にする。
ステップ1003では、現在オープンしているロードモジュール（この場合、ロードモジュールX）に含まれるオブジェクトの中からオブジェクト名称をひとつ取り出す。オブジェクト名称の取り出し順序も任意であるが、ここでは図４の記載のとおり上から下に順に取り出されるものと仮定する。したがって、ここでは最初にオブジェクトxの名称が取り出される。
【００１１】
ステップ1004では、取り出したオブジェクト名称xをキーとして配列ObjectNameを検索しステップ1005の判定へ移る。
この時点では配列ObjectNameにはまだひとつも名称が登録されていないため、オブジェクト名称xは見つからず、ステップ1005の判定はNoとなりステップ1007へ行く。
ステップ1007では、OCを0から1に増やし、ObjectName[OC]に名称文字列xを格納する。格納した名称文字列xにはインデックスを付ける。このインデックスは図５のオブジェクト−ロードモジュール集合対応表のオブジェクト番号に相当する。
また、ステップ1005の判定の結果、Yesであればステップ1006に進み、ステップ1006では配列中で見つかった要素のインデックスをオブジェクト番号(OC)とし、ステップ1007に進む。
ステップ1008では、配列要素LoadSet[1]の最下位からMC番目(ここでは1番目)のビットをオンにする。ここでは、モジュールカウンタMCの値は1であるので、最下位から1番目のビットをオンにする。この操作は、オブジェクトxが属するロードモジュールの集合にXを要素として追加したことを意味する。
判定1009では、オープンしたロードモジュールXにはまだオブジェクトが残っているので、ステップ1003に戻って、次のオブジェクトa以降の処理を続ける。
ロードモジュールX内のすべてのオブジェクトを処理し終えた場合は、判定1009の結果がNoとなり、ステップ1010に移ってオープンしていたロードモジュールXをクローズする。
ステップ1011の判定では、まだYとZのロードモジュールが残っているので、結果はYesとなり、ステップ1002に移って処理を続ける。
すべてのロードモジュールを処理し終えた場合は、判定1011の結果がNoとなり、オブジェクト関係解析部が終了する。
【００１２】
図５のオブジェクト−ロードモジュール集合対応表が示すとおり、この時点で配列LoadSetの各要素は、各オブジェクトがどのロードモジュールに属するかをビットベクトルで表している。オブジェクト関係解析部における出現順序に従って、各オブジェクトには1から連続する整数値が割り振られており、それが図５のオブジェクト番号である。
図５を用いて任意のオブジェクトに対してそれを含むロードモジュール集合を求めるには以下のようにする。
まず、例えば、名称文字列dをキーにして配列ObjectNameを検索する。その結果、ObjectName[10]の内容がdであることが判明し、このインデックス10がオブジェクトdのオブジェクト番号であることがわかる。次に、この10をインデックスとして配列LoadSetを参照すると、LoadSet[10]=(110)２である。これは集合のビットベクトル表現であり、各ビットは最下位から順にX,Y,Zというロードモジュールを意味しているので、結局、オブジェクトdはYとZに含まれることがわかる。
以上のとおり、本例では、オブジェクト関係解析部により、オブジェクト−ロードモジュール集合対応表がこの時点でLoadSet配列の形で求められたことになる。
【００１３】
次に、図１１を用いてオブジェクト分類部の動作を説明する。
最初にステップ1101において、配列ObjectSetを確保する。この配列は、ロードモジュールの包含パターンごとに、そのようなパターンを持つオブジェクトをまとめて集合表現するものであるので、ロードモジュール数をαとすると、確保すべき配列要素数は2αとなり、α＝3とすれば、配列要素数は8となり、オブジェクトの総数は13個なので、要素型は最低でも13ビット以上の幅を持つ整数型である必要がある。また、オブジェクトカウンタOCはゼロに初期化しておく。
ステップ1102において、オブジェクトカウンタOCを0から1に増やす。
ステップ1103において、OCが1であるので、オブジェクト番号(OC)＝1におけるLoadSet[OC]は(001)２であり、その１０進値は1であるので、LoadSet[OC]の１０進値が1であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち1番目のビットを1にする。その結果、ObjectSetの内容は(0000000000001)になる。
判定1104では、オブジェクト総数が13であるのに対し、OCは現在1であるので、結果はNoとなり、ステップ1103へ戻って順次オブジェクトを処理する。
【００１４】
ステップ1103においてOC＝2の場合には、オブジェクト番号(OC)＝2におけるLoadSet[OC]は(101)２であり、その１０進値は5であるので、LoadSet[OC]の１０進値が5であるエントリのObjectSet（ObjectSet[LoadSet[OC]]）の最下位から数えてOC番目のビット、すなわち2番目のビットを1にする。その結果、ObjectSetの内容は(0000000000010)になる。
OC＝3の場合には、オブジェクト番号(OC)＝3におけるLoadSet[OC]は(011)２であり、その１０進値は3であるので、LoadSet[OC]の１０進値が3であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち3番目のビットを1にする。その結果、ObjectSetの内容は(0000000000100)になる。
OC＝4の場合には、オブジェクト番号(OC)＝4におけるLoadSet[OC]は(011)２であり、その１０進値は3であるので、LoadSet[OC]の１０進値が3であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち4番目のビットを1にする。その結果、ObjectSetの内容は(0000000001100)になる。
OC＝5の場合には、オブジェクト番号(OC)＝5におけるLoadSet[OC]は(101)２であり、その１０進値は5であるので、LoadSet[OC]の１０進値が5であるエントリのObjectSetの最下位から数えてOC番目のビット、すなわち5番目のビットを1にする。その結果、ObjectSetの内容は(0000000010010)になる。
以下、同様にして、オブジェクト番号(OC)＝13までの処理をする。
【００１５】
図５によれば最大の番号を持つオブジェクトはzであるので、ｚの処理を終えた後、判定1104がYesとなり、オブジェクト分類部を終了する。
図６が示すとおり、この時点で配列ObjectSetの各要素は、ロードモジュールのそれぞれの包含パターンを持つオブジェクトの集合を表している。
例えば、モジュールXおよびYのみに含まれるオブジェクト集合を求めることを考えると、集合{X,Y}に対応するビットベクトルは(011)２である。これは10進表現で3であるので、ObjectSet[3]を参照すると、内容は(0000001101100)２である。 これを最下位ビットから順に、オブジェクト番号順に並べたオブジェクトx,a,b,c,f,p,q,s,y,d,e,r,zに対応付けて見ると、結局、XとYのみに含まれるオブジェクトは、b,c,p,qであることがわかる。
以上のとおり、本例では、オブジェクト分類部により、ロードモジュール集合−オブジェクト集合対応表がこの時点でObjectSet配列の形で求められたことになる。
【００１６】
次に、図１２を用いてライブラリ生成部の動作を説明する。
最初にステップ1201において、単一の共有ライブラリを作成するために一括してリンケージエディタに渡すオブジェクト群の名称文字列を格納する文字配列LinkBufを確保し、空文字列を初期設定する。また、オブジェクト集合カウンタOSCを設け、これをゼロに初期化しておく。
ロードモジュールの総数をαとした場合、OSCは1〜2α-1（α＝3の場合、1〜7）まで1ずつ変移するカウンタであり、各々のカウント値は、それを2進表現したビットベクトル（OSC＝3の場合、(011)２）が各ロードモジュールの包含パターンを意味するものである。
ステップ1202において、OSCを0から1に増やし、オブジェクトカウンタOCをゼロに初期設定する。
ステップ1203において、OCを0から1に増やす。
判定1204において、ObjectSet[1]は(0000000000001)２であり、最下位ビットがオンなので、結果はYesとなり判定1205へ行く。
判定1205では、ObjectName[1]はxであり、これはメインオブジェクトなので、結果はYesとなりステップ1207へ行く。
ステップ1207では、ObjectSet[1]を1ビット右シフトした結果、すべてのビットがゼロとなる。
ステップ1208の結果はYesなので、ステップ1209へいく。
ステップ1209では、LinkBufに何も格納されていないので、リンケージエディタは起動されず、ObjectSet[1]に対応する共有ライブラリは作成されない。
ステップ1210では、OSCは1であり、配列ObjectSetの最大インデックスは7(すなわち2３-1：3はロードモジュールの総数)なので、結果はNoとなりステップ1202へ行く。
上記をOSCが7になるまで繰り返すと、判定1210がYesとなり、ライブラリ生成部は終了する。この時点で、生成されている共有ライブラリは、図６が示すように、オブジェクトb,c,p,qから成るもの、オブジェクトa,f,sから成るもの、および、オブジェクトd,e,rから成るものの３個である。
例えば、OSC＝3の場合、OC＝3,4,6,7のときにステップ1206においてObjectName[OC]が示すオブジェクト名称がLinkBufに追加書きで出力される。
【００１７】
最後に、リンケージエディタでロードモジュールを作成する。ロードモジュールXを作成する場合は、オブジェクトx、ロードモジュールYを作成する場合はオブジェクトy、ロードモジュールZを作成する場合は、オブジェクトzと、構成したすべての共有ライブラリを引数に与えてリンケージエディタをそれぞれ起動すればよい。
【００１８】
以上のようにして生成したロードモジュールと各共有ライブラリの参照関係を示したものが図７である。
71、72、および73が前記ライブラリ生成部により生成された共有ライブラリである。図７における矢印の意味は、左側のメインモジュールを実行する場合は、そこから出ているすべての矢印が指す右側の共有ライブラリをローディングする必要があるという意味である。
図７が示すように、ロードモジュールXを実行する場合は、共有ライブラリ71と73、ロードモジュールYを実行する場合は共有ライブラリ71と72、ロードモジュールZを実行する場合は、共有ライブラリ72と73をそれぞれローディングすれば、必要十分なオブジェクトが仮想空間上に存在する。
さらに、無駄なオブジェクトがローディングされないという特長は、ロードモジュールの組み合わせには依存せず、いかなるローディングパターンにおいても維持される。
【００１９】
【発明の効果】
以上述べたように、本発明によれば、特に、実行されるロードモジュールがあらかじめ決定されているシステムにおいて、オブジェクトが含まれるロードモジュール集合をキーにしてオブジェクトをグループ化および共有ライブラリ化することにより、無駄なオブジェクトをローディングすることなく、計算機システムの仮想記憶の利用効率を常に最大にすることができる。
【図面の簡単な説明】
【図１】実施形態の概要を説明するための図である。
【図２】計算機システムの構成を示す図である。
【図３】実施例で用いるオブジェクト間の参照関係を示す図である。
【図４】ロードモジュールのオブジェクト構成を示す図である。
【図５】オブジェクト−ロードモジュール集合対応表を示す図である。
【図６】ロードモジュール集合−オブジェクト集合対応表を示す図である。
【図７】生成したライブラリを示す図である。
【図８】ビットベクトルによる集合表現を示す図である。
【図９】ビットベクトル集合への操作を示す図である。
【図１０】オブジェクト関係解析部のフローを示す図である。
【図１１】オブジェクト分類部のフローを示す図である。
【図１２】ライブラリ生成部のフローを示す図である。
【符号の説明】
２１ ＣＰＵ
２２ 入出力装置
２３ メモリ
２４ ディスク
Claims (3)
- 処理装置とメモリを備える計算機システムにおける共有ライブラリ生成方法であって、
前記メモリにはコンパイラが生成した個々のオブジェクトモジュールと実行可能な複数のモジュールが格納され、
前記処理装置は、前記個々のオブジェクトモジュールがどの前記モジュールにリンクされるかを解析し、個々のオブジェクトモジュールと各モジュール間のリンク関係を取得し、
該取得したリンク関係に基づき、前記モジュールにリンクする全てのオブジェクトモジュールについて、オブジェクトモジュールがリンクされるモジュールの集合をキーとして全てのオブジェクトモジュールを分類してオブジェクトモジュールの集合を取得し、
該取得したオブジェクトモジュールの各集合を基に前記メモリに格納する共有ライブラリを生成することを特徴とする共有ライブラリ生成方法。 - 処理装置とメモリを有し、
前記メモリにはコンパイラが生成した個々のオブジェクトモジュールと実行可能な複数のモジュールが格納され、
前記処理装置は、前記個々のオブジェクトモジュールがどの前記モジュールにリンクされるかを解析し、個々のオブジェクトモジュールと各モジュール間のリンク関係を取得するオブジェクトモジュール関係解析手段と、
該取得したリンク関係に基づき、前記モジュールにリンクする全てのオブジェクトモジュールについて、オブジェクトモジュールがリンクされるモジュールの集合をキーとして全てのオブジェクトモジュールを分類してオブジェクトモジュールの集合を取得するオブジェクトモジュール分類手段と、
該取得したオブジェクトモジュールの各集合を基に前記メモリに格納する共有ライブラリを生成するライブラリ生成手段を有することを特徴とする共有ライブラリ生成システム。 - メモリに格納されているコンパイラが生成した個々のオブジェクトモジュールがメモリに格納されている実行可能な複数のモジュールのどのモジュールにリンクされるかを解析し、個々のオブジェクトモジュールと各モジュール間のリンク関係を取得する手順と、
該取得したリンク関係に基づき、前記モジュールにリンクする全てのオブジェクトモジュールについて、オブジェクトモジュールがリンクされるモジュールの集合をキーとして全てのオブジェクトモジュールを分類してオブジェクトモジュールの集合を取得する手順と、
該取得したオブジェクトモジュールの各集合を基に前記メモリに格納する共有ライブラリを生成する手順をコンピュータに実行させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002114223A JP4036257B2 (ja) | 2002-04-17 | 2002-04-17 | 共有ライブラリ生成方法およびシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002114223A JP4036257B2 (ja) | 2002-04-17 | 2002-04-17 | 共有ライブラリ生成方法およびシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003308216A JP2003308216A (ja) | 2003-10-31 |
| JP4036257B2 true JP4036257B2 (ja) | 2008-01-23 |
Family
ID=29396116
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002114223A Expired - Fee Related JP4036257B2 (ja) | 2002-04-17 | 2002-04-17 | 共有ライブラリ生成方法およびシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4036257B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100617297B1 (ko) | 2004-12-03 | 2006-08-30 | 한국전자통신연구원 | 복수의 응용 프로그램들에 공통된 경량 공유 라이브러리를생성하는 방법 |
| JP5899946B2 (ja) | 2012-01-17 | 2016-04-06 | 富士通株式会社 | 分割装置、分割方法、および分割プログラム |
| CN112395436A (zh) * | 2019-08-14 | 2021-02-23 | 北京迈格威科技有限公司 | 一种底库录入方法及装置 |
-
2002
- 2002-04-17 JP JP2002114223A patent/JP4036257B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003308216A (ja) | 2003-10-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Cole et al. | Approximate parallel scheduling. Part I: The basic technique with applications to optimal parallel list ranking in logarithmic time | |
| CN103999035B (zh) | 用于状态机中的数据分析的方法及系统 | |
| Heineman et al. | Algorithms in a Nutshell | |
| EP2875433B1 (en) | Methods and systems for handling data received by a state machine engine | |
| US8074219B2 (en) | Order preservation in data parallel operations | |
| TW201506632A (zh) | 用於提供藉由狀態機器引擎所接收之資料之方法及裝置 | |
| CN109791492B (zh) | 流水线相关树查询优化器和调度器 | |
| Mitani et al. | Parallelizing exact and approximate string matching via inclusive scan on a GPU | |
| JP2013206289A (ja) | プログラム、コード生成方法および情報処理装置 | |
| Qiao et al. | Hyper dimension shuffle: Efficient data repartition at petabyte scale in scope | |
| JP4036257B2 (ja) | 共有ライブラリ生成方法およびシステム | |
| Onai et al. | Architecture of a reduction-based parallel inference machine: PIM-R | |
| WO2005106713A1 (ja) | 情報処理方法及び情報処理システム | |
| Dewar | The SETL programming language | |
| Amestoy et al. | PARASOL An integrated programming environment for parallel sparse matrix solvers | |
| JPS6142031A (ja) | ソ−ト処理装置 | |
| JP5429164B2 (ja) | 有限オートマトン生成システム | |
| Lee | ALTEP—A cellular processor for high-speed pattern matching | |
| Blelloch et al. | Class notes: Programming parallel algorithms | |
| CN109937453A (zh) | 存储器减少的核苷酸序列比较 | |
| Rajasekaran et al. | A practical realization of parallel disks | |
| Malhotra et al. | Data Structures and Program Design Using C: A Self-Teaching Introduction | |
| Cécé | Three simulation algorithms for labelled transition systems | |
| JP4995724B2 (ja) | 情報処理システムおよび情報処理方法 | |
| Mishra et al. | Selection of best sorting algorithm for a particular problem |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040318 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041020 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070511 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070605 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070806 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071016 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071023 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101109 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |