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
Application number
JP8139572A
Other languages
English (en)
Inventor
Neil G Smithline
ジー スミスライン ニール
Christopher D Quenelle
ディー クイネル クリストファー
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.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
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 Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of JPH09204297A publication Critical patent/JPH09204297A/ja
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/54Link editing before load time
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free 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

【発明の詳細な説明】
【0001】
【発明の属する技術分野】この発明は、データ処理シス
テムにおけるメモリ管理に関し、特に、複数のヒープの
間におけるデータの順序を一定に維持しながら該複数の
ヒープにおけるデータの付加および削除を行うことがで
きるようにした装置および方法に関する。
【0002】
【従来の技術】各種のソフトウエアプログラムは、情報
を“ヒープ”という形態でメモリに格納している。この
ヒープとは、データの集合のことである。ヒープは、ア
レイ、リンク(連結)リストとして、または、当業者に
知られているその他の適当なデータ構造として実現され
ることができる。従来のソフトウエアプログラムの多く
は、該プログラムに必要なデータを格納するためのヒー
プ群を作成する。通常、ソフトウエアプログラムの実行
開始時に空きヒープが作成され、該ソフトウエアプログ
ラムの実行が進行するのに伴って、該ヒープにデータが
付加される。
【0003】“リンカ(linker)”ソフトウエアプログ
ラムは、1つまたは複数の“オブジェクトファイル”を
単一の“実行可能なファイル”に併合するものである。
従来のリンカソフトウエアは実行時に複数のリストを作
成し、各前記リストは、リンクされるオブジェクトファ
イルの特定種類のデータを格納する。前記リンカは、各
オブジェクトファイルからのセグメントを入力順に取り
込み、適当なリストの終わりに付加する。従来のリンカ
は、新たな再リンクが行われる毎に、完全に新しい実行
可能なファイルを作成する。
【0004】
【発明が解決しようとする課題】しかし、最後(最近)
のリンク動作実行後において、複数のオブジェクトファ
イルのうちの一部のみが変更されているのにすぎないの
で、このような従来技術のように新たな再リンクが行わ
れる毎に完全に新しい実行可能なファイルを作成するこ
とは、効率的ではない。この発明は上述の点に鑑みてな
されたもので、複数のヒープ間においてデータの順序を
維持しながら、該ヒープに対するデータの削除および付
加を可能にし、これにより、オブジェクトファイルの新
たな再リンクが行われる毎に完全に新しい実行可能なフ
ァイルを作成する必要性を除去しようとするものであ
る。
【0005】
【課題を解決するための手段】上記目的を達成するた
め、この発明に係る装置は、データ処理システムのメモ
リに格納された複数のヒープにおけるエントリを操作す
る装置であって、前記各ヒープ毎に必要とされる空きス
ペースの量をそれぞれ決定する手段と、前記各ヒープに
おけるエントリの順序が各ヒープ間で維持されるよう、
前記各必要とされる空きスペースの量を前記各ヒープに
割り当てる手段とを具備するものである。
【0006】さらに、この発明に係る方法は、データ処
理システムのメモリに格納された複数のヒープの各々に
おける所定量の空きスペースを見つけるために、前記デ
ータ処理システムによって実行される方法であって、前
記各ヒープがそれに関連するLOポインタおよびHIポイン
タ(すなわち第1および第2ポインタ)を有するよう、
各ヒープ毎の該LOポインタおよびHIポインタをそれぞれ
設定するステップと、少なくとも1つの前記LOポインタ
を、これに対応する前記HIポインタと等しい値になるよ
うに進めるステップと、前記対応する少なくとも1つの
HIポインタを、前記複数のヒープにおける該HIポインタ
に関する次の有意セグメントを指示するように進めるス
テップと、前記各ヒープにおける各関連する前記LOポイ
ンタとHIポインタとの間に前記所定量の空きスペースが
存在するか否かを判定するステップとを具備するもので
ある。
【0007】さらに、この発明は、複数のヒープの各々
に割り当てられるべきスペースの量をそれぞれ示す複数
の所定値を受け取るステップと、前記複数のヒープにお
いて、前記各割り当てられるべきスペース量を有するそ
れぞれの位置を検出するステップと、前記それぞれの位
置が前記複数ヒープ間において同じ順序を維持するよう
に、該それぞれの位置を割り当てるステップとを具備す
る方法を実行するためのプログラムを記憶してなるコン
ピュータによって読み取り可能な記憶媒体からなるもの
である。
【0008】この発明は、複数のヒープに対するデータ
の削除および付加が行われるときに、前記複数のヒープ
の間でその順序を維持してメモリ割り当てを行うことが
できるものである。ある用途においては、データの削除
および付加が行われるときに複数のヒープ間でその順序
を維持することが望まれるので、そのような用途におい
て本発明を有利に応用することができる。“セグメン
ト”とは、1つのヒープにおけるデータの1ブロックで
ある。1つのヒープにおける各セグメントは、その他の
ヒープの各々に0個または1個の関連するセグメントを
有する。この発明の順序制御によって、たとえば1つの
ヒープにおけるセグメント[i]がセグメント[i+
1]の前にある場合には、前記セグメント[i]および
セグメント[i+1]を含むすべてのヒープにおいて、
前記セグメント[i]に関連するセグメントは、前記セ
グメント[i+1]に関連するセグメントの前に位置す
る、ことが保証される。
【0009】複数の関連するデータセグメントを複数の
ヒープにおける対応するセグメントに挿入する、という
ことがしばしば必要になる。前記複数のヒープのデータ
の順序が維持されるために必要なことは、或る1つのデ
ータセグメントを或る1つのヒープの途中に挿入可能で
あるのは、他の各ヒープの対応する位置に他の関連する
データセグメントを挿入する余地がある場合にのみに限
る、ということである。以下では、この発明は、インク
リメンタルリンカ・ソフトウエアプログラムにおけるヒ
ープに関して説明されている。しかし、当業者に理解さ
れるように、この発明は、複数のヒープ間において順序
を維持することが有用な他の分野においても適用可能で
ある。この発明は、“有意セグメント”という観念を使
用することによって、複数のヒープに対するデータの付
加および削除が行われるときに前記複数のヒープ間にお
いてその順序が維持されるよう、前記複数のヒープに関
連する複数のポインタを操作する発明である。この発明
の作用と効果は、図面を参照して以下で行う発明の実施
の形態の詳細な説明によってより一層明らかになる。
【0010】
【発明の実施の形態】以下、添付図面を参照してこの発
明の一実施の形態を詳細に説明する。図1は、CPU1
02と、該CPU102に接続されたメモリ104とを
備えたデータ処理システム100を示す図である。明確
さのため図示されていないが、該データ処理システム1
00は、各種の入出力装置、周辺機器、ネットワーク接
続装置、メモリ、他のCPU等を備えていてもよい。
【0011】前記メモリ104は、UNIXオペレーティン
グシステムの下に実行されるインクリメンタルリンカで
あるのが好ましいインクリメンタルリンカ・ソフトウエ
アプログラムを格納している。前記UNIXは、米国および
その他の国において、X/OPEN, Ltd.によって独占的にラ
イセンスされている登録商標である。Sun Microsystem
s,Inc.では、該Sun Microsystems,Inc.の登録商標であ
るSolarisという名前でUNIXの一バージョンを製造して
いる。さらに、前記メモリ104は、1つまたは複数の
オブジェクトファイル110、および、1つまたは複数
のインクリメントタルリンクされた実行可能なファイル
112を格納している。各前記実行可能なファイル11
2は、以下に詳述するヒープ、フリーセグメントリスト
および順序リストのような各種データ構造を含んでい
る。
【0012】図2〜図4に示すように、オブジェクトフ
ァイル110はインクリメンタルリンカ108に入力さ
れ、該リンカ108は実行可能なファイル112を修正
する。この実施の形態に係るインクリメンタルリンカ1
08は、オブジェクトファイル間のリンクが実行される
毎にすべてのオブジェクトファイル110の再リンクを
行なわない、という点において従来のリンカとは異なっ
ている。また、該インクリメンタルリンカ108は、前
回のリンク動作からのすべての旧いデータを実行可能な
ファイル112にセーブし、前回のリンク動作後修正さ
れたオブジェクトファイルのみについて新たなデータを
生成するものである。前記リンカ108に対して入出力
される前記ファイル110,112のフォーマットは、
当業者に知られており、“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年)に詳細に記載されてい
る。
【0013】好ましい実施の形態において、この発明が
インクリメンタルリンカ108に適用される場合、実行
可能なファイル112における各ヒープ、および、各オ
ブジェクトファイルにおける各セグメントは、ELF(Exe
cutable and Linking Format)部に対応する。一般的
に、各オブジェクトファイル110は、複数のELF部を
該ELF部のサイズと共に有している。これらは、リンク
動作時において、前のファイル112と共にマージされ
ることによって、インクリメンタルリンクされたファイ
ル112のELF部を形成する(図4参照)。
【0014】図2は、インクリメンタルリンカ108の
入出力を示すブロック図である。図示のように、前記イ
ンクリメンタルリンカ108は、初期入力として、オブ
ジェクトファイルa.o,e.o,b.o,d.o,c.o
を取り込む。図3は、オブジェクトファイルe.oの最
初のバージョン202が修正されることによって、該オ
ブジェクトファイルe.oの新たな(修正済の)バージ
ョン204が生成される動作を示している。図4に示す
ように、前記オブジェクトファイルe.oの修正後、該
オブジェクトファイルの再リンクが行われる。この再リ
ンク時において、前記オブジェクトファイルe.oの最
初のバージョン202に関するすべてのデータが、前記
実行可能なファイル112から削除され、前記新たなバ
ージョン204に関する新たなデータが、前記実行可能
なファイル112に付加されることになる。
【0015】図5は、メモリ104における複数のヒー
プから、前記オブジェクトファイルe.oの最初のバー
ジョン202に対応するセグメントを削除するステップ
を示すフローチャートである。また、図6は、メモリ1
04における複数のヒープに対して、オブジェクトファ
イルe.oの新たなバージョン204に対応するセグメ
ントを付加するステップを示すフローチャートである。
これら図5および図6については、図7〜図16の図示
例に関連して後で詳述する。なお、図5および図6のス
テップは、インクリメンタルリンカ108の命令を実行
し、前記メモリ104に格納されたデータ構造を使用す
るCPU102によって行われる。
【0016】以下の説明は、図5および図6のフローチ
ャートを参照して図7〜図16の図示例を説明するもの
である。図7は3つのヒープ502,504,506を
示している。なお、当業者に理解されるように、この発
明は任意数のヒープについて実施されてよい。図7およ
び図8は、前記オブジェクトファイルe.oの最初のバ
ージョン202のセグメントを複数のヒープから削除す
る例を示すものである。また、図8〜図16は、ヒープ
間におけるセグメントの順序を維持しながら、前記オブ
ジェクトファイルe.oの新たなバージョン204のセ
グメントを前記複数のヒープに付加する例を示す。
【0017】図示例において、ヒープ502は、前記オ
ブジェクトファイルa.o,e.o,b.o,c.oについ
ての記号部(.SYMBOLS)に対応し、同様に、ヒープ50
4は、前記オブジェクトファイルa.o,e.o,b.
o,c.oについてのデバッグ情報部(.STABS)に対応
する。さらに、ヒープ506は、前記オブジェクトファ
イルa.o,e.o,d.o,c.oについてのデバッグ情
報ストリングテーブル部(.STABSTR)に対応する。各ヒ
ープ(ELF部)におけるエントリは“セグメント”と呼
ばれている。なお、ヒープ502および504にはオブ
ジェクトファイルd.oのセグメントは存在していな
い。同様に、ヒープ506にはオブジェクトファイル
b.oのセグメントは存在していない。前記複数のヒー
プは同一のオブジェクトファイルに関するデータを含ま
ないが、各前記ヒープにおけるセグメントは、順序リス
ト508に従って順序付けられている。
【0018】図7に示すように、前記順序リスト508
は、6つのエントリ、すなわち、該リストのヘッダとし
ての第1のエントリ510と、ヒープ502、504、
506に対するポインタを有するオブジェクトファイル
a.oのエントリ512と、ヒープ502、504、5
06に対するポインタを有するオブジェクトファイル
e.oのエントリ513と、ヒープ502、504に対
するポインタを有するが、ヒープ506に対するポイン
タを有さないオブジェクトファイルb.oのエントリ5
14と、ヒープ506に対するポインタのみを有するオ
ブジェクトファイルd.oのエントリ516と、各前記
ヒープ502、504、506に対するポインタを有す
るオブジェクトファイルc.oのエントリ518とを含
んでいる。このように、図7は、オブジェクトファイル
a.o,e.o(最初のバージョン202)のリンク後の
インクリメンタルリンカ108におけるデータ構造を示
している。
【0019】各前記ヒープ502、504、506は、
例えばセグメント520のような複数のセグメントを含
んでおり、もっとも好ましくは、これらのセグメント
は、1つまたは複数のフリーバイト(free byte: 空き
バイト)からなるパディング、例えばパディング(パッ
ド)522、によって分離されている。図7において、
“パッド”という用語の後の数は、そのパディングエリ
アのバイト数を示している。各ヒープにおけるパディン
グエリアは、“フリーリスト”(free list: 空きリス
ト)530、532、534と呼ばれる連結リスト(li
nked list)において連結・管理されている。また、図
7では、各ヒープにおける、オブジェクトファイルe.
oの最初のバージョン202の個々のセグメントにおけ
るバイト数(すなわち、“2”,“10”,“20”な
ど)も示している。好ましい実施の形態によると、各ヒ
ープに割り当てられたセグメントも連結リストにおいて
連結・管理されているが、これは必ずしも必要ではな
く、ヒープ、フリーリストおよび順序リストを表すため
にその他の適当なデータ構造が使用されてもよい。図示
例をより明確にするために、割り当てられたセグメント
の連結リストは図示されていない。
【0020】図5は、複数のヒープから、オブジェクト
ファイルe.oの最初のバージョン202に対応するセ
グメントを削除するために実行されるステップを示すフ
ローチャートである。図示例によると、オブジェクトフ
ァイルe.oの最初のバージョン202に対応するセグ
メントが削除され、オブジェクトファイルe.oの新た
なバージョン204が付加可能になる(図6および図8
〜図16参照)。先ず、ステップ302において、CP
U102は、順序リスト508におけるオブジェクトフ
ァイルe.oの最初のバージョン202のエントリ51
3を捜し、各ヒープ502,504,506に対するポ
インタにアクセスする(これらのボインタのうちのいく
つかは値が“ゼロ”であることがある)。
【0021】ステップ302では、.SYMBOLSヒープ50
2において前記オブジェクトファイルe.oの最初のバ
ージョン202のために前に確保されたスペースが、フ
リーリスト530に戻される。ステップ304では、.S
TABSヒープ504において前記オブジェクトファイル
e.oの最初のバージョン202のために前に確保され
たスペースが、フリーリスト532に戻される。また、
ステップ306では、.STABSTRヒープ506において前
記オブジェクトファイルe.oの最初のバージョン20
2のために前に確保されたスペースが、フリーリスト5
34に戻される。さらに、ステップ307では、その他
のヒープにおいて前記オブジェクトファイルe.oの最
初のバージョン202のために前に確保されたスペース
が、対応するフリーリストに戻される。(当業者に理解
されるように、ステップ302〜307はループとして
実行されてよい)
【0022】最後に、順序リスト508における前記オ
ブジェクトファイルe.oの最初のバージョン202の
ためのエントリ513が、前記リスト508から削除さ
れる。図8は、前記最初のバージョン202が削除され
た後における前記ヒープおよび順序リスト508の一例
を示している。なお、図8のヒープ502において、
“パッド3”、オブジェクトファイルe.oの記号のた
めに確保されたスペース、および、“パッド5”のため
に確保されたスペースが組み合わされることによって、
“パッド10”が形成されている。すなわち、2バイト
のオブジェクトファイルe.oを削除したことにより、
その前の3バイトの“パッド3”と合わせて5バイトの
空きスペースが生じ、これとその次の5バイトの“パッ
ド5”と合わせて合計10バイトの空きスペースが生じ
るので、“パッド10”として示されている。ヒープ5
04および506においても、同様な変更がなされてい
る。さらに、前記オブジェクトファイルe.oのための
エントリ513が、前記リスト508から削除されてい
る。
【0023】図6は、オブジェクトファイルe.oの新
たなバージョン204に関するセグメントを既存の前記
複数のヒープに付加するために、前記CPU102によ
って実行されるステップを示す図である。図9〜図16
に示すように、各ヒープは、メモリ104に格納された
次のような関連変数を有する。 LO:順序リスト508における或る空きスペースの領域
の始めに位置するセグメントを示すために使用されるポ
インタ(すなわち第1ポインタ)。 HI:順序リスト508における前記空きスペースの領域
の終わりに位置するセグメントを示すために使用される
ポインタ(すなわち第2ポインタ)。 FIRST_FREE:1つのヒープにおける、前記LOより大きい
が前記HIより小さいアドレスを有する最初の空きセグメ
ントを示す。 LAST_FREE:1つのヒープにおける、前記LOより大きい
が前記HIより小さいアドレスを有する最後の空きセグメ
ントを示す。 MAX_FREE:FIRST_FREEからLAST_FREEまでの領域内の空
きブロックの最大サイズを示す。
【0024】図8〜図16の例において、前記変数LOお
よびHIは、その変数名の前にヒープ名を付することによ
って区別されている。例えば、図において、.STABSヒー
プ502のLOポインタおよびHIポインタは、それぞれ、
“.STABS:LO”および“.STABS:HI”として示される。さ
らに、図において、前記FIRST_FREEおよびLAST_FREE
は、それぞれ、“FF”および“LF”と略示されている。
ステップ402において、前記CPU102は、各ヒー
プに割り当てられるべき新たなセグメントのサイズを入
力する。図2〜図4に示したように、セグメントのサイ
ズは、前記オブジェクトファイルe.oの新たなバージ
ョン204の一部である。
【0025】図8〜図16の図示例では、15バイト
の.SYMBOLSセグメント、10バイトの.STABSセグメント
および30バイトの.STABSTRセグメントを有するオブジ
ェクトファイルe.oの新たなバージョン204に関す
るセグメント割当て処理の一例を示している。ステップ
404では、図9に示すように、前記MAX_FREE変数が
“0”に設定される。また、各ヒープのHIポインタは、
順序リスト508の先頭を示すよう初期化される。ステ
ップ407では、最小HIポインタが、前記順序リスト5
08における最初のポインタを示すすべてのHIポインタ
であると定義される。図9において、すべての前記HIポ
インタは前記順序リスト508の同一のエントリ(すな
わち、前記リスト508の始め)を示すので、これらす
べてのHIポインタは、最小HIポインタ組の一員である。
ステップ408では、前記LOポインタのすべてが、対応
する前記HIポインタの値に等しくなるよう設定される。
【0026】ステップ410(図10参照)において、
前記CPU102は、“有意セグメント”をトラバース
することなく歩進可能な値まで各前記HIポインタを進め
る。ここで、“有意セグメント”とは、前記順序リスト
508における該セグメントのエントリが、そのHIポイ
ンタに対応するヒープに対するゼロではないポインタ
(非ゼロのポインタ)を含み、且つ、少なくとも1つの
他のヒープに対する非ゼロポインタを含むセグメントと
して定義される。この場合、前記少なくとも1つの他の
ヒープとは、該ヒープに関して現在配置中のセグメント
が非ゼロのポインタを有するヒープのことである。従っ
て、前記順序リスト508におけるオブジェクトファイ
ルa.oのエントリ512が、3つのHIポインタの各々
に関する有意セグメントである。ステップ410では、
図10に示すように、前記3つのヒープの各々に関する
HIポインタが、前記順序リスト508におけるオブジェ
クトファイルa.oのエントリに進められる。ステップ
412では、同じく図10に示すように、各FIRST_FREE
(FF)変数が、対応するヒープに関するフリーリストの
始めに設定される。
【0027】ステップ414(図11参照)では、各LA
ST_FREE(LF)変数が、これに対応するFIRST_FREE変数
に設定される。ステップ416および418において、
前記CPU102は、空きセグメントのアドレスを前記
順序リスト508における対応するHIポインタのアドレ
スより小さい値に維持しながら、各LAST_FREE変数をそ
のフリーリストに沿って可能な範囲まで進める。従っ
て、図示例においては、どのLAST_FREE(LF)変数も進
められず、該LAST_FREE(LF)変数は、図11に示すよ
うに、前記フリーリストの先頭に維持される。ステップ
416および418では、(HIポインタによって示され
た)前記オブジェクトファイルa.oの前における前記
新たなセグメントを挿入するための位置をサーチする。
しかし、どのヒープにも前記オブジェクトファイルa.
oの前にはパッディングが存在しないので、空きスペー
スは見つけられない。
【0028】ステップ420において、前記CPU10
2は、各ヒープのMAX_FREEを更新する(この場合、すべ
てのMAX_FREE変数は依然として“0”である)。そし
て、ステップ422において、CPU102は、FIRST_
FREEとLAST_FREEとの間のすべての空きスペース(この
場合、無し)を調べ、該空きスペースが求められている
所定量に適合するか否かを判定する。図示例において
は、ステップ424では“適合無し”と判定され、ステ
ップ407に戻る。その後、ステップ407の処理(図
12参照)を繰り返し、CPU102は、どのHIポイン
タの更新が必要であるか否かを判定する。ここでは、再
び、すべてのHIポインタが更新される必要がある。ステ
ップ408では、各LOポインタをこれに対応するHIポイ
ンタの値に設定し、さらに、ステップ410(図13参
照)では、“有意セグメント”をトラバースすることな
く歩進できる値まで各前記HIポインタを進める。
【0029】図13において、前記ヒープ502および
504のHIポインタ(SYMBOLS:HIおよびSTABS:HI)は、
順序リスト508におけるオブジェクトファイルb.o
のエントリ514に進められている。この場合、該エン
トリ514は、ヒープ502および少なくも1つの他の
ヒープ(ヒープ504)に対する非ゼロのポインタを有
するので、ヒープ502のHIポインタに関する有意セグ
メントを表していることになる。また、該エントリ51
4は、ヒープ504および少なくも1つの他のヒープ
(ヒープ502)に対する非ゼロのポインタを有するの
で、ヒープ504のHIポインタに関する有意セグメント
を表している。
【0030】また、図13において、前記ヒープ506
のHIポインタは、順序リスト508におけるオブジェク
トファイルc.oのエントリ518に進められている。
この場合、前記オブジェクトファイルb.oのエントリ
514は、ヒープ506に対するゼロのポインタを有す
るので、有意セグメントではない。同様に、オブジェク
トファイルd.oのエントリ516は、ヒープ506に
対する非ゼロのポインタを有するが、他のヒープに対す
る非ゼロのポインタを有していないので、有意セグメン
トではない。さらに、オブジェクトファイルc.oのエ
ントリ518は、ヒープ506および少なくも1つの他
のヒープ(ヒープ504および506)に対する非ゼロ
のポインタを有するので、ヒープ506に関する有意セ
グメントである。ステップ412(図13参照)では、
前記ヒープ502および504に関するFIRST_FREE変数
が、これに対応するヒープのLOポインタより大きい値に
進められる。
【0031】ステップ414(図14参照)では、各LA
ST_FREE変数が、これに対応するFIRST_FREE変数に設定
される。ステップ416および418では、各LAST_FRE
E変数が、そのフリーリストにおける、対応するHIポイ
ンタによって示されるセグメントより小さい最上位のエ
ントリに進められる。こうして、図14において、ヒー
プ502に関するLAST_FREE変数は“パッド10”(オ
ブジェクトファイルb.oより小さな値)に維持され、
ヒープ504に関するLAST_FREE変数は“パッド20”
(オブジェクトファイルb.oより小さな値)に維持さ
れ、ヒープ506に関するLAST_FREE変数は“パッド
5”(オブジェクトファイルc.oより小さな値)を示
す。そして、ステップ420では、ヒープ502に関す
るMAX_FREE変数が“10”に更新され、ヒープ504に
関するMAX_FREE変数が“20”に更新され、ヒープ50
6に関するMAX_FREE変数が“60”(60および5の最
大値)に更新される。
【0032】オブジェクトファイルe.oの記号セグメ
ントは15バイトを必要とし、10バイトのみが利用可
能であるので、前記CPU102は、図14におけるヒ
ープ502のFIRST_FREEとLAST_FREEとの間にオブジェ
クトファイルe.oのセグメントを挿入できない。すな
わち、ステップ422および424において、各ヒープ
においてFIRST_FREE変数およびLAST_FREE変数によって
形成されるウィンドウには十分な空きスペースが存在し
ていない、ということが前記MAX_FREEによって示される
ので、ステップ407に戻る。
【0033】3回目の繰り返し時において、ステップ4
08〜420の処理は、ヒープ502および504(図
14参照)に対応する変数のみについて行われる。ヒー
プ506に対応する変数は影響されない。先ず、ステッ
プ408(図15参照)では、ヒープ502および50
4のLOポインタが、これらのヒープ(オブジェクトファ
イルb.o)のHIポインタの値に設定される。ステップ
410では、ヒープ502および504に関するFIRST_
FREE変数が、これに対応するヒープのLOポインタより大
きい値に進められる。そして、ステップ412では、ヒ
ープ502および504のHIポインタが、両前記HIポイ
ンタに関する有意セグメントであるオブジェクトファイ
ルc.oのエントリに進められる。次のステップ414
では、個々の前記LAST_FREE変数が前記FIRST_FREE変数
の値に設定される。ステップ416および418では、
個々の前記LAST_FREE変数が、依然としてHIポインタの
値未満であって、できるだけ大きいに値にインクリメン
トされる。この例において、個々の前記LAST_FREE変数
は、その値が変らない。ステップ420において、ヒー
プ502および504の前記MAX_FREE変数は、それぞ
れ、“20”および“15”に更新される。
【0034】ステップ420の実行に続いて、各前記ヒ
ープ502,504,506における最大空きスペース
は、それぞれ、 SYMBOLS:MAX_FREE=20, STABS:MAX_FREE=15, STABSTR:MAX_FREE=60(5および60の最大値) である。処理目的は前記ヒープ502,504,506
における15バイト、10バイトおよび30バイトをそ
れぞれ見つけることであるので、ステップ422および
ステップ424の判定結果は“YES”となり、前記オ
ブジェクトファイルe.oの新たなバージョン204のS
YMBOLSセグメント、STABSセグメントおよびSTABSTRセグ
メントが、ステップ426において、それぞれのヒープ
の位置1302,1304および1306に付加され
る。図16は、前記ステップ426の処理後の前記ヒー
プ502,504,506の状態を示している。前記オ
ブジェクトファイルe.oの新たなバージョン204の
エントリ520が、順序リスト508に付加される。な
お、新たなエントリ520は、前記順序リスト508に
おける、旧いエントリ513とは異なる位置を占める。
図5および図6のステップは、インクリメンタルリンカ
108によって再リンクされる各修正済オブジェクトフ
ァイルごとに繰り返される。
【0035】図8〜図16を参照して上記の動作を説明
すると、挿入すべきオブジェクトファイルe.oのバイ
ト数に対応して、各ヒープに必要とされる空きスペース
として、SYMBOLS部では15バイト、STABS部では10バ
イト、STABSTR部では30バイトが決定され、これらの
必要バイト数を満足するパッドとして、SYMBOLS部では
“パット20”、STABS部では“パット15”、STABSTR部
では“パット60”がそれぞれサーチされる。そして、
サーチされた各ヒープ毎のパッドにおいて15バイト、
10バイト、30バイトの空きスペースがオブジェクト
ファイルe.oのためにそれぞれ割り当てられ、この割
当スペースに該各オブジェクイファイルe.oをそれぞ
れ格納する。これにより、格納された各オブジェクトフ
ァイルe.oの次のエリアにおけるパッドのバイト数は
それぞれの残りのバイト数となり、SYMBOLS部では“パ
ット5”、STABS部では“パット5”、STABSTR部では“パ
ット30”となる。
【0036】図6の実施例において、前記CPU102
は、ステップ422,424において最初に見つけられ
る適合を選択する。この発明の他の実施の形態による
と、すべての可能な適合を見つけた後、最適な適合を選
択するようにしてもよい。Peterson and Silberschatz
による“Operating System Concepts 2e”, Addison-We
lsley Publishing(1985年著作権)を参照されたし。さ
らに、明確さのため図には示されていないが、この発明
の少なくとも1つの実施の形態は、順序リスト508に
“リスト終わり”エントリを含んでいる。このエントリ
は、1つのヒープにおける最後の部分の後(例えばヒー
プ502のオブジェクトファイルc.oの後)にパディ
ングを割り当てることを可能にする。
【0037】重要なことは、この発明が、順序リスト5
08に従って、個々のヒープの間においてセグメントの
順序を維持することである。こうして、図16に示すよ
うに、オブジェクトファイルe.oの新たなバージョン
204に関するセグメントが前記ヒープに付加された後
においても、すべてのヒープは、a.o,b.o,e.
o,d.o,c.oの順序に対応する。これらのファイル
のいくつかに関するセグメントはいくつかのヒープに存
在しないことがある(例えば、オブジェクトファイル
b.oはヒープ506には存在しない)が、これらヒー
プにおける関連する各セグメントの順序は決して狂うこ
とがない。図16には示されていないが、前記ヒープ5
02,504,506において新たに付加されたセグメ
ントは、インクリメンタルリンカ108によって、実行
可能なファイル112の正しいリンクに必要な前記オブ
ジェクトファイルe.oの新たなバージョン204から
のデータによって埋められる。
【0038】この発明は、図5および6のステップを実
行するためにCPUによって実行可能な種類のコンピュ
ータ命令を格納したフロッピーディスク、光ディスクま
たはハードディスクなどのコンピュータによって読み取
り可能な媒体である製品にも及ぶものである。要約する
と、この発明は、複数のヒープ間においてデータの順序
を維持しながら、前記複数のヒープに対するデータの削
除および付加を可能にする。以上説明された好ましい実
施の形態において、インクリメンタルリンカによって、
前記ヒープに対するセグメントの削除および付加が行わ
れる。しかし、この発明は、複数のヒープに対するデー
タの削除および付加が行われる場合に、前記ヒープ間に
おける順序を維持することが望ましいいかなる用途にお
いても使用可能である。
【0039】
【発明の効果】以上のように、この発明は、複数のヒー
プ間においてデータの順序を維持しながら、前記複数の
ヒープに対するデータの削除および付加を可能にし、こ
れにより、オブジェクトファイルの新たな再リンクが行
われる毎に完全に新しい実行可能なファイルを作成する
必要性を除去できる、という優れた効果を奏する。
【図面の簡単な説明】
【図1】この発明の好ましい実施の形態に係るデータ処
理システムのブロック図。
【図2】図1におけるインクリメンタルリンカの入出力
を示すブロック図。
【図3】オブジェクトファイルの最初のバージョンが修
正されることによって、該オブジェクトファイルの新た
なバージョンが生成される動作を示す図。
【図4】オブジェクトファイルの修正後、該オブジェク
トファイルの再リンクが行われる動作を示す図。
【図5】図1におけるメモリにおける複数のヒープから
複数のセグメントを削除するステップを示すフローチャ
ート。
【図6】複数のヒープ間におけるデータ順序を維持しな
がら、前記ヒープに対して複数のセグメントを付加する
ステップを示すフローチャート。
【図7】複数のヒープに複数のセグメントが付加された
後における、図1のコンピュータメモリのデータ構造の
初期状態を示す図。
【図8】複数のヒープから複数のセグメントを削除した
後における、図7のデータ構造の一例を示す図。
【図9】複数のヒープに対する複数のセグメントの付加
を説明する図8のデータ構造の一例を示す図。
【図10】複数のヒープに対する複数のセグメントの付
加を説明する図9のデータ構造の変更例を示す図。
【図11】複数のヒープに対する複数のセグメントの付
加を説明する図10のデータ構造の変更例を示す図。
【図12】複数のヒープに対する複数のセグメントの付
加を説明する図11のデータ構造の変更例を示す図。
【図13】複数のヒープに対する複数のセグメントの付
加を説明する図12のデータ構造の変更例を示す図。
【図14】複数のヒープに対する複数のセグメントの付
加を説明する図13のデータ構造の変更例を示す図。
【図15】複数のヒープに対する複数のセグメントの付
加を説明する図14のデータ構造の変更例を示す図。
【図16】複数のヒープに対する複数のセグメントの付
加を説明する図15のデータ構造の変更例を示す図。
【符号の説明】
100 データ処理システム 102 CPU 104 メモリ 108 インクリメンタルリンカ 110 オブジェクトファイル 112 実行可能なファイル
フロントページの続き (72)発明者 クリストファー ディー クイネル アメリカ合衆国 94043 カリフォルニア, マウンテンビュー,ロータスレーン 452

Claims (20)

    【特許請求の範囲】
  1. 【請求項1】 データ処理システムのメモリに格納され
    た複数のヒープにおけるエントリを操作する装置であっ
    て、 前記各ヒープ毎に必要とされる空きスペースの量をそれ
    ぞれ決定する手段と、 前記各ヒープにおけるエントリの順序が各ヒープ間で維
    持されるよう、前記各必要とされる空きスペースの量を
    前記各ヒープに割り当てる手段とを具備した装置。
  2. 【請求項2】 前記複数のヒープに対応して前記メモリ
    に格納された各々の空きリストから、前記割り当てられ
    た空きスペースの量を除去する手段をさらに具備した請
    求項1に記載の装置。
  3. 【請求項3】 各ヒープにおける割当てスペース量の割
    り当てを解除する手段をさらに具備しており、割り当て
    を解除された各スペース量が、前記複数のヒープにおけ
    る同一の相対順序にあることを特徴とする請求項1に記
    載の装置。
  4. 【請求項4】 前記複数のヒープに対応して前記メモリ
    に格納された各々の空きリストに対して、前記割り当て
    を解除されたスペース量を戻す手段を含む請求項3に記
    載の装置。
  5. 【請求項5】 データ処理システムのメモリに格納され
    た複数のヒープの各々における所定量の空きスペースを
    見つけるために、前記データ処理システムによって実行
    される方法であって、 前記各ヒープがそれに関連するLOポインタおよびHIポイ
    ンタ(すなわち第1および第2ポインタ)を有するよ
    う、各ヒープ毎の該LOポインタおよびHIポインタをそれ
    ぞれ設定するステップと、 少なくとも1つの前記LOポインタを、これに対応する前
    記HIポインタと等しい値になるように進めるステップ
    と、 前記対応する少なくとも1つのHIポインタを、前記複数
    のヒープにおける該HIポインタに関する次の有意セグメ
    ントを指示するように進めるステップと、 前記各ヒープにおける各関連する前記LOポインタとHIポ
    インタとの間に前記所定量の空きスペースが存在するか
    否かを判定するステップとを具備する方法。
  6. 【請求項6】 すべての前記HIポインタとLOポインタと
    の間に前記所定量の空きスペースが見つかった場合、少
    なくとも1つの前記ヒープにおいて見つけられた前記空
    きスペースにセグメントを付加するステップをさらに含
    む請求項5に記載の方法。
  7. 【請求項7】 前記所定量の空きスペースが見つかるま
    で、または、前記関連するHIポインタが各々の前記ヒー
    プの終わりに到達するまで、前記設定するステップと前
    記進めるステップと前記判定するステップとを繰り返す
    ことをさらに含む請求項5に記載の方法。
  8. 【請求項8】 1つの前記ヒープにおける2番目の有意
    セグメントを示すよう、少なくとも1つの前記HIポイン
    タを進めるステップをさらに含み、前記2番目の有意セ
    グメントが、そのヒープにおける1番目の有意セグメン
    トの位置より高位に位置するものである請求項5に記載
    の方法。
  9. 【請求項9】 前記少なくとも1つのLOポインタを進め
    るステップが、少なくとも1つの最小HIポインタに対応
    する少なくとも1つのLOポインタを、これに対応する最
    小HIポインタの値に等しくなるよう進めるステップと、 前記少なくとも1つのHIポインタを進めるステップが、
    少なくとも1つの対応する最小HIポインタを、前記複数
    のヒープにおける前記少なくとも1つの最小HIポインタ
    に関する次のセグメントを示すよう進めるステップとを
    含む請求項5に記載の方法。
  10. 【請求項10】 すべての前記HIポインタとLOポインタ
    との間に前記所定量の空きスペースが見つからなかった
    場合、対応する最小HIポインタを有さないヒープに関連
    する前記LOポインタの現在値を維持し、最小HIポインタ
    ではない対応するHIポインタの現在値を維持するステッ
    プをさらに含む請求項9に記載の方法。
  11. 【請求項11】 有意セグメントが、HIポインタに関連
    するヒープを指示すると共に少なくとも1つの他のヒー
    プを指示するエントリを有するセグメントである請求項
    5に記載の方法。
  12. 【請求項12】 各前記ヒープにおける空きスペース
    が、連結リストにおいて連結されている請求項5に記載
    の方法。
  13. 【請求項13】 前記所定量の空きスペースが、各前記
    ヒープごとに同じである請求項5に記載の方法。
  14. 【請求項14】 前記所定量の空きスペースが、各前記
    ヒープごとに異なる量である請求項5に記載の方法。
  15. 【請求項15】 前記判定するステップが、 関連するLOポインタとHIポインタとの間における前記空
    きスペースの各ブロックを、最大のものから最小のもの
    に至る順にチェックするステップと、 前記所定量の空きスペースと同じ大きさを有する空きス
    ペースの1番目のブロックを使用するステップとを含む
    請求項14に記載の方法。
  16. 【請求項16】 前記判定するステップが、 関連するLOポインタとHIポインタとの間における前記空
    きスペースの各ブロックを、最大のものから最小のもの
    まで至る順にチェックするステップと、 前記所定量の空きスペースと同じ大きさを有する空きス
    ペースの最大ブロックを使用するステップとを含む請求
    項14に記載の方法。
  17. 【請求項17】 前記複数のヒープのうちの少なくとも
    2つが、異なるサイズである請求項5に記載の方法。
  18. 【請求項18】 “割り当て(V)”の形態からなる入
    力シーケンスを受け取るステップをさらに含み、ここ
    で、“V”が整数ベクトルであり、各整数が、対応する
    ヒープに割り当てられる必要があるスペースの量を示す
    ものである請求項5に記載の方法。
  19. 【請求項19】 前記入力に“空き(i)”のコマンド
    を挿入するステップをさらに含み、ここで、前記“i”
    が、前記入力ストリームにおけるi番目の割当てを示
    し、前記“割り当て”に関連するメモリが空き状態にさ
    れるべきことを示すものである請求項5に記載の方法。
  20. 【請求項20】 複数のヒープの各々に割り当てられる
    べきスペースの量をそれぞれ示す複数の所定値を受け取
    るステップと、 前記複数のヒープにおいて、前記各割り当てられるべき
    スペース量を有するそれぞれの位置を検出するステップ
    と、 前記それぞれの位置が前記複数ヒープ間において同じ順
    序を維持するように、該それぞれの位置を割り当てるス
    テップとを具備する方法を実行するためのプログラムを
    記憶してなるコンピュータによって読み取り可能な記憶
    媒体。
JP8139572A 1995-05-08 1996-05-08 複数のヒープにおいて順序を維持してメモリ割り当てを行うための装置および方法 Pending JPH09204297A (ja)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

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) 標準プログラムの機能拡張方法及び方式