JPH09204297A - 複数のヒープにおいて順序を維持してメモリ割り当てを行うための装置および方法 - Google Patents
複数のヒープにおいて順序を維持してメモリ割り当てを行うための装置および方法Info
- Publication number
- JPH09204297A JPH09204297A JP8139572A JP13957296A JPH09204297A JP H09204297 A JPH09204297 A JP H09204297A JP 8139572 A JP8139572 A JP 8139572A JP 13957296 A JP13957296 A JP 13957296A JP H09204297 A JPH09204297 A JP H09204297A
- Authority
- JP
- Japan
- Prior art keywords
- pointer
- heap
- heaps
- space
- segment
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/54—Link editing before load time
-
- 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/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Abstract
(57)【要約】
【課題】 オブジェクトファイルの新たな再リンクが行
われる毎に完全に新しい実行可能なファイルを作成する
必要性を除去できるようにする。 【解決手段】 セグメントの付加および削除が行われる
場合、メモリに格納された複数のヒープにおけるデータ
の順序は、前記複数のヒープの間で同じように維持され
る。前記複数のヒープにおけるすべてのエントリが、他
のすべてのヒープに対応するエントリを有するわけでは
ないが、前記複数のヒープにおけるデータの順序は、前
記メモリに格納された順序リストに従う。このように順
序付けられたヒープは、例えば、インクリメンタルリン
カ・ソフトウエアプログラムにおいて有用である。
われる毎に完全に新しい実行可能なファイルを作成する
必要性を除去できるようにする。 【解決手段】 セグメントの付加および削除が行われる
場合、メモリに格納された複数のヒープにおけるデータ
の順序は、前記複数のヒープの間で同じように維持され
る。前記複数のヒープにおけるすべてのエントリが、他
のすべてのヒープに対応するエントリを有するわけでは
ないが、前記複数のヒープにおけるデータの順序は、前
記メモリに格納された順序リストに従う。このように順
序付けられたヒープは、例えば、インクリメンタルリン
カ・ソフトウエアプログラムにおいて有用である。
Description
【０００１】
【発明の属する技術分野】この発明は、データ処理シス
テムにおけるメモリ管理に関し、特に、複数のヒープの
間におけるデータの順序を一定に維持しながら該複数の
ヒープにおけるデータの付加および削除を行うことがで
きるようにした装置および方法に関する。
テムにおけるメモリ管理に関し、特に、複数のヒープの
間におけるデータの順序を一定に維持しながら該複数の
ヒープにおけるデータの付加および削除を行うことがで
きるようにした装置および方法に関する。
【０００２】
【従来の技術】各種のソフトウエアプログラムは、情報
を“ヒープ”という形態でメモリに格納している。この
ヒープとは、データの集合のことである。ヒープは、ア
レイ、リンク（連結）リストとして、または、当業者に
知られているその他の適当なデータ構造として実現され
ることができる。従来のソフトウエアプログラムの多く
は、該プログラムに必要なデータを格納するためのヒー
プ群を作成する。通常、ソフトウエアプログラムの実行
開始時に空きヒープが作成され、該ソフトウエアプログ
ラムの実行が進行するのに伴って、該ヒープにデータが
付加される。
を“ヒープ”という形態でメモリに格納している。この
ヒープとは、データの集合のことである。ヒープは、ア
レイ、リンク（連結）リストとして、または、当業者に
知られているその他の適当なデータ構造として実現され
ることができる。従来のソフトウエアプログラムの多く
は、該プログラムに必要なデータを格納するためのヒー
プ群を作成する。通常、ソフトウエアプログラムの実行
開始時に空きヒープが作成され、該ソフトウエアプログ
ラムの実行が進行するのに伴って、該ヒープにデータが
付加される。
【０００３】“リンカ（linker）”ソフトウエアプログ
ラムは、１つまたは複数の“オブジェクトファイル”を
単一の“実行可能なファイル”に併合するものである。
従来のリンカソフトウエアは実行時に複数のリストを作
成し、各前記リストは、リンクされるオブジェクトファ
イルの特定種類のデータを格納する。前記リンカは、各
オブジェクトファイルからのセグメントを入力順に取り
込み、適当なリストの終わりに付加する。従来のリンカ
は、新たな再リンクが行われる毎に、完全に新しい実行
可能なファイルを作成する。
ラムは、１つまたは複数の“オブジェクトファイル”を
単一の“実行可能なファイル”に併合するものである。
従来のリンカソフトウエアは実行時に複数のリストを作
成し、各前記リストは、リンクされるオブジェクトファ
イルの特定種類のデータを格納する。前記リンカは、各
オブジェクトファイルからのセグメントを入力順に取り
込み、適当なリストの終わりに付加する。従来のリンカ
は、新たな再リンクが行われる毎に、完全に新しい実行
可能なファイルを作成する。
【０００４】
【発明が解決しようとする課題】しかし、最後（最近）
のリンク動作実行後において、複数のオブジェクトファ
イルのうちの一部のみが変更されているのにすぎないの
で、このような従来技術のように新たな再リンクが行わ
れる毎に完全に新しい実行可能なファイルを作成するこ
とは、効率的ではない。この発明は上述の点に鑑みてな
されたもので、複数のヒープ間においてデータの順序を
維持しながら、該ヒープに対するデータの削除および付
加を可能にし、これにより、オブジェクトファイルの新
たな再リンクが行われる毎に完全に新しい実行可能なフ
ァイルを作成する必要性を除去しようとするものであ
る。
のリンク動作実行後において、複数のオブジェクトファ
イルのうちの一部のみが変更されているのにすぎないの
で、このような従来技術のように新たな再リンクが行わ
れる毎に完全に新しい実行可能なファイルを作成するこ
とは、効率的ではない。この発明は上述の点に鑑みてな
されたもので、複数のヒープ間においてデータの順序を
維持しながら、該ヒープに対するデータの削除および付
加を可能にし、これにより、オブジェクトファイルの新
たな再リンクが行われる毎に完全に新しい実行可能なフ
ァイルを作成する必要性を除去しようとするものであ
る。
【０００５】
【課題を解決するための手段】上記目的を達成するた
め、この発明に係る装置は、データ処理システムのメモ
リに格納された複数のヒープにおけるエントリを操作す
る装置であって、前記各ヒープ毎に必要とされる空きス
ペースの量をそれぞれ決定する手段と、前記各ヒープに
おけるエントリの順序が各ヒープ間で維持されるよう、
前記各必要とされる空きスペースの量を前記各ヒープに
割り当てる手段とを具備するものである。
め、この発明に係る装置は、データ処理システムのメモ
リに格納された複数のヒープにおけるエントリを操作す
る装置であって、前記各ヒープ毎に必要とされる空きス
ペースの量をそれぞれ決定する手段と、前記各ヒープに
おけるエントリの順序が各ヒープ間で維持されるよう、
前記各必要とされる空きスペースの量を前記各ヒープに
割り当てる手段とを具備するものである。
【０００６】さらに、この発明に係る方法は、データ処
理システムのメモリに格納された複数のヒープの各々に
おける所定量の空きスペースを見つけるために、前記デ
ータ処理システムによって実行される方法であって、前
記各ヒープがそれに関連するLOポインタおよびHIポイン
タ（すなわち第１および第２ポインタ）を有するよう、
各ヒープ毎の該LOポインタおよびHIポインタをそれぞれ
設定するステップと、少なくとも１つの前記LOポインタ
を、これに対応する前記HIポインタと等しい値になるよ
うに進めるステップと、前記対応する少なくとも１つの
HIポインタを、前記複数のヒープにおける該HIポインタ
に関する次の有意セグメントを指示するように進めるス
テップと、前記各ヒープにおける各関連する前記LOポイ
ンタとHIポインタとの間に前記所定量の空きスペースが
存在するか否かを判定するステップとを具備するもので
ある。
理システムのメモリに格納された複数のヒープの各々に
おける所定量の空きスペースを見つけるために、前記デ
ータ処理システムによって実行される方法であって、前
記各ヒープがそれに関連するLOポインタおよびHIポイン
タ（すなわち第１および第２ポインタ）を有するよう、
各ヒープ毎の該LOポインタおよびHIポインタをそれぞれ
設定するステップと、少なくとも１つの前記LOポインタ
を、これに対応する前記HIポインタと等しい値になるよ
うに進めるステップと、前記対応する少なくとも１つの
HIポインタを、前記複数のヒープにおける該HIポインタ
に関する次の有意セグメントを指示するように進めるス
テップと、前記各ヒープにおける各関連する前記LOポイ
ンタとHIポインタとの間に前記所定量の空きスペースが
存在するか否かを判定するステップとを具備するもので
ある。
【０００７】さらに、この発明は、複数のヒープの各々
に割り当てられるべきスペースの量をそれぞれ示す複数
の所定値を受け取るステップと、前記複数のヒープにお
いて、前記各割り当てられるべきスペース量を有するそ
れぞれの位置を検出するステップと、前記それぞれの位
置が前記複数ヒープ間において同じ順序を維持するよう
に、該それぞれの位置を割り当てるステップとを具備す
る方法を実行するためのプログラムを記憶してなるコン
ピュータによって読み取り可能な記憶媒体からなるもの
である。
に割り当てられるべきスペースの量をそれぞれ示す複数
の所定値を受け取るステップと、前記複数のヒープにお
いて、前記各割り当てられるべきスペース量を有するそ
れぞれの位置を検出するステップと、前記それぞれの位
置が前記複数ヒープ間において同じ順序を維持するよう
に、該それぞれの位置を割り当てるステップとを具備す
る方法を実行するためのプログラムを記憶してなるコン
ピュータによって読み取り可能な記憶媒体からなるもの
である。
【０００８】この発明は、複数のヒープに対するデータ
の削除および付加が行われるときに、前記複数のヒープ
の間でその順序を維持してメモリ割り当てを行うことが
できるものである。ある用途においては、データの削除
および付加が行われるときに複数のヒープ間でその順序
を維持することが望まれるので、そのような用途におい
て本発明を有利に応用することができる。“セグメン
ト”とは、１つのヒープにおけるデータの１ブロックで
ある。１つのヒープにおける各セグメントは、その他の
ヒープの各々に０個または１個の関連するセグメントを
有する。この発明の順序制御によって、たとえば１つの
ヒープにおけるセグメント［ｉ］がセグメント［ｉ＋
１］の前にある場合には、前記セグメント［ｉ］および
セグメント［ｉ＋１］を含むすべてのヒープにおいて、
前記セグメント［ｉ］に関連するセグメントは、前記セ
グメント［ｉ＋１］に関連するセグメントの前に位置す
る、ことが保証される。
の削除および付加が行われるときに、前記複数のヒープ
の間でその順序を維持してメモリ割り当てを行うことが
できるものである。ある用途においては、データの削除
および付加が行われるときに複数のヒープ間でその順序
を維持することが望まれるので、そのような用途におい
て本発明を有利に応用することができる。“セグメン
ト”とは、１つのヒープにおけるデータの１ブロックで
ある。１つのヒープにおける各セグメントは、その他の
ヒープの各々に０個または１個の関連するセグメントを
有する。この発明の順序制御によって、たとえば１つの
ヒープにおけるセグメント［ｉ］がセグメント［ｉ＋
１］の前にある場合には、前記セグメント［ｉ］および
セグメント［ｉ＋１］を含むすべてのヒープにおいて、
前記セグメント［ｉ］に関連するセグメントは、前記セ
グメント［ｉ＋１］に関連するセグメントの前に位置す
る、ことが保証される。
【０００９】複数の関連するデータセグメントを複数の
ヒープにおける対応するセグメントに挿入する、という
ことがしばしば必要になる。前記複数のヒープのデータ
の順序が維持されるために必要なことは、或る１つのデ
ータセグメントを或る１つのヒープの途中に挿入可能で
あるのは、他の各ヒープの対応する位置に他の関連する
データセグメントを挿入する余地がある場合にのみに限
る、ということである。以下では、この発明は、インク
リメンタルリンカ・ソフトウエアプログラムにおけるヒ
ープに関して説明されている。しかし、当業者に理解さ
れるように、この発明は、複数のヒープ間において順序
を維持することが有用な他の分野においても適用可能で
ある。この発明は、“有意セグメント”という観念を使
用することによって、複数のヒープに対するデータの付
加および削除が行われるときに前記複数のヒープ間にお
いてその順序が維持されるよう、前記複数のヒープに関
連する複数のポインタを操作する発明である。この発明
の作用と効果は、図面を参照して以下で行う発明の実施
の形態の詳細な説明によってより一層明らかになる。
ヒープにおける対応するセグメントに挿入する、という
ことがしばしば必要になる。前記複数のヒープのデータ
の順序が維持されるために必要なことは、或る１つのデ
ータセグメントを或る１つのヒープの途中に挿入可能で
あるのは、他の各ヒープの対応する位置に他の関連する
データセグメントを挿入する余地がある場合にのみに限
る、ということである。以下では、この発明は、インク
リメンタルリンカ・ソフトウエアプログラムにおけるヒ
ープに関して説明されている。しかし、当業者に理解さ
れるように、この発明は、複数のヒープ間において順序
を維持することが有用な他の分野においても適用可能で
ある。この発明は、“有意セグメント”という観念を使
用することによって、複数のヒープに対するデータの付
加および削除が行われるときに前記複数のヒープ間にお
いてその順序が維持されるよう、前記複数のヒープに関
連する複数のポインタを操作する発明である。この発明
の作用と効果は、図面を参照して以下で行う発明の実施
の形態の詳細な説明によってより一層明らかになる。
【００１０】
【発明の実施の形態】以下、添付図面を参照してこの発
明の一実施の形態を詳細に説明する。図１は、ＣＰＵ１
０２と、該ＣＰＵ１０２に接続されたメモリ１０４とを
備えたデータ処理システム１００を示す図である。明確
さのため図示されていないが、該データ処理システム１
００は、各種の入出力装置、周辺機器、ネットワーク接
続装置、メモリ、他のＣＰＵ等を備えていてもよい。
明の一実施の形態を詳細に説明する。図１は、ＣＰＵ１
０２と、該ＣＰＵ１０２に接続されたメモリ１０４とを
備えたデータ処理システム１００を示す図である。明確
さのため図示されていないが、該データ処理システム１
００は、各種の入出力装置、周辺機器、ネットワーク接
続装置、メモリ、他のＣＰＵ等を備えていてもよい。
【００１１】前記メモリ１０４は、UNIXオペレーティン
グシステムの下に実行されるインクリメンタルリンカで
あるのが好ましいインクリメンタルリンカ・ソフトウエ
アプログラムを格納している。前記UNIXは、米国および
その他の国において、X/OPEN, Ltd.によって独占的にラ
イセンスされている登録商標である。Sun Microsystem
s,Inc.では、該Sun Microsystems,Inc.の登録商標であ
るSolarisという名前でUNIXの一バージョンを製造して
いる。さらに、前記メモリ１０４は、１つまたは複数の
オブジェクトファイル１１０、および、１つまたは複数
のインクリメントタルリンクされた実行可能なファイル
１１２を格納している。各前記実行可能なファイル１１
２は、以下に詳述するヒープ、フリーセグメントリスト
および順序リストのような各種データ構造を含んでい
る。
グシステムの下に実行されるインクリメンタルリンカで
あるのが好ましいインクリメンタルリンカ・ソフトウエ
アプログラムを格納している。前記UNIXは、米国および
その他の国において、X/OPEN, Ltd.によって独占的にラ
イセンスされている登録商標である。Sun Microsystem
s,Inc.では、該Sun Microsystems,Inc.の登録商標であ
るSolarisという名前でUNIXの一バージョンを製造して
いる。さらに、前記メモリ１０４は、１つまたは複数の
オブジェクトファイル１１０、および、１つまたは複数
のインクリメントタルリンクされた実行可能なファイル
１１２を格納している。各前記実行可能なファイル１１
２は、以下に詳述するヒープ、フリーセグメントリスト
および順序リストのような各種データ構造を含んでい
る。
【００１２】図２〜図４に示すように、オブジェクトフ
ァイル１１０はインクリメンタルリンカ１０８に入力さ
れ、該リンカ１０８は実行可能なファイル１１２を修正
する。この実施の形態に係るインクリメンタルリンカ１
０８は、オブジェクトファイル間のリンクが実行される
毎にすべてのオブジェクトファイル１１０の再リンクを
行なわない、という点において従来のリンカとは異なっ
ている。また、該インクリメンタルリンカ１０８は、前
回のリンク動作からのすべての旧いデータを実行可能な
ファイル１１２にセーブし、前回のリンク動作後修正さ
れたオブジェクトファイルのみについて新たなデータを
生成するものである。前記リンカ１０８に対して入出力
される前記ファイル１１０，１１２のフォーマットは、
当業者に知られており、“System V Application Binar
y Interface”，Prentice‐Hall（AT&Tによる著作権199
0年）、および、“System V Application Binary Inter
face -- SPARC Processor Supplement”，Prentice‐Ha
ll（AT&Tによる著作権1990年）に詳細に記載されてい
る。
ァイル１１０はインクリメンタルリンカ１０８に入力さ
れ、該リンカ１０８は実行可能なファイル１１２を修正
する。この実施の形態に係るインクリメンタルリンカ１
０８は、オブジェクトファイル間のリンクが実行される
毎にすべてのオブジェクトファイル１１０の再リンクを
行なわない、という点において従来のリンカとは異なっ
ている。また、該インクリメンタルリンカ１０８は、前
回のリンク動作からのすべての旧いデータを実行可能な
ファイル１１２にセーブし、前回のリンク動作後修正さ
れたオブジェクトファイルのみについて新たなデータを
生成するものである。前記リンカ１０８に対して入出力
される前記ファイル１１０，１１２のフォーマットは、
当業者に知られており、“System V Application Binar
y Interface”，Prentice‐Hall（AT&Tによる著作権199
0年）、および、“System V Application Binary Inter
face -- SPARC Processor Supplement”，Prentice‐Ha
ll（AT&Tによる著作権1990年）に詳細に記載されてい
る。
【００１３】好ましい実施の形態において、この発明が
インクリメンタルリンカ１０８に適用される場合、実行
可能なファイル１１２における各ヒープ、および、各オ
ブジェクトファイルにおける各セグメントは、ELF（Exe
cutable and Linking Format）部に対応する。一般的
に、各オブジェクトファイル１１０は、複数のELF部を
該ELF部のサイズと共に有している。これらは、リンク
動作時において、前のファイル１１２と共にマージされ
ることによって、インクリメンタルリンクされたファイ
ル１１２のELF部を形成する（図４参照）。
インクリメンタルリンカ１０８に適用される場合、実行
可能なファイル１１２における各ヒープ、および、各オ
ブジェクトファイルにおける各セグメントは、ELF（Exe
cutable and Linking Format）部に対応する。一般的
に、各オブジェクトファイル１１０は、複数のELF部を
該ELF部のサイズと共に有している。これらは、リンク
動作時において、前のファイル１１２と共にマージされ
ることによって、インクリメンタルリンクされたファイ
ル１１２のELF部を形成する（図４参照）。
【００１４】図２は、インクリメンタルリンカ１０８の
入出力を示すブロック図である。図示のように、前記イ
ンクリメンタルリンカ１０８は、初期入力として、オブ
ジェクトファイルａ.ｏ，ｅ.ｏ，ｂ.ｏ，ｄ.ｏ，ｃ.ｏ
を取り込む。図３は、オブジェクトファイルｅ.ｏの最
初のバージョン２０２が修正されることによって、該オ
ブジェクトファイルｅ.ｏの新たな（修正済の）バージ
ョン２０４が生成される動作を示している。図４に示す
ように、前記オブジェクトファイルｅ.ｏの修正後、該
オブジェクトファイルの再リンクが行われる。この再リ
ンク時において、前記オブジェクトファイルｅ.ｏの最
初のバージョン２０２に関するすべてのデータが、前記
実行可能なファイル１１２から削除され、前記新たなバ
ージョン２０４に関する新たなデータが、前記実行可能
なファイル１１２に付加されることになる。
入出力を示すブロック図である。図示のように、前記イ
ンクリメンタルリンカ１０８は、初期入力として、オブ
ジェクトファイルａ.ｏ，ｅ.ｏ，ｂ.ｏ，ｄ.ｏ，ｃ.ｏ
を取り込む。図３は、オブジェクトファイルｅ.ｏの最
初のバージョン２０２が修正されることによって、該オ
ブジェクトファイルｅ.ｏの新たな（修正済の）バージ
ョン２０４が生成される動作を示している。図４に示す
ように、前記オブジェクトファイルｅ.ｏの修正後、該
オブジェクトファイルの再リンクが行われる。この再リ
ンク時において、前記オブジェクトファイルｅ.ｏの最
初のバージョン２０２に関するすべてのデータが、前記
実行可能なファイル１１２から削除され、前記新たなバ
ージョン２０４に関する新たなデータが、前記実行可能
なファイル１１２に付加されることになる。
【００１５】図５は、メモリ１０４における複数のヒー
プから、前記オブジェクトファイルｅ.ｏの最初のバー
ジョン２０２に対応するセグメントを削除するステップ
を示すフローチャートである。また、図６は、メモリ１
０４における複数のヒープに対して、オブジェクトファ
イルｅ.ｏの新たなバージョン２０４に対応するセグメ
ントを付加するステップを示すフローチャートである。
これら図５および図６については、図７〜図１６の図示
例に関連して後で詳述する。なお、図５および図６のス
テップは、インクリメンタルリンカ１０８の命令を実行
し、前記メモリ１０４に格納されたデータ構造を使用す
るＣＰＵ１０２によって行われる。
プから、前記オブジェクトファイルｅ.ｏの最初のバー
ジョン２０２に対応するセグメントを削除するステップ
を示すフローチャートである。また、図６は、メモリ１
０４における複数のヒープに対して、オブジェクトファ
イルｅ.ｏの新たなバージョン２０４に対応するセグメ
ントを付加するステップを示すフローチャートである。
これら図５および図６については、図７〜図１６の図示
例に関連して後で詳述する。なお、図５および図６のス
テップは、インクリメンタルリンカ１０８の命令を実行
し、前記メモリ１０４に格納されたデータ構造を使用す
るＣＰＵ１０２によって行われる。
【００１６】以下の説明は、図５および図６のフローチ
ャートを参照して図７〜図１６の図示例を説明するもの
である。図７は３つのヒープ５０２，５０４，５０６を
示している。なお、当業者に理解されるように、この発
明は任意数のヒープについて実施されてよい。図７およ
び図８は、前記オブジェクトファイルｅ.ｏの最初のバ
ージョン２０２のセグメントを複数のヒープから削除す
る例を示すものである。また、図８〜図１６は、ヒープ
間におけるセグメントの順序を維持しながら、前記オブ
ジェクトファイルｅ.ｏの新たなバージョン２０４のセ
グメントを前記複数のヒープに付加する例を示す。
ャートを参照して図７〜図１６の図示例を説明するもの
である。図７は３つのヒープ５０２，５０４，５０６を
示している。なお、当業者に理解されるように、この発
明は任意数のヒープについて実施されてよい。図７およ
び図８は、前記オブジェクトファイルｅ.ｏの最初のバ
ージョン２０２のセグメントを複数のヒープから削除す
る例を示すものである。また、図８〜図１６は、ヒープ
間におけるセグメントの順序を維持しながら、前記オブ
ジェクトファイルｅ.ｏの新たなバージョン２０４のセ
グメントを前記複数のヒープに付加する例を示す。
【００１７】図示例において、ヒープ５０２は、前記オ
ブジェクトファイルａ.ｏ，ｅ.ｏ，ｂ.ｏ，ｃ.ｏについ
ての記号部（.SYMBOLS）に対応し、同様に、ヒープ５０
４は、前記オブジェクトファイルａ.ｏ，ｅ.ｏ，ｂ.
ｏ，ｃ.ｏについてのデバッグ情報部（.STABS）に対応
する。さらに、ヒープ５０６は、前記オブジェクトファ
イルａ.ｏ，ｅ.ｏ，ｄ.ｏ，ｃ.ｏについてのデバッグ情
報ストリングテーブル部（.STABSTR）に対応する。各ヒ
ープ（ELF部）におけるエントリは“セグメント”と呼
ばれている。なお、ヒープ５０２および５０４にはオブ
ジェクトファイルｄ.ｏのセグメントは存在していな
い。同様に、ヒープ５０６にはオブジェクトファイル
ｂ.ｏのセグメントは存在していない。前記複数のヒー
プは同一のオブジェクトファイルに関するデータを含ま
ないが、各前記ヒープにおけるセグメントは、順序リス
ト５０８に従って順序付けられている。
ブジェクトファイルａ.ｏ，ｅ.ｏ，ｂ.ｏ，ｃ.ｏについ
ての記号部（.SYMBOLS）に対応し、同様に、ヒープ５０
４は、前記オブジェクトファイルａ.ｏ，ｅ.ｏ，ｂ.
ｏ，ｃ.ｏについてのデバッグ情報部（.STABS）に対応
する。さらに、ヒープ５０６は、前記オブジェクトファ
イルａ.ｏ，ｅ.ｏ，ｄ.ｏ，ｃ.ｏについてのデバッグ情
報ストリングテーブル部（.STABSTR）に対応する。各ヒ
ープ（ELF部）におけるエントリは“セグメント”と呼
ばれている。なお、ヒープ５０２および５０４にはオブ
ジェクトファイルｄ.ｏのセグメントは存在していな
い。同様に、ヒープ５０６にはオブジェクトファイル
ｂ.ｏのセグメントは存在していない。前記複数のヒー
プは同一のオブジェクトファイルに関するデータを含ま
ないが、各前記ヒープにおけるセグメントは、順序リス
ト５０８に従って順序付けられている。
【００１８】図７に示すように、前記順序リスト５０８
は、６つのエントリ、すなわち、該リストのヘッダとし
ての第１のエントリ５１０と、ヒープ５０２、５０４、
５０６に対するポインタを有するオブジェクトファイル
ａ.ｏのエントリ５１２と、ヒープ５０２、５０４、５
０６に対するポインタを有するオブジェクトファイル
ｅ.ｏのエントリ５１３と、ヒープ５０２、５０４に対
するポインタを有するが、ヒープ５０６に対するポイン
タを有さないオブジェクトファイルｂ.ｏのエントリ５
１４と、ヒープ５０６に対するポインタのみを有するオ
ブジェクトファイルｄ.ｏのエントリ５１６と、各前記
ヒープ５０２、５０４、５０６に対するポインタを有す
るオブジェクトファイルｃ.ｏのエントリ５１８とを含
んでいる。このように、図７は、オブジェクトファイル
ａ.ｏ，ｅ.ｏ（最初のバージョン２０２）のリンク後の
インクリメンタルリンカ１０８におけるデータ構造を示
している。
は、６つのエントリ、すなわち、該リストのヘッダとし
ての第１のエントリ５１０と、ヒープ５０２、５０４、
５０６に対するポインタを有するオブジェクトファイル
ａ.ｏのエントリ５１２と、ヒープ５０２、５０４、５
０６に対するポインタを有するオブジェクトファイル
ｅ.ｏのエントリ５１３と、ヒープ５０２、５０４に対
するポインタを有するが、ヒープ５０６に対するポイン
タを有さないオブジェクトファイルｂ.ｏのエントリ５
１４と、ヒープ５０６に対するポインタのみを有するオ
ブジェクトファイルｄ.ｏのエントリ５１６と、各前記
ヒープ５０２、５０４、５０６に対するポインタを有す
るオブジェクトファイルｃ.ｏのエントリ５１８とを含
んでいる。このように、図７は、オブジェクトファイル
ａ.ｏ，ｅ.ｏ（最初のバージョン２０２）のリンク後の
インクリメンタルリンカ１０８におけるデータ構造を示
している。
【００１９】各前記ヒープ５０２、５０４、５０６は、
例えばセグメント５２０のような複数のセグメントを含
んでおり、もっとも好ましくは、これらのセグメント
は、１つまたは複数のフリーバイト（free byte: 空き
バイト）からなるパディング、例えばパディング（パッ
ド）５２２、によって分離されている。図７において、
“パッド”という用語の後の数は、そのパディングエリ
アのバイト数を示している。各ヒープにおけるパディン
グエリアは、“フリーリスト”（free list: 空きリス
ト）５３０、５３２、５３４と呼ばれる連結リスト（li
nked list）において連結・管理されている。また、図
７では、各ヒープにおける、オブジェクトファイルｅ.
ｏの最初のバージョン２０２の個々のセグメントにおけ
るバイト数（すなわち、“２”，“１０”，“２０”な
ど）も示している。好ましい実施の形態によると、各ヒ
ープに割り当てられたセグメントも連結リストにおいて
連結・管理されているが、これは必ずしも必要ではな
く、ヒープ、フリーリストおよび順序リストを表すため
にその他の適当なデータ構造が使用されてもよい。図示
例をより明確にするために、割り当てられたセグメント
の連結リストは図示されていない。
例えばセグメント５２０のような複数のセグメントを含
んでおり、もっとも好ましくは、これらのセグメント
は、１つまたは複数のフリーバイト（free byte: 空き
バイト）からなるパディング、例えばパディング（パッ
ド）５２２、によって分離されている。図７において、
“パッド”という用語の後の数は、そのパディングエリ
アのバイト数を示している。各ヒープにおけるパディン
グエリアは、“フリーリスト”（free list: 空きリス
ト）５３０、５３２、５３４と呼ばれる連結リスト（li
nked list）において連結・管理されている。また、図
７では、各ヒープにおける、オブジェクトファイルｅ.
ｏの最初のバージョン２０２の個々のセグメントにおけ
るバイト数（すなわち、“２”，“１０”，“２０”な
ど）も示している。好ましい実施の形態によると、各ヒ
ープに割り当てられたセグメントも連結リストにおいて
連結・管理されているが、これは必ずしも必要ではな
く、ヒープ、フリーリストおよび順序リストを表すため
にその他の適当なデータ構造が使用されてもよい。図示
例をより明確にするために、割り当てられたセグメント
の連結リストは図示されていない。
【００２０】図５は、複数のヒープから、オブジェクト
ファイルｅ.ｏの最初のバージョン２０２に対応するセ
グメントを削除するために実行されるステップを示すフ
ローチャートである。図示例によると、オブジェクトフ
ァイルｅ.ｏの最初のバージョン２０２に対応するセグ
メントが削除され、オブジェクトファイルｅ.ｏの新た
なバージョン２０４が付加可能になる（図６および図８
〜図１６参照）。先ず、ステップ３０２において、ＣＰ
Ｕ１０２は、順序リスト５０８におけるオブジェクトフ
ァイルｅ.ｏの最初のバージョン２０２のエントリ５１
３を捜し、各ヒープ５０２，５０４，５０６に対するポ
インタにアクセスする（これらのボインタのうちのいく
つかは値が“ゼロ”であることがある）。
ファイルｅ.ｏの最初のバージョン２０２に対応するセ
グメントを削除するために実行されるステップを示すフ
ローチャートである。図示例によると、オブジェクトフ
ァイルｅ.ｏの最初のバージョン２０２に対応するセグ
メントが削除され、オブジェクトファイルｅ.ｏの新た
なバージョン２０４が付加可能になる（図６および図８
〜図１６参照）。先ず、ステップ３０２において、ＣＰ
Ｕ１０２は、順序リスト５０８におけるオブジェクトフ
ァイルｅ.ｏの最初のバージョン２０２のエントリ５１
３を捜し、各ヒープ５０２，５０４，５０６に対するポ
インタにアクセスする（これらのボインタのうちのいく
つかは値が“ゼロ”であることがある）。
【００２１】ステップ３０２では、.SYMBOLSヒープ５０
２において前記オブジェクトファイルｅ.ｏの最初のバ
ージョン２０２のために前に確保されたスペースが、フ
リーリスト５３０に戻される。ステップ３０４では、.S
TABSヒープ５０４において前記オブジェクトファイル
ｅ.ｏの最初のバージョン２０２のために前に確保され
たスペースが、フリーリスト５３２に戻される。また、
ステップ３０６では、.STABSTRヒープ５０６において前
記オブジェクトファイルｅ.ｏの最初のバージョン２０
２のために前に確保されたスペースが、フリーリスト５
３４に戻される。さらに、ステップ３０７では、その他
のヒープにおいて前記オブジェクトファイルｅ.ｏの最
初のバージョン２０２のために前に確保されたスペース
が、対応するフリーリストに戻される。（当業者に理解
されるように、ステップ３０２〜３０７はループとして
実行されてよい）
２において前記オブジェクトファイルｅ.ｏの最初のバ
ージョン２０２のために前に確保されたスペースが、フ
リーリスト５３０に戻される。ステップ３０４では、.S
TABSヒープ５０４において前記オブジェクトファイル
ｅ.ｏの最初のバージョン２０２のために前に確保され
たスペースが、フリーリスト５３２に戻される。また、
ステップ３０６では、.STABSTRヒープ５０６において前
記オブジェクトファイルｅ.ｏの最初のバージョン２０
２のために前に確保されたスペースが、フリーリスト５
３４に戻される。さらに、ステップ３０７では、その他
のヒープにおいて前記オブジェクトファイルｅ.ｏの最
初のバージョン２０２のために前に確保されたスペース
が、対応するフリーリストに戻される。（当業者に理解
されるように、ステップ３０２〜３０７はループとして
実行されてよい）
【００２２】最後に、順序リスト５０８における前記オ
ブジェクトファイルｅ.ｏの最初のバージョン２０２の
ためのエントリ５１３が、前記リスト５０８から削除さ
れる。図８は、前記最初のバージョン２０２が削除され
た後における前記ヒープおよび順序リスト５０８の一例
を示している。なお、図８のヒープ５０２において、
“パッド３”、オブジェクトファイルｅ.ｏの記号のた
めに確保されたスペース、および、“パッド５”のため
に確保されたスペースが組み合わされることによって、
“パッド１０”が形成されている。すなわち、２バイト
のオブジェクトファイルｅ．ｏを削除したことにより、
その前の３バイトの“パッド３”と合わせて５バイトの
空きスペースが生じ、これとその次の５バイトの“パッ
ド５”と合わせて合計１０バイトの空きスペースが生じ
るので、“パッド１０”として示されている。ヒープ５
０４および５０６においても、同様な変更がなされてい
る。さらに、前記オブジェクトファイルｅ.ｏのための
エントリ５１３が、前記リスト５０８から削除されてい
る。
ブジェクトファイルｅ.ｏの最初のバージョン２０２の
ためのエントリ５１３が、前記リスト５０８から削除さ
れる。図８は、前記最初のバージョン２０２が削除され
た後における前記ヒープおよび順序リスト５０８の一例
を示している。なお、図８のヒープ５０２において、
“パッド３”、オブジェクトファイルｅ.ｏの記号のた
めに確保されたスペース、および、“パッド５”のため
に確保されたスペースが組み合わされることによって、
“パッド１０”が形成されている。すなわち、２バイト
のオブジェクトファイルｅ．ｏを削除したことにより、
その前の３バイトの“パッド３”と合わせて５バイトの
空きスペースが生じ、これとその次の５バイトの“パッ
ド５”と合わせて合計１０バイトの空きスペースが生じ
るので、“パッド１０”として示されている。ヒープ５
０４および５０６においても、同様な変更がなされてい
る。さらに、前記オブジェクトファイルｅ.ｏのための
エントリ５１３が、前記リスト５０８から削除されてい
る。
【００２３】図６は、オブジェクトファイルｅ.ｏの新
たなバージョン２０４に関するセグメントを既存の前記
複数のヒープに付加するために、前記ＣＰＵ１０２によ
って実行されるステップを示す図である。図９〜図１６
に示すように、各ヒープは、メモリ１０４に格納された
次のような関連変数を有する。 LO：順序リスト５０８における或る空きスペースの領域
の始めに位置するセグメントを示すために使用されるポ
インタ（すなわち第１ポインタ）。 HI：順序リスト５０８における前記空きスペースの領域
の終わりに位置するセグメントを示すために使用される
ポインタ（すなわち第２ポインタ）。 FIRST_FREE：１つのヒープにおける、前記LOより大きい
が前記HIより小さいアドレスを有する最初の空きセグメ
ントを示す。 LAST_FREE：１つのヒープにおける、前記LOより大きい
が前記HIより小さいアドレスを有する最後の空きセグメ
ントを示す。 MAX_FREE：FIRST_FREEからLAST_FREEまでの領域内の空
きブロックの最大サイズを示す。
たなバージョン２０４に関するセグメントを既存の前記
複数のヒープに付加するために、前記ＣＰＵ１０２によ
って実行されるステップを示す図である。図９〜図１６
に示すように、各ヒープは、メモリ１０４に格納された
次のような関連変数を有する。 LO：順序リスト５０８における或る空きスペースの領域
の始めに位置するセグメントを示すために使用されるポ
インタ（すなわち第１ポインタ）。 HI：順序リスト５０８における前記空きスペースの領域
の終わりに位置するセグメントを示すために使用される
ポインタ（すなわち第２ポインタ）。 FIRST_FREE：１つのヒープにおける、前記LOより大きい
が前記HIより小さいアドレスを有する最初の空きセグメ
ントを示す。 LAST_FREE：１つのヒープにおける、前記LOより大きい
が前記HIより小さいアドレスを有する最後の空きセグメ
ントを示す。 MAX_FREE：FIRST_FREEからLAST_FREEまでの領域内の空
きブロックの最大サイズを示す。
【００２４】図８〜図１６の例において、前記変数LOお
よびHIは、その変数名の前にヒープ名を付することによ
って区別されている。例えば、図において、.STABSヒー
プ５０２のLOポインタおよびHIポインタは、それぞれ、
“.STABS:LO”および“.STABS:HI”として示される。さ
らに、図において、前記FIRST_FREEおよびLAST_FREE
は、それぞれ、“FF”および“LF”と略示されている。
ステップ４０２において、前記ＣＰＵ１０２は、各ヒー
プに割り当てられるべき新たなセグメントのサイズを入
力する。図２〜図４に示したように、セグメントのサイ
ズは、前記オブジェクトファイルｅ.ｏの新たなバージ
ョン２０４の一部である。
よびHIは、その変数名の前にヒープ名を付することによ
って区別されている。例えば、図において、.STABSヒー
プ５０２のLOポインタおよびHIポインタは、それぞれ、
“.STABS:LO”および“.STABS:HI”として示される。さ
らに、図において、前記FIRST_FREEおよびLAST_FREE
は、それぞれ、“FF”および“LF”と略示されている。
ステップ４０２において、前記ＣＰＵ１０２は、各ヒー
プに割り当てられるべき新たなセグメントのサイズを入
力する。図２〜図４に示したように、セグメントのサイ
ズは、前記オブジェクトファイルｅ.ｏの新たなバージ
ョン２０４の一部である。
【００２５】図８〜図１６の図示例では、１５バイト
の.SYMBOLSセグメント、１０バイトの.STABSセグメント
および３０バイトの.STABSTRセグメントを有するオブジ
ェクトファイルｅ.ｏの新たなバージョン２０４に関す
るセグメント割当て処理の一例を示している。ステップ
４０４では、図９に示すように、前記MAX_FREE変数が
“０”に設定される。また、各ヒープのHIポインタは、
順序リスト５０８の先頭を示すよう初期化される。ステ
ップ４０７では、最小HIポインタが、前記順序リスト５
０８における最初のポインタを示すすべてのHIポインタ
であると定義される。図９において、すべての前記HIポ
インタは前記順序リスト５０８の同一のエントリ（すな
わち、前記リスト５０８の始め）を示すので、これらす
べてのHIポインタは、最小HIポインタ組の一員である。
ステップ４０８では、前記LOポインタのすべてが、対応
する前記HIポインタの値に等しくなるよう設定される。
の.SYMBOLSセグメント、１０バイトの.STABSセグメント
および３０バイトの.STABSTRセグメントを有するオブジ
ェクトファイルｅ.ｏの新たなバージョン２０４に関す
るセグメント割当て処理の一例を示している。ステップ
４０４では、図９に示すように、前記MAX_FREE変数が
“０”に設定される。また、各ヒープのHIポインタは、
順序リスト５０８の先頭を示すよう初期化される。ステ
ップ４０７では、最小HIポインタが、前記順序リスト５
０８における最初のポインタを示すすべてのHIポインタ
であると定義される。図９において、すべての前記HIポ
インタは前記順序リスト５０８の同一のエントリ（すな
わち、前記リスト５０８の始め）を示すので、これらす
べてのHIポインタは、最小HIポインタ組の一員である。
ステップ４０８では、前記LOポインタのすべてが、対応
する前記HIポインタの値に等しくなるよう設定される。
【００２６】ステップ４１０（図１０参照）において、
前記ＣＰＵ１０２は、“有意セグメント”をトラバース
することなく歩進可能な値まで各前記HIポインタを進め
る。ここで、“有意セグメント”とは、前記順序リスト
５０８における該セグメントのエントリが、そのHIポイ
ンタに対応するヒープに対するゼロではないポインタ
（非ゼロのポインタ）を含み、且つ、少なくとも１つの
他のヒープに対する非ゼロポインタを含むセグメントと
して定義される。この場合、前記少なくとも１つの他の
ヒープとは、該ヒープに関して現在配置中のセグメント
が非ゼロのポインタを有するヒープのことである。従っ
て、前記順序リスト５０８におけるオブジェクトファイ
ルａ.ｏのエントリ５１２が、３つのHIポインタの各々
に関する有意セグメントである。ステップ４１０では、
図１０に示すように、前記３つのヒープの各々に関する
HIポインタが、前記順序リスト５０８におけるオブジェ
クトファイルａ.ｏのエントリに進められる。ステップ
４１２では、同じく図１０に示すように、各FIRST_FREE
（FF）変数が、対応するヒープに関するフリーリストの
始めに設定される。
前記ＣＰＵ１０２は、“有意セグメント”をトラバース
することなく歩進可能な値まで各前記HIポインタを進め
る。ここで、“有意セグメント”とは、前記順序リスト
５０８における該セグメントのエントリが、そのHIポイ
ンタに対応するヒープに対するゼロではないポインタ
（非ゼロのポインタ）を含み、且つ、少なくとも１つの
他のヒープに対する非ゼロポインタを含むセグメントと
して定義される。この場合、前記少なくとも１つの他の
ヒープとは、該ヒープに関して現在配置中のセグメント
が非ゼロのポインタを有するヒープのことである。従っ
て、前記順序リスト５０８におけるオブジェクトファイ
ルａ.ｏのエントリ５１２が、３つのHIポインタの各々
に関する有意セグメントである。ステップ４１０では、
図１０に示すように、前記３つのヒープの各々に関する
HIポインタが、前記順序リスト５０８におけるオブジェ
クトファイルａ.ｏのエントリに進められる。ステップ
４１２では、同じく図１０に示すように、各FIRST_FREE
（FF）変数が、対応するヒープに関するフリーリストの
始めに設定される。
【００２７】ステップ４１４（図１１参照）では、各LA
ST_FREE（LF）変数が、これに対応するFIRST_FREE変数
に設定される。ステップ４１６および４１８において、
前記ＣＰＵ１０２は、空きセグメントのアドレスを前記
順序リスト５０８における対応するHIポインタのアドレ
スより小さい値に維持しながら、各LAST_FREE変数をそ
のフリーリストに沿って可能な範囲まで進める。従っ
て、図示例においては、どのLAST_FREE（LF）変数も進
められず、該LAST_FREE（LF）変数は、図１１に示すよ
うに、前記フリーリストの先頭に維持される。ステップ
４１６および４１８では、（HIポインタによって示され
た）前記オブジェクトファイルａ.ｏの前における前記
新たなセグメントを挿入するための位置をサーチする。
しかし、どのヒープにも前記オブジェクトファイルａ.
ｏの前にはパッディングが存在しないので、空きスペー
スは見つけられない。
ST_FREE（LF）変数が、これに対応するFIRST_FREE変数
に設定される。ステップ４１６および４１８において、
前記ＣＰＵ１０２は、空きセグメントのアドレスを前記
順序リスト５０８における対応するHIポインタのアドレ
スより小さい値に維持しながら、各LAST_FREE変数をそ
のフリーリストに沿って可能な範囲まで進める。従っ
て、図示例においては、どのLAST_FREE（LF）変数も進
められず、該LAST_FREE（LF）変数は、図１１に示すよ
うに、前記フリーリストの先頭に維持される。ステップ
４１６および４１８では、（HIポインタによって示され
た）前記オブジェクトファイルａ.ｏの前における前記
新たなセグメントを挿入するための位置をサーチする。
しかし、どのヒープにも前記オブジェクトファイルａ.
ｏの前にはパッディングが存在しないので、空きスペー
スは見つけられない。
【００２８】ステップ４２０において、前記ＣＰＵ１０
２は、各ヒープのMAX_FREEを更新する（この場合、すべ
てのMAX_FREE変数は依然として“０”である）。そし
て、ステップ４２２において、ＣＰＵ１０２は、FIRST_
FREEとLAST_FREEとの間のすべての空きスペース（この
場合、無し）を調べ、該空きスペースが求められている
所定量に適合するか否かを判定する。図示例において
は、ステップ４２４では“適合無し”と判定され、ステ
ップ４０７に戻る。その後、ステップ４０７の処理（図
１２参照）を繰り返し、ＣＰＵ１０２は、どのHIポイン
タの更新が必要であるか否かを判定する。ここでは、再
び、すべてのHIポインタが更新される必要がある。ステ
ップ４０８では、各LOポインタをこれに対応するHIポイ
ンタの値に設定し、さらに、ステップ４１０（図１３参
照）では、“有意セグメント”をトラバースすることな
く歩進できる値まで各前記HIポインタを進める。
２は、各ヒープのMAX_FREEを更新する（この場合、すべ
てのMAX_FREE変数は依然として“０”である）。そし
て、ステップ４２２において、ＣＰＵ１０２は、FIRST_
FREEとLAST_FREEとの間のすべての空きスペース（この
場合、無し）を調べ、該空きスペースが求められている
所定量に適合するか否かを判定する。図示例において
は、ステップ４２４では“適合無し”と判定され、ステ
ップ４０７に戻る。その後、ステップ４０７の処理（図
１２参照）を繰り返し、ＣＰＵ１０２は、どのHIポイン
タの更新が必要であるか否かを判定する。ここでは、再
び、すべてのHIポインタが更新される必要がある。ステ
ップ４０８では、各LOポインタをこれに対応するHIポイ
ンタの値に設定し、さらに、ステップ４１０（図１３参
照）では、“有意セグメント”をトラバースすることな
く歩進できる値まで各前記HIポインタを進める。
【００２９】図１３において、前記ヒープ５０２および
５０４のHIポインタ（SYMBOLS:HIおよびSTABS:HI）は、
順序リスト５０８におけるオブジェクトファイルｂ.ｏ
のエントリ５１４に進められている。この場合、該エン
トリ５１４は、ヒープ５０２および少なくも１つの他の
ヒープ（ヒープ５０４）に対する非ゼロのポインタを有
するので、ヒープ５０２のHIポインタに関する有意セグ
メントを表していることになる。また、該エントリ５１
４は、ヒープ５０４および少なくも１つの他のヒープ
（ヒープ５０２）に対する非ゼロのポインタを有するの
で、ヒープ５０４のHIポインタに関する有意セグメント
を表している。
５０４のHIポインタ（SYMBOLS:HIおよびSTABS:HI）は、
順序リスト５０８におけるオブジェクトファイルｂ.ｏ
のエントリ５１４に進められている。この場合、該エン
トリ５１４は、ヒープ５０２および少なくも１つの他の
ヒープ（ヒープ５０４）に対する非ゼロのポインタを有
するので、ヒープ５０２のHIポインタに関する有意セグ
メントを表していることになる。また、該エントリ５１
４は、ヒープ５０４および少なくも１つの他のヒープ
（ヒープ５０２）に対する非ゼロのポインタを有するの
で、ヒープ５０４のHIポインタに関する有意セグメント
を表している。
【００３０】また、図１３において、前記ヒープ５０６
のHIポインタは、順序リスト５０８におけるオブジェク
トファイルｃ.ｏのエントリ５１８に進められている。
この場合、前記オブジェクトファイルｂ.ｏのエントリ
５１４は、ヒープ５０６に対するゼロのポインタを有す
るので、有意セグメントではない。同様に、オブジェク
トファイルｄ.ｏのエントリ５１６は、ヒープ５０６に
対する非ゼロのポインタを有するが、他のヒープに対す
る非ゼロのポインタを有していないので、有意セグメン
トではない。さらに、オブジェクトファイルｃ.ｏのエ
ントリ５１８は、ヒープ５０６および少なくも１つの他
のヒープ（ヒープ５０４および５０６）に対する非ゼロ
のポインタを有するので、ヒープ５０６に関する有意セ
グメントである。ステップ４１２（図１３参照）では、
前記ヒープ５０２および５０４に関するFIRST_FREE変数
が、これに対応するヒープのLOポインタより大きい値に
進められる。
のHIポインタは、順序リスト５０８におけるオブジェク
トファイルｃ.ｏのエントリ５１８に進められている。
この場合、前記オブジェクトファイルｂ.ｏのエントリ
５１４は、ヒープ５０６に対するゼロのポインタを有す
るので、有意セグメントではない。同様に、オブジェク
トファイルｄ.ｏのエントリ５１６は、ヒープ５０６に
対する非ゼロのポインタを有するが、他のヒープに対す
る非ゼロのポインタを有していないので、有意セグメン
トではない。さらに、オブジェクトファイルｃ.ｏのエ
ントリ５１８は、ヒープ５０６および少なくも１つの他
のヒープ（ヒープ５０４および５０６）に対する非ゼロ
のポインタを有するので、ヒープ５０６に関する有意セ
グメントである。ステップ４１２（図１３参照）では、
前記ヒープ５０２および５０４に関するFIRST_FREE変数
が、これに対応するヒープのLOポインタより大きい値に
進められる。
【００３１】ステップ４１４（図１４参照）では、各LA
ST_FREE変数が、これに対応するFIRST_FREE変数に設定
される。ステップ４１６および４１８では、各LAST_FRE
E変数が、そのフリーリストにおける、対応するHIポイ
ンタによって示されるセグメントより小さい最上位のエ
ントリに進められる。こうして、図１４において、ヒー
プ５０２に関するLAST_FREE変数は“パッド１０”（オ
ブジェクトファイルｂ.ｏより小さな値）に維持され、
ヒープ５０４に関するLAST_FREE変数は“パッド２０”
（オブジェクトファイルｂ.ｏより小さな値）に維持さ
れ、ヒープ５０６に関するLAST_FREE変数は“パッド
５”（オブジェクトファイルｃ.ｏより小さな値）を示
す。そして、ステップ４２０では、ヒープ５０２に関す
るMAX_FREE変数が“１０”に更新され、ヒープ５０４に
関するMAX_FREE変数が“２０”に更新され、ヒープ５０
６に関するMAX_FREE変数が“６０”（６０および５の最
大値）に更新される。
ST_FREE変数が、これに対応するFIRST_FREE変数に設定
される。ステップ４１６および４１８では、各LAST_FRE
E変数が、そのフリーリストにおける、対応するHIポイ
ンタによって示されるセグメントより小さい最上位のエ
ントリに進められる。こうして、図１４において、ヒー
プ５０２に関するLAST_FREE変数は“パッド１０”（オ
ブジェクトファイルｂ.ｏより小さな値）に維持され、
ヒープ５０４に関するLAST_FREE変数は“パッド２０”
（オブジェクトファイルｂ.ｏより小さな値）に維持さ
れ、ヒープ５０６に関するLAST_FREE変数は“パッド
５”（オブジェクトファイルｃ.ｏより小さな値）を示
す。そして、ステップ４２０では、ヒープ５０２に関す
るMAX_FREE変数が“１０”に更新され、ヒープ５０４に
関するMAX_FREE変数が“２０”に更新され、ヒープ５０
６に関するMAX_FREE変数が“６０”（６０および５の最
大値）に更新される。
【００３２】オブジェクトファイルｅ.ｏの記号セグメ
ントは１５バイトを必要とし、１０バイトのみが利用可
能であるので、前記ＣＰＵ１０２は、図１４におけるヒ
ープ５０２のFIRST_FREEとLAST_FREEとの間にオブジェ
クトファイルｅ.ｏのセグメントを挿入できない。すな
わち、ステップ４２２および４２４において、各ヒープ
においてFIRST_FREE変数およびLAST_FREE変数によって
形成されるウィンドウには十分な空きスペースが存在し
ていない、ということが前記MAX_FREEによって示される
ので、ステップ４０７に戻る。
ントは１５バイトを必要とし、１０バイトのみが利用可
能であるので、前記ＣＰＵ１０２は、図１４におけるヒ
ープ５０２のFIRST_FREEとLAST_FREEとの間にオブジェ
クトファイルｅ.ｏのセグメントを挿入できない。すな
わち、ステップ４２２および４２４において、各ヒープ
においてFIRST_FREE変数およびLAST_FREE変数によって
形成されるウィンドウには十分な空きスペースが存在し
ていない、ということが前記MAX_FREEによって示される
ので、ステップ４０７に戻る。
【００３３】３回目の繰り返し時において、ステップ４
０８〜４２０の処理は、ヒープ５０２および５０４（図
１４参照）に対応する変数のみについて行われる。ヒー
プ５０６に対応する変数は影響されない。先ず、ステッ
プ４０８（図１５参照）では、ヒープ５０２および５０
４のLOポインタが、これらのヒープ（オブジェクトファ
イルｂ.ｏ）のHIポインタの値に設定される。ステップ
４１０では、ヒープ５０２および５０４に関するFIRST_
FREE変数が、これに対応するヒープのLOポインタより大
きい値に進められる。そして、ステップ４１２では、ヒ
ープ５０２および５０４のHIポインタが、両前記HIポイ
ンタに関する有意セグメントであるオブジェクトファイ
ルｃ.ｏのエントリに進められる。次のステップ４１４
では、個々の前記LAST_FREE変数が前記FIRST_FREE変数
の値に設定される。ステップ４１６および４１８では、
個々の前記LAST_FREE変数が、依然としてHIポインタの
値未満であって、できるだけ大きいに値にインクリメン
トされる。この例において、個々の前記LAST_FREE変数
は、その値が変らない。ステップ４２０において、ヒー
プ５０２および５０４の前記MAX_FREE変数は、それぞ
れ、“２０”および“１５”に更新される。
０８〜４２０の処理は、ヒープ５０２および５０４（図
１４参照）に対応する変数のみについて行われる。ヒー
プ５０６に対応する変数は影響されない。先ず、ステッ
プ４０８（図１５参照）では、ヒープ５０２および５０
４のLOポインタが、これらのヒープ（オブジェクトファ
イルｂ.ｏ）のHIポインタの値に設定される。ステップ
４１０では、ヒープ５０２および５０４に関するFIRST_
FREE変数が、これに対応するヒープのLOポインタより大
きい値に進められる。そして、ステップ４１２では、ヒ
ープ５０２および５０４のHIポインタが、両前記HIポイ
ンタに関する有意セグメントであるオブジェクトファイ
ルｃ.ｏのエントリに進められる。次のステップ４１４
では、個々の前記LAST_FREE変数が前記FIRST_FREE変数
の値に設定される。ステップ４１６および４１８では、
個々の前記LAST_FREE変数が、依然としてHIポインタの
値未満であって、できるだけ大きいに値にインクリメン
トされる。この例において、個々の前記LAST_FREE変数
は、その値が変らない。ステップ４２０において、ヒー
プ５０２および５０４の前記MAX_FREE変数は、それぞ
れ、“２０”および“１５”に更新される。
【００３４】ステップ４２０の実行に続いて、各前記ヒ
ープ５０２，５０４，５０６における最大空きスペース
は、それぞれ、 SYMBOLS:MAX_FREE=２０， STABS:MAX_FREE=１５， STABSTR:MAX_FREE=６０（５および６０の最大値） である。処理目的は前記ヒープ５０２，５０４，５０６
における１５バイト、１０バイトおよび３０バイトをそ
れぞれ見つけることであるので、ステップ４２２および
ステップ４２４の判定結果は“ＹＥＳ”となり、前記オ
ブジェクトファイルｅ.ｏの新たなバージョン２０４のS
YMBOLSセグメント、STABSセグメントおよびSTABSTRセグ
メントが、ステップ４２６において、それぞれのヒープ
の位置１３０２，１３０４および１３０６に付加され
る。図１６は、前記ステップ４２６の処理後の前記ヒー
プ５０２，５０４，５０６の状態を示している。前記オ
ブジェクトファイルｅ.ｏの新たなバージョン２０４の
エントリ５２０が、順序リスト５０８に付加される。な
お、新たなエントリ５２０は、前記順序リスト５０８に
おける、旧いエントリ５１３とは異なる位置を占める。
図５および図６のステップは、インクリメンタルリンカ
１０８によって再リンクされる各修正済オブジェクトフ
ァイルごとに繰り返される。
ープ５０２，５０４，５０６における最大空きスペース
は、それぞれ、 SYMBOLS:MAX_FREE=２０， STABS:MAX_FREE=１５， STABSTR:MAX_FREE=６０（５および６０の最大値） である。処理目的は前記ヒープ５０２，５０４，５０６
における１５バイト、１０バイトおよび３０バイトをそ
れぞれ見つけることであるので、ステップ４２２および
ステップ４２４の判定結果は“ＹＥＳ”となり、前記オ
ブジェクトファイルｅ.ｏの新たなバージョン２０４のS
YMBOLSセグメント、STABSセグメントおよびSTABSTRセグ
メントが、ステップ４２６において、それぞれのヒープ
の位置１３０２，１３０４および１３０６に付加され
る。図１６は、前記ステップ４２６の処理後の前記ヒー
プ５０２，５０４，５０６の状態を示している。前記オ
ブジェクトファイルｅ.ｏの新たなバージョン２０４の
エントリ５２０が、順序リスト５０８に付加される。な
お、新たなエントリ５２０は、前記順序リスト５０８に
おける、旧いエントリ５１３とは異なる位置を占める。
図５および図６のステップは、インクリメンタルリンカ
１０８によって再リンクされる各修正済オブジェクトフ
ァイルごとに繰り返される。
【００３５】図８〜図１６を参照して上記の動作を説明
すると、挿入すべきオブジェクトファイルｅ．ｏのバイ
ト数に対応して、各ヒープに必要とされる空きスペース
として、SYMBOLS部では１５バイト、STABS部では１０バ
イト、STABSTR部では３０バイトが決定され、これらの
必要バイト数を満足するパッドとして、SYMBOLS部では
“パット２０”、STABS部では“パット１５”、STABSTR部
では“パット６０”がそれぞれサーチされる。そして、
サーチされた各ヒープ毎のパッドにおいて１５バイト、
１０バイト、３０バイトの空きスペースがオブジェクト
ファイルｅ．ｏのためにそれぞれ割り当てられ、この割
当スペースに該各オブジェクイファイルｅ．ｏをそれぞ
れ格納する。これにより、格納された各オブジェクトフ
ァイルｅ．ｏの次のエリアにおけるパッドのバイト数は
それぞれの残りのバイト数となり、SYMBOLS部では“パ
ット５”、STABS部では“パット５”、STABSTR部では“パ
ット３０”となる。
すると、挿入すべきオブジェクトファイルｅ．ｏのバイ
ト数に対応して、各ヒープに必要とされる空きスペース
として、SYMBOLS部では１５バイト、STABS部では１０バ
イト、STABSTR部では３０バイトが決定され、これらの
必要バイト数を満足するパッドとして、SYMBOLS部では
“パット２０”、STABS部では“パット１５”、STABSTR部
では“パット６０”がそれぞれサーチされる。そして、
サーチされた各ヒープ毎のパッドにおいて１５バイト、
１０バイト、３０バイトの空きスペースがオブジェクト
ファイルｅ．ｏのためにそれぞれ割り当てられ、この割
当スペースに該各オブジェクイファイルｅ．ｏをそれぞ
れ格納する。これにより、格納された各オブジェクトフ
ァイルｅ．ｏの次のエリアにおけるパッドのバイト数は
それぞれの残りのバイト数となり、SYMBOLS部では“パ
ット５”、STABS部では“パット５”、STABSTR部では“パ
ット３０”となる。
【００３６】図６の実施例において、前記ＣＰＵ１０２
は、ステップ４２２，４２４において最初に見つけられ
る適合を選択する。この発明の他の実施の形態による
と、すべての可能な適合を見つけた後、最適な適合を選
択するようにしてもよい。Peterson and Silberschatz
による“Operating System Concepts 2e”, Addison-We
lsley Publishing（1985年著作権）を参照されたし。さ
らに、明確さのため図には示されていないが、この発明
の少なくとも１つの実施の形態は、順序リスト５０８に
“リスト終わり”エントリを含んでいる。このエントリ
は、１つのヒープにおける最後の部分の後（例えばヒー
プ５０２のオブジェクトファイルｃ.ｏの後）にパディ
ングを割り当てることを可能にする。
は、ステップ４２２，４２４において最初に見つけられ
る適合を選択する。この発明の他の実施の形態による
と、すべての可能な適合を見つけた後、最適な適合を選
択するようにしてもよい。Peterson and Silberschatz
による“Operating System Concepts 2e”, Addison-We
lsley Publishing（1985年著作権）を参照されたし。さ
らに、明確さのため図には示されていないが、この発明
の少なくとも１つの実施の形態は、順序リスト５０８に
“リスト終わり”エントリを含んでいる。このエントリ
は、１つのヒープにおける最後の部分の後（例えばヒー
プ５０２のオブジェクトファイルｃ.ｏの後）にパディ
ングを割り当てることを可能にする。
【００３７】重要なことは、この発明が、順序リスト５
０８に従って、個々のヒープの間においてセグメントの
順序を維持することである。こうして、図１６に示すよ
うに、オブジェクトファイルｅ.ｏの新たなバージョン
２０４に関するセグメントが前記ヒープに付加された後
においても、すべてのヒープは、ａ.ｏ，ｂ.ｏ，ｅ.
ｏ，ｄ.ｏ，ｃ.ｏの順序に対応する。これらのファイル
のいくつかに関するセグメントはいくつかのヒープに存
在しないことがある（例えば、オブジェクトファイル
ｂ.ｏはヒープ５０６には存在しない）が、これらヒー
プにおける関連する各セグメントの順序は決して狂うこ
とがない。図１６には示されていないが、前記ヒープ５
０２，５０４，５０６において新たに付加されたセグメ
ントは、インクリメンタルリンカ１０８によって、実行
可能なファイル１１２の正しいリンクに必要な前記オブ
ジェクトファイルｅ.ｏの新たなバージョン２０４から
のデータによって埋められる。
０８に従って、個々のヒープの間においてセグメントの
順序を維持することである。こうして、図１６に示すよ
うに、オブジェクトファイルｅ.ｏの新たなバージョン
２０４に関するセグメントが前記ヒープに付加された後
においても、すべてのヒープは、ａ.ｏ，ｂ.ｏ，ｅ.
ｏ，ｄ.ｏ，ｃ.ｏの順序に対応する。これらのファイル
のいくつかに関するセグメントはいくつかのヒープに存
在しないことがある（例えば、オブジェクトファイル
ｂ.ｏはヒープ５０６には存在しない）が、これらヒー
プにおける関連する各セグメントの順序は決して狂うこ
とがない。図１６には示されていないが、前記ヒープ５
０２，５０４，５０６において新たに付加されたセグメ
ントは、インクリメンタルリンカ１０８によって、実行
可能なファイル１１２の正しいリンクに必要な前記オブ
ジェクトファイルｅ.ｏの新たなバージョン２０４から
のデータによって埋められる。
【００３８】この発明は、図５および６のステップを実
行するためにＣＰＵによって実行可能な種類のコンピュ
ータ命令を格納したフロッピーディスク、光ディスクま
たはハードディスクなどのコンピュータによって読み取
り可能な媒体である製品にも及ぶものである。要約する
と、この発明は、複数のヒープ間においてデータの順序
を維持しながら、前記複数のヒープに対するデータの削
除および付加を可能にする。以上説明された好ましい実
施の形態において、インクリメンタルリンカによって、
前記ヒープに対するセグメントの削除および付加が行わ
れる。しかし、この発明は、複数のヒープに対するデー
タの削除および付加が行われる場合に、前記ヒープ間に
おける順序を維持することが望ましいいかなる用途にお
いても使用可能である。
行するためにＣＰＵによって実行可能な種類のコンピュ
ータ命令を格納したフロッピーディスク、光ディスクま
たはハードディスクなどのコンピュータによって読み取
り可能な媒体である製品にも及ぶものである。要約する
と、この発明は、複数のヒープ間においてデータの順序
を維持しながら、前記複数のヒープに対するデータの削
除および付加を可能にする。以上説明された好ましい実
施の形態において、インクリメンタルリンカによって、
前記ヒープに対するセグメントの削除および付加が行わ
れる。しかし、この発明は、複数のヒープに対するデー
タの削除および付加が行われる場合に、前記ヒープ間に
おける順序を維持することが望ましいいかなる用途にお
いても使用可能である。
【００３９】
【発明の効果】以上のように、この発明は、複数のヒー
プ間においてデータの順序を維持しながら、前記複数の
ヒープに対するデータの削除および付加を可能にし、こ
れにより、オブジェクトファイルの新たな再リンクが行
われる毎に完全に新しい実行可能なファイルを作成する
必要性を除去できる、という優れた効果を奏する。
プ間においてデータの順序を維持しながら、前記複数の
ヒープに対するデータの削除および付加を可能にし、こ
れにより、オブジェクトファイルの新たな再リンクが行
われる毎に完全に新しい実行可能なファイルを作成する
必要性を除去できる、という優れた効果を奏する。
【図１】この発明の好ましい実施の形態に係るデータ処
理システムのブロック図。
理システムのブロック図。
【図２】図１におけるインクリメンタルリンカの入出力
を示すブロック図。
を示すブロック図。
【図３】オブジェクトファイルの最初のバージョンが修
正されることによって、該オブジェクトファイルの新た
なバージョンが生成される動作を示す図。
正されることによって、該オブジェクトファイルの新た
なバージョンが生成される動作を示す図。
【図４】オブジェクトファイルの修正後、該オブジェク
トファイルの再リンクが行われる動作を示す図。
トファイルの再リンクが行われる動作を示す図。
【図５】図１におけるメモリにおける複数のヒープから
複数のセグメントを削除するステップを示すフローチャ
ート。
複数のセグメントを削除するステップを示すフローチャ
ート。
【図６】複数のヒープ間におけるデータ順序を維持しな
がら、前記ヒープに対して複数のセグメントを付加する
ステップを示すフローチャート。
がら、前記ヒープに対して複数のセグメントを付加する
ステップを示すフローチャート。
【図７】複数のヒープに複数のセグメントが付加された
後における、図１のコンピュータメモリのデータ構造の
初期状態を示す図。
後における、図１のコンピュータメモリのデータ構造の
初期状態を示す図。
【図８】複数のヒープから複数のセグメントを削除した
後における、図７のデータ構造の一例を示す図。
後における、図７のデータ構造の一例を示す図。
【図９】複数のヒープに対する複数のセグメントの付加
を説明する図８のデータ構造の一例を示す図。
を説明する図８のデータ構造の一例を示す図。
【図１０】複数のヒープに対する複数のセグメントの付
加を説明する図９のデータ構造の変更例を示す図。
加を説明する図９のデータ構造の変更例を示す図。
【図１１】複数のヒープに対する複数のセグメントの付
加を説明する図１０のデータ構造の変更例を示す図。
加を説明する図１０のデータ構造の変更例を示す図。
【図１２】複数のヒープに対する複数のセグメントの付
加を説明する図１１のデータ構造の変更例を示す図。
加を説明する図１１のデータ構造の変更例を示す図。
【図１３】複数のヒープに対する複数のセグメントの付
加を説明する図１２のデータ構造の変更例を示す図。
加を説明する図１２のデータ構造の変更例を示す図。
【図１４】複数のヒープに対する複数のセグメントの付
加を説明する図１３のデータ構造の変更例を示す図。
加を説明する図１３のデータ構造の変更例を示す図。
【図１５】複数のヒープに対する複数のセグメントの付
加を説明する図１４のデータ構造の変更例を示す図。
加を説明する図１４のデータ構造の変更例を示す図。
【図１６】複数のヒープに対する複数のセグメントの付
加を説明する図１５のデータ構造の変更例を示す図。
加を説明する図１５のデータ構造の変更例を示す図。
１００ データ処理システム １０２ ＣＰＵ １０４ メモリ １０８ インクリメンタルリンカ １１０ オブジェクトファイル １１２ 実行可能なファイル
フロントページの続き (72)発明者 クリストファー ディー クイネル アメリカ合衆国 94043 カリフォルニア, マウンテンビュー，ロータスレーン 452
Claims (20)
- 【請求項１】 データ処理システムのメモリに格納され
た複数のヒープにおけるエントリを操作する装置であっ
て、 前記各ヒープ毎に必要とされる空きスペースの量をそれ
ぞれ決定する手段と、 前記各ヒープにおけるエントリの順序が各ヒープ間で維
持されるよう、前記各必要とされる空きスペースの量を
前記各ヒープに割り当てる手段とを具備した装置。 - 【請求項２】 前記複数のヒープに対応して前記メモリ
に格納された各々の空きリストから、前記割り当てられ
た空きスペースの量を除去する手段をさらに具備した請
求項１に記載の装置。 - 【請求項３】 各ヒープにおける割当てスペース量の割
り当てを解除する手段をさらに具備しており、割り当て
を解除された各スペース量が、前記複数のヒープにおけ
る同一の相対順序にあることを特徴とする請求項１に記
載の装置。 - 【請求項４】 前記複数のヒープに対応して前記メモリ
に格納された各々の空きリストに対して、前記割り当て
を解除されたスペース量を戻す手段を含む請求項３に記
載の装置。 - 【請求項５】 データ処理システムのメモリに格納され
た複数のヒープの各々における所定量の空きスペースを
見つけるために、前記データ処理システムによって実行
される方法であって、 前記各ヒープがそれに関連するLOポインタおよびHIポイ
ンタ（すなわち第１および第２ポインタ）を有するよ
う、各ヒープ毎の該LOポインタおよびHIポインタをそれ
ぞれ設定するステップと、 少なくとも１つの前記LOポインタを、これに対応する前
記HIポインタと等しい値になるように進めるステップ
と、 前記対応する少なくとも１つのHIポインタを、前記複数
のヒープにおける該HIポインタに関する次の有意セグメ
ントを指示するように進めるステップと、 前記各ヒープにおける各関連する前記LOポインタとHIポ
インタとの間に前記所定量の空きスペースが存在するか
否かを判定するステップとを具備する方法。 - 【請求項６】 すべての前記HIポインタとLOポインタと
の間に前記所定量の空きスペースが見つかった場合、少
なくとも１つの前記ヒープにおいて見つけられた前記空
きスペースにセグメントを付加するステップをさらに含
む請求項５に記載の方法。 - 【請求項７】 前記所定量の空きスペースが見つかるま
で、または、前記関連するHIポインタが各々の前記ヒー
プの終わりに到達するまで、前記設定するステップと前
記進めるステップと前記判定するステップとを繰り返す
ことをさらに含む請求項５に記載の方法。 - 【請求項８】 １つの前記ヒープにおける２番目の有意
セグメントを示すよう、少なくとも１つの前記HIポイン
タを進めるステップをさらに含み、前記２番目の有意セ
グメントが、そのヒープにおける１番目の有意セグメン
トの位置より高位に位置するものである請求項５に記載
の方法。 - 【請求項９】 前記少なくとも１つのLOポインタを進め
るステップが、少なくとも１つの最小HIポインタに対応
する少なくとも１つのLOポインタを、これに対応する最
小HIポインタの値に等しくなるよう進めるステップと、 前記少なくとも１つのHIポインタを進めるステップが、
少なくとも１つの対応する最小HIポインタを、前記複数
のヒープにおける前記少なくとも１つの最小HIポインタ
に関する次のセグメントを示すよう進めるステップとを
含む請求項５に記載の方法。 - 【請求項１０】 すべての前記HIポインタとLOポインタ
との間に前記所定量の空きスペースが見つからなかった
場合、対応する最小HIポインタを有さないヒープに関連
する前記LOポインタの現在値を維持し、最小HIポインタ
ではない対応するHIポインタの現在値を維持するステッ
プをさらに含む請求項９に記載の方法。 - 【請求項１１】 有意セグメントが、HIポインタに関連
するヒープを指示すると共に少なくとも１つの他のヒー
プを指示するエントリを有するセグメントである請求項
５に記載の方法。 - 【請求項１２】 各前記ヒープにおける空きスペース
が、連結リストにおいて連結されている請求項５に記載
の方法。 - 【請求項１３】 前記所定量の空きスペースが、各前記
ヒープごとに同じである請求項５に記載の方法。 - 【請求項１４】 前記所定量の空きスペースが、各前記
ヒープごとに異なる量である請求項５に記載の方法。 - 【請求項１５】 前記判定するステップが、 関連するLOポインタとHIポインタとの間における前記空
きスペースの各ブロックを、最大のものから最小のもの
に至る順にチェックするステップと、 前記所定量の空きスペースと同じ大きさを有する空きス
ペースの１番目のブロックを使用するステップとを含む
請求項１４に記載の方法。 - 【請求項１６】 前記判定するステップが、 関連するLOポインタとHIポインタとの間における前記空
きスペースの各ブロックを、最大のものから最小のもの
まで至る順にチェックするステップと、 前記所定量の空きスペースと同じ大きさを有する空きス
ペースの最大ブロックを使用するステップとを含む請求
項１４に記載の方法。 - 【請求項１７】 前記複数のヒープのうちの少なくとも
２つが、異なるサイズである請求項５に記載の方法。 - 【請求項１８】 “割り当て（Ｖ）”の形態からなる入
力シーケンスを受け取るステップをさらに含み、ここ
で、“Ｖ”が整数ベクトルであり、各整数が、対応する
ヒープに割り当てられる必要があるスペースの量を示す
ものである請求項５に記載の方法。 - 【請求項１９】 前記入力に“空き（i）”のコマンド
を挿入するステップをさらに含み、ここで、前記“i”
が、前記入力ストリームにおけるｉ番目の割当てを示
し、前記“割り当て”に関連するメモリが空き状態にさ
れるべきことを示すものである請求項５に記載の方法。 - 【請求項２０】 複数のヒープの各々に割り当てられる
べきスペースの量をそれぞれ示す複数の所定値を受け取
るステップと、 前記複数のヒープにおいて、前記各割り当てられるべき
スペース量を有するそれぞれの位置を検出するステップ
と、 前記それぞれの位置が前記複数ヒープ間において同じ順
序を維持するように、該それぞれの位置を割り当てるス
テップとを具備する方法を実行するためのプログラムを
記憶してなるコンピュータによって読み取り可能な記憶
媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/436,101 US5787447A (en) | 1995-05-08 | 1995-05-08 | Memory allocation maintaining ordering across multiple heaps |
| US08/436101 | 1995-05-08 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH09204297A true JPH09204297A (ja) | 1997-08-05 |
Family
ID=23731114
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP8139572A Pending JPH09204297A (ja) | 1995-05-08 | 1996-05-08 | 複数のヒープにおいて順序を維持してメモリ割り当てを行うための装置および方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5787447A (ja) |
| EP (1) | EP0742519B1 (ja) |
| JP (1) | JPH09204297A (ja) |
| CA (1) | CA2173819A1 (ja) |
| DE (1) | DE69615606T2 (ja) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6718550B1 (en) | 1996-06-26 | 2004-04-06 | Sun Microsystems, Inc. | Method and apparatus for improving the performance of object invocation |
| US6076151A (en) | 1997-10-10 | 2000-06-13 | Advanced Micro Devices, Inc. | Dynamic memory allocation suitable for stride-based prefetching |
| US6065130A (en) * | 1997-12-01 | 2000-05-16 | Telefonaktiebolaget Lm Ericsson | Implementing counters in a system with limited primary memory |
| US6438616B1 (en) | 1997-12-18 | 2002-08-20 | Sun Microsystems, Inc. | Method and apparatus for fast, local corba object references |
| US6516354B2 (en) | 1997-12-18 | 2003-02-04 | Sun Microsystems, Inc. | Method and apparatus for efficient representation of variable length identifiers in a distributed object system |
| US6016489A (en) * | 1997-12-18 | 2000-01-18 | Sun Microsystems, Inc. | Method and apparatus for constructing stable iterators in a shared data collection |
| US6249803B1 (en) | 1997-12-18 | 2001-06-19 | Sun Microsystems, Inc. | Method and apparatus for executing code during method invocation |
| US6510460B1 (en) | 1997-12-18 | 2003-01-21 | Sun Microsystems, Inc. | Method and apparatus for enforcing locking invariants in multi-threaded systems |
| US6480862B1 (en) * | 1999-04-23 | 2002-11-12 | International Business Machines Corporation | Relation-based ordering of objects in an object heap |
| US6408368B1 (en) | 1999-06-15 | 2002-06-18 | Sun Microsystems, Inc. | Operating system page placement to maximize cache data reuse |
| US6366994B1 (en) | 1999-06-22 | 2002-04-02 | Sun Microsystems, Inc. | Cache aware memory allocation |
| US6407469B1 (en) * | 1999-11-30 | 2002-06-18 | Balboa Instruments, Inc. | Controller system for pool and/or spa |
| US6865585B1 (en) * | 2000-07-31 | 2005-03-08 | Microsoft Corporation | Method and system for multiprocessor garbage collection |
| US6457023B1 (en) * | 2000-12-28 | 2002-09-24 | International Business Machines Corporation | Estimation of object lifetime using static analysis |
| US20030004922A1 (en) * | 2001-06-27 | 2003-01-02 | Ontrack Data International, Inc. | System and method for data management |
| US6499094B1 (en) * | 2001-09-14 | 2002-12-24 | Unisys Corporation | Management of memory heap space for data files accessible to programs operating in different addressing modes |
| US7185167B2 (en) * | 2003-06-06 | 2007-02-27 | Microsoft Corporation | Heap allocation |
| WO2010010597A1 (ja) * | 2008-07-23 | 2010-01-28 | 富士通株式会社 | 静的にリンクされた実行形式プログラムファイルにおけるオブジェクトを結合するオブジェクト結合装置、オブジェクトの結合方法およびそのプログラム |
| CN103399774A (zh) * | 2013-07-29 | 2013-11-20 | 华为技术有限公司 | 链接方法及链接器及计算机系统 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4757438A (en) * | 1984-07-12 | 1988-07-12 | Texas Instruments Incorporated | Computer system enabling automatic memory management operations |
| US4920483A (en) * | 1985-11-15 | 1990-04-24 | Data General Corporation | A computer memory for accessing any word-sized group of contiguous bits |
| US5222221A (en) * | 1986-06-17 | 1993-06-22 | Yeda Research And Development Co., Ltd. | Method and apparatus for implementing a concurrent logic program |
| US4989134A (en) * | 1987-03-20 | 1991-01-29 | Hewlett-Packard Company | Method and apparatus for enhancing data storage efficiency |
| US5088036A (en) * | 1989-01-17 | 1992-02-11 | Digital Equipment Corporation | Real time, concurrent garbage collection system and method |
| US5182806A (en) * | 1989-06-30 | 1993-01-26 | Digital Equipment Corporation | Incremental compiler for source-code development system |
| US5325531A (en) * | 1989-06-30 | 1994-06-28 | Digital Equipment Corporation | Compiler using clean lines table with entries indicating unchanged text lines for incrementally compiling only changed source text lines |
| US5321834A (en) * | 1989-11-28 | 1994-06-14 | Xerox Corporation | Method and system for reclaiming unreferenced computer memory space |
| JPH04506720A (ja) * | 1990-03-23 | 1992-11-19 | イーストマン・コダック・カンパニー | ディジタル・データ処理システムのための仮想メモリ管理及び割付け装置 |
| US5193180A (en) * | 1991-06-21 | 1993-03-09 | Pure Software Inc. | System for modifying relocatable object code files to monitor accesses to dynamically allocated memory |
| US5355483A (en) * | 1991-07-18 | 1994-10-11 | Next Computers | Asynchronous garbage collection |
| DE69327089T2 (de) * | 1992-07-24 | 2000-04-13 | Microsoft Corp., Redmond | Rechnerverfahren und system zur zuordnung und zur freigabe von speichern. |
| US5560003A (en) * | 1992-12-21 | 1996-09-24 | Iowa State University Research Foundation, Inc. | System and hardware module for incremental real time garbage collection and memory management |
| US5519866A (en) * | 1993-06-28 | 1996-05-21 | Taligent, Inc. | Method and apparatus of incrementally linking components of a modeled computer program |
| US5408650A (en) * | 1993-06-29 | 1995-04-18 | Digital Equipment Corporation | Memory analysis system for dynamically displaying memory allocation and de-allocation events associated with an application program |
| US5566321A (en) * | 1993-12-13 | 1996-10-15 | Cray Research, Inc. | Method of managing distributed memory within a massively parallel processing system |
-
1995
- 1995-05-08 US US08/436,101 patent/US5787447A/en not_active Expired - Fee Related
-
1996
- 1996-04-10 CA CA002173819A patent/CA2173819A1/en not_active Abandoned
- 1996-05-07 EP EP96107173A patent/EP0742519B1/en not_active Expired - Lifetime
- 1996-05-07 DE DE69615606T patent/DE69615606T2/de not_active Expired - Fee Related
- 1996-05-08 JP JP8139572A patent/JPH09204297A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP0742519B1 (en) | 2001-10-04 |
| EP0742519A3 (en) | 1997-08-06 |
| DE69615606T2 (de) | 2002-07-11 |
| EP0742519A2 (en) | 1996-11-13 |
| CA2173819A1 (en) | 1996-11-09 |
| US5787447A (en) | 1998-07-28 |
| DE69615606D1 (de) | 2001-11-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH09204297A (ja) | 複数のヒープにおいて順序を維持してメモリ割り当てを行うための装置および方法 | |
| EP0390900B1 (en) | Generic code sharing arrangement for digital data processing system | |
| US5303392A (en) | Accessing current symbol definitions in a dynamically configurable operating system | |
| US6643711B2 (en) | Method and apparatus for dispatch table construction | |
| EP1086419B1 (en) | A method of and system for implementing parameterized types to be compatible with existing unparameterized libraries | |
| US6219830B1 (en) | Relocatable object code format and method for loading same into a computer system | |
| US5764987A (en) | Relocatable file format and method and apparatus for creating and loading same | |
| US4587628A (en) | Method and apparatus for dynamic invocation of utilities | |
| US20030093420A1 (en) | Method and system for retrieving sharable information using a hierarchically dependent directory structure | |
| EP0777177A1 (en) | A method for object-oriented programming using dynamic interfaces | |
| JP2003526827A (ja) | ソフトウェアコードを圧縮するためのシステムおよび方法 | |
| JPH1069408A (ja) | ホールを利用するファイルシステムレベルでのデータ格納方法及びデータ格納装置 | |
| JPH10198587A (ja) | ファイル・システムの間接アドレシング方法及び装置 | |
| EP0237637B1 (en) | A method for the relocation of linked control blocks | |
| US5842223A (en) | Method and apparatus for information state management | |
| US5832507A (en) | Method and apparatus for converting ASCII path names to parsed path name structures | |
| US5889995A (en) | Using constant selectors for method identification | |
| JP2000029674A (ja) | アプリケ―ションソフトウェア構成方法 | |
| JPH06110703A (ja) | コンパイル方法 | |
| US6009272A (en) | Register allocation via selective spilling | |
| JP2002534737A (ja) | 低減されたメモリ条件でプログラムコードを実行するための装置 | |
| Barnard et al. | Hierarchic syntax error repair for LR grammars | |
| JP3166699B2 (ja) | オブジェクト指向プログラム設計支援装置、方法および記録媒体 | |
| EP0633525B1 (en) | Method for compilation of programming languages | |
| JP3090048B2 (ja) | 標準プログラムの機能拡張方法及び方式 |