JP3422743B2 - メモリ使用効率を増すための方法 - Google Patents

メモリ使用効率を増すための方法

Info

Publication number
JP3422743B2
JP3422743B2 JP2000031065A JP2000031065A JP3422743B2 JP 3422743 B2 JP3422743 B2 JP 3422743B2 JP 2000031065 A JP2000031065 A JP 2000031065A JP 2000031065 A JP2000031065 A JP 2000031065A JP 3422743 B2 JP3422743 B2 JP 3422743B2
Authority
JP
Japan
Prior art keywords
memory
data
heap manager
data structure
size
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
Application number
JP2000031065A
Other languages
English (en)
Other versions
JP2000242551A (ja
Inventor
ピーター・エフ・スウィーニー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2000242551A publication Critical patent/JP2000242551A/ja
Application granted granted Critical
Publication of JP3422743B2 publication Critical patent/JP3422743B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System (AREA)

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、一般にメモリ管理
に関し、より詳細には明示的なメモリ管理に関する。具
体的には、要求されたメモリの特性に基づくメモリ管理
のための方法および装置が提供される。
【０００２】
【従来の技術】コンピュータ・プログラムは、通常、デ
ータを操作して結果を計算するアルゴリズムである。デ
ータを記憶するためのメモリ・ブロックをまず割り振っ
ておかなければ、データを操作することができない。デ
ータがもはや不要になった場合、そのメモリ・ブロック
は割振り解除または解放される。メモリ・ブロックの割
振りおよび割振り解除は一般にメモリ管理と呼ばれる。
【０００３】一部のプログラミング言語（すなわち、
Ｃ、パスカル、Ａｄａ、Ｃ＋＋、．．．）では、プログ
ラマはメモリ管理を明示的に制御することができる。こ
のようなプログラミング言語の中には、コンパイル時に
データ構造の存続時間が未知のものであるか、データ構
造のサイズが未知のものであるか、またはデータ構造を
割り振るプログラム領域の存続時間がデータ構造の存続
時間より前に終了する場合、プログラマによる明示メモ
リ管理を必要とするもの（すなわち、Ｃ、パスカル、Ｃ
＋＋）もある。このようなメモリ・アロケータは動的記
憶アロケータと呼ばれることもある。というのは、情報
が実行時にのみ把握される場合、メモリを明示的に管理
しなければならないからである。
【０００４】通常、オペレーティング・システムはプロ
グラミング言語に対してメモリ管理サービスを提供す
る。アプリケーションは、このサービスを使用してメモ
リを明示的に管理し、空きストアまたはヒープと呼ばれ
る未使用メモリ・ストアからメモリ・ブロックを割り振
ることができる。このサービスは一般にヒープ（heap）
・マネージャと呼ばれる。
【０００５】ヒープ・マネージャは、すでに割り振られ
たメモリ・ブロックの割振り解除を行うために、任意の
順序で要求が散在している任意のサイズのメモリ・ブロ
ックを割り振る。通常、割り振られた各メモリ・ブロッ
クは割り振られた他のメモリ・ブロックにオーバラップ
することはなく、ヒープ・マネージャはそのブロック内
に記憶されたデータのタイプまたは値とは無関係に１つ
の記憶ブロック全体のみの割振りまたは割振り解除を行
う。プログラミング言語によっては（すなわち、Ｃ、パ
スカル、Ａｄａ、Ｃ＋＋）、データが記憶されているメ
モリ・ブロックは、そのデータが使用されている間、小
型メモリに再割振りすることができない。というのは、
ヒープ・マネージャは、そのメモリ・ブロックが再割振
りされた場合、そのメモリ・ブロックを指すポインタを
見つけて更新することができないからである。
【０００６】多くのコンピュータ・アーキテクチャで
は、メモリ内の位置合せされていないデータ記憶域にア
クセスすることによってパフォーマンス上の不利益を被
る。データ・タイプがメモリ内の適切な境界上にない場
合、記憶されたデータは位置合せされない。たとえば、
位置合せ要件が４バイトのワードである場合、その開始
アドレスが４で割り切れると、記憶されたデータは「位
置合せされる」。位置合せされていないメモリにアクセ
スすることによるパフォーマンス上の不利益としては、
追加の命令サイクル、不十分なキャッシュ使用効率、ま
たは実行パイプラインへのバブルの導入あるいはこれら
の組合せを含む場合がある。
【０００７】図１は、データ構造１０２を記憶するため
にヒープ・マネージャによって割り振られるメモリ・ブ
ロック１００の一例を示している。データ構造１０２
は、２つの文字（ｃｈａｒ）型データ・ユニット１０
４、１０８と、１つの整数（ｉｎｔ）型データ・ユニッ
ト１０６とを含む。各ｃｈａｒ型データ・ユニット１０
４、１０８は１バイトの記憶域を必要とし、各ｉｎｔ型
データ・ユニット１０６は４バイト（１ワード）の記憶
域を必要とする。データ・ユニット１０４、１０６、１
０８は、ｃｈａｒ、ｉｎｔ、ｃｈａｒの順序でデータ構
造１０２内に配置されている。
【０００８】コンパイラは、データ構造１０２が位置合
せ境界上で始まり、位置合せ境界上で終わることを保証
することにより、適切に位置合せされたデータ構造１０
２を提供することができる。データ構造１０２に対応す
る位置合せ要件は、そのデータ・ユニット１０４、１０
６、１０８のうちのいずれか１つの最大サイズである。
したがって、データ構造１０２に対応する位置合せ要件
は４バイトになる。というのは、ｉｎｔ型データ・ユニ
ット１０６が４バイトのサイズを有し、ｃｈａｒ型デー
タ・ユニット１０４、１０８より大きいからである。
【０００９】データ構造１０２に含まれる各データ・ユ
ニット１０４、１０６、１０８は、４バイトというデー
タ構造１０２の位置合せ要件に応じて位置合せされる。
したがって、ｃｈａｒ型データ・ユニット１０４の後に
は３バイトの埋込み１０５が続き、他のｃｈａｒ型デー
タ・ユニット１０８の後にも３バイトの埋込み１０９が
続く。したがって、わずか６バイトの合計サイズを有す
るだけのデータ・ユニット１０４、１０６、１０８を記
憶するために１２バイトのメモリを使用する。
【００１０】ヒープ・マネージャは、ヒープ・マネージ
ャの位置合せ要件に応じてメモリ・ブロック１００を割
り振る。可能なすべてのメモリ要求のためのメモリ・ア
クセスを位置合せするために、ヒープ・マネージャの位
置合せ要件は、可能なすべてのメモリ要求に関する最大
データ・ユニットのサイズに匹敵する。図１に示す例で
は、ヒープ・マネージャの位置合せ要件は８バイト（ダ
ブル・ワード）である。
【００１１】メモリ・ブロック１００は、割り振られた
メモリのサイズを示すヘッダ・サイズ１１０とヘッダ埋
込み１１２とを含む、ヘッダ１１１を含む。この例で
は、ヘッダ・サイズ１１０は４バイトであり、ヘッダ埋
込み１１２は４バイトである。データ構造１０２が位置
合せ境界（ダブル・ワード）上で始まるように、ヘッダ
埋込み１１２は必要である。メモリ・ブロック１００の
終わりにある４バイトの内部断片化１１４により、ブロ
ック１００はダブル・ワード位置合せ境界上で終わるこ
とができる。
【００１２】
【発明が解決しようとする課題】内部断片化と大きいヘ
ッダは未使用データでメモリを汚染する場合があり、そ
の結果、メモリ使用効率が不十分になる可能性がある。
たとえば、データ・キャッシュおよびページング・メモ
リは有限リソースである。データ・キャッシュまたはペ
ージング・メモリ内に記憶された未使用データは、使用
データを無理に押し出す場合があり、その結果、押し出
されたデータに再アクセスした場合にコストが高くなる
可能性がある。
【００１３】
【課題を解決するための手段】メモリ使用効率を改善す
るための方法は、複数のデータ構造のそれぞれに対応す
る位置合せ要件を測定することを含む。データ・メモリ
内の複数のデータ構造からなる記憶域は、位置合せ要件
に基づいて配置される。
【００１４】
【発明の実施の形態】次に添付図面を参照すると、同様
の参照番号は全体を通して同様の要素を示し、図２は本
発明によるメモリ管理を実現するためのコンピュータ・
システム２００を示している。コンピュータ・システム
２００はコンピュータ・プラットフォーム２０４を含
む。そのコンピュータ・プラットフォーム２０４上で
は、１つまたは複数のアプリケーション・プログラム２
０２とオペレーティング・システム２０８が動作する。
コンピュータ・プラットフォーム２０４はハードウェア
・ユニット２１２を含む。ハードウェア・ユニット２１
２は、１つまたは複数の中央演算処理装置（ＣＰＵ）２
１６と、ランダム・アクセス・メモリ（ＲＡＭ）２１４
と、入出力（Ｉ／Ｏ）インタフェース２１８とを含む。
端末２２６、データ記憶装置２３０、印刷装置２３４な
どの周辺構成要素をコンピュータ・プラットフォーム２
０４に接続することができる。本発明によるオペレーテ
ィング・システム２０８はアプリケーション・プログラ
ム２０２にサービスを提供することができ、したがっ
て、アプリケーション２０２はそのサービスによりヒー
プからのメモリの割振りおよび割振り解除を明示的に行
うことができる。
【００１５】図３は、本発明による例示的なメモリ管理
方法を示す流れ図３００である。この例示的な実施の形
態は、第１の段階３０２と、第２の段階３０４と、第３
の段階３０６とを含む。第１の段階３０２では、プログ
ラム表現を受け取り、そのプログラム表現についてプロ
グラム分析を実行する。このプログラム分析は、プログ
ラムのヒープ割振り済みデータ構造のサイズおよび位置
合せ要件の決定を含む、プログラムによるヒープ・メモ
リの使用法を決定する。第２の段階３０４では、第１の
段階から受け取られたヒープ・メモリ使用法情報を使用
して、カストマイズしたヒープ・マネージャを生成す
る。第３の段階３０６では、カストマイズしたヒープ・
マネージャ（以下「カスタム・ヒープ・マネージャ」と
もいう）を使用するようにプログラム表現を更新し、更
新されたプログラム表現を提供する。
【００１６】例示的な実施の形態では、本発明によるメ
モリ管理の方法がコンパイラによって実行される。図４
は、コンパイラ４００の例示的な構造を示している。コ
ンパイラ４００はプログラムのソース・コードを受け取
り、構文解析プログラム４０２はソース・コードの内部
表現を生成する。分析プログラム４０４は、ソース・コ
ードの内部表現を受け取り、言語意味体系に違反してい
ないことを検証する。コード生成プログラム４０６は内
部表現からマシン・コードを生成する。例示的な実施の
形態では、本発明の段階１（図３のステップ３０２）は
コンパイラの分析プログラム４０４によって実行され、
段階２（図３のステップ３０４）と段階３（図３のステ
ップ３０６）はコンパイラのコード生成プログラム４０
６によって実行される。
【００１７】図５は、本発明によるメモリ管理の他の例
示的な方法を示す流れ図５００を示している。ステップ
５０２では、プログラム表現を分析して、元（オリジナ
ル）のヒープ・マネージャへの呼出しを識別する。ステ
ップ５０６では、そのデータ構造の位置合せ要件を識別
する。ステップ５０８では、元のヒープ・マネージャへ
の呼出しに対応するメモリ要求のサイズが既知のもので
あるかどうかを判定する。プログラム実行の前にプログ
ラム分析がコンパイラによって実行される場合、メモリ
要求のサイズが未知のものである可能性がある。
【００１８】ステップ５１０では、要求されたメモリの
サイズが未知のものであるメモリ要求を個別グループに
配置する。各個別グループは、同じ位置合せ要件を備え
た対応するデータ構造を有するメモリ要求を含む。ステ
ップ５１２では、その固有の位置合せ要件に応じて、各
個別グループごとにカスタム・ヒープ・マネージャを生
成する。
【００１９】ステップ５０８でメモリ要求のサイズが既
知のものであると判定された場合、ステップ５１４でそ
のメモリ要求のサイズを決定する。ステップ５１６で
は、それぞれの対応するメモリ要求のサイズに応じて、
元のヒープ・マネージャへの呼出しを個別グループに配
置する。各個別グループは、同じサイズのメモリに関す
る要求を含む。
【００２０】ステップ５１８では、これらの個別グルー
プのそれぞれに関する位置合せ要件を決定する。それぞ
れの個別グループ内のメモリ要求は同じサイズのメモリ
・ブロックに関する多くのメモリ要求に対応する可能性
があるが、１つの個別グループ内の各メモリ要求は異な
る位置合せ要件を備えた対応するデータ構造を有する可
能性がある。この例示的は実施の形態では、そのグルー
プに関する位置合せ要件は、そのグループに対応するデ
ータ構造に関するデータ構造位置合せ要件のうちの最大
位置合せ要件である。ステップ５２０では、メモリ要求
の固有のサイズとそのグループの位置合せ要件に応じ
て、各個別グループに対応するカスタム・ヒープ・マネ
ージャを生成する。
【００２１】ステップ５２２では、各カスタム・ヒープ
・マネージャごとに個別記憶プールを割り振ることがで
きる。ステップ５２４では、プログラム表現内の元のヒ
ープ・マネージャへの呼出しをカスタム・ヒープ・マネ
ージャへの呼出しで置き換え、更新されたプログラム表
現を提供する。
【００２２】図６は、図５の流れ図に示すメモリ管理の
例示的な方法のための例示的なアルゴリズムを示してい
る。段階１（行１〜７）では、プログラム表現を分析し
て、各ヒープ割振り済みデータ構造のサイズおよび位置
合せ要件を決定する。この情報は、データ構造の型ｔ、
データ構造の位置合せ要件（alignmentOf(t)）、要求さ
れたメモリのサイズ（sizeOf(s)）を含む、１組のトリ
プル（Ｒ）として記憶される。
【００２３】データ構造の位置合せ要件（alignmentOf
(t)）は、そのデータ構造内に含まれる最大データ型の
サイズである。位置合せ要件は、プログラム表現の実行
前にコンパイラによってコンパイル中に入手することが
できる。メモリ要求のサイズ（sizeOf(s)）は未知のも
のである可能性がある。というのは、ヒープ・マネージ
ャへの呼出しに対応するメモリ要求のサイズは、コンパ
イル時に未知のものである可能性があるからである。
【００２４】段階２（行８〜９）では、GenerateCustom
izedRoutinesというルーチンを呼び出して、カストマイ
ズしたヒープ・マネージャを生成する。図７に示すこの
ルーチンは、１組のトリプルＲを受け取って、１組の出
力トリプルＳを生成する。各出力トリプルＳは、データ
構造の型ｔと、メモリ要求のサイズがコンパイル時に既
知のものである場合にデータ構造の割振りおよび割振り
解除を行うための１対のカストマイズ・メモリ管理ルー
チンとを含む。
【００２５】それぞれ別個のサイズのメモリ要求ごとに
個別の１対のルーチンmallocおよびfreeを生成する。こ
の例示的な実施の形態では、各対のルーチンはそれ自体
の記憶プールを共用し、それらのルーチンはそこからメ
モリの割振りおよび割振り解除を行う。特定の１対のル
ーチンによって割振りおよび割振り解除が行われるすべ
てのメモリ・ブロックは同じサイズなので、ヘッダ情報
は不要である。１対のルーチンが異なる位置合せ要件を
有する異なるデータ構造型に対応する場合、その１対の
ルーチン用として、対応するデータ構造型の最大位置合
せ要件を選択する。
【００２６】図６を参照すると、アルゴリズムの段階３
（行１０〜２２）は、カストマイズしたヒープ・マネー
ジャを使用するよう、プログラム表現を更新する。メモ
リ要求のサイズがコンパイル時に未知のものである場合
（行１２〜１９）、サイズではなく位置合せ要件に応じ
て記憶プールを区分する（行１６〜１８、図５のステッ
プ５１０および５１２を参照）。この結果、同じ位置合
せ要件とコンパイル時に未知のサイズを備えたメモリ要
求が同じ記憶プールから割り振られるが、結局、それぞ
れのサイズが異なる可能性がある。コンパイル時に既知
のサイズのメモリ要求とは対照的に、位置合せ要件に応
じて割り振られ、コンパイル時に未知のサイズのメモリ
要求は、それぞれのサイズが異なる可能性があるので、
ヘッダを必要とする。
【００２７】メモリ要求のサイズがコンパイル時に既知
のものである場合、プログラム更新ルーチンを呼び出し
て（行２２）、段階２で生成されたカストマイズ・メモ
リ管理ルーチンを使用するようプログラム表現を更新す
る。図５のステップ５２４に関して前述したように、プ
ログラム更新ルーチンは、元のプログラム表現ととも
に、データ構造の型と、対応する１対のヒープ・マネー
ジャ・ルーチンとを入力として受け取り、更新されたプ
ログラム表現という出力を提供する。
【００２８】図８は、手続き型プログラミング言語用の
例示的なプログラム更新アルゴリズムを示している。プ
ログラム表現内のステートメントを調べて（行１〜
３）、それに関するメモリ要求のサイズがコンパイル時
に既知のものである型ｔのデータ構造を割り振るヒープ
・マネージャへの呼出しを識別する。次に、これらの元
のヒープ・マネージャを対応するカスタム・ヒープ・マ
ネージャで置き換える（行７〜１１）。図９は、オブジ
ェクト指向プログラム言語用のプログラム更新ルーチン
を示している。Ｓ内の<t,malloc_l_a,free_l_a>という
各要素ごとに、newがmalloc_l_aを呼び出し、deleteがf
ree_l_aを呼び出すように、newおよびdeleteというメソ
ッドをｔのクラスに追加する（行２〜３）。ｔに関して
new（またはdelete）を呼び出すと、ｔのnew（またはde
lete）メソッドが呼び出される。
【００２９】手続き型言語として実現されるように本発
明によるメモリ管理の一例については、明示的にメモリ
を管理する図１０のＣプログラム（元のプログラム表
現）と、図１１に示す対応する更新済みＣプログラム
（更新されたプログラム表現）に関連して示す。このプ
ログラムは、Ｔ１、Ｔ２、Ｔ３という３つのデータ構造
を有する。Ｔ１およびＴ２は２４バイトの記憶域を必要
とし、Ｔ３は１６バイトの記憶域を必要とする。Ｔ１は
ダブル・ワード（８バイト）の位置合せ要件を有し、Ｔ
２とＴ３はどちらも１ワード（４バイト）の位置合せ要
件を有する。
【００３０】メイン・ルーチンは、ヒープからの３つの
データ構造すべての割振り（Ｓ２〜Ｓ５）および割振り
解除（Ｓ６〜Ｓ９）を行う。たとえば、ステートメント
Ｓ２は、ヒープからのＴ１データ構造を含むメモリ・ブ
ロックの割振りを行い、Ｔ１データ構造を指すポインタ
である変数T1_ptr内にそのメモリ・ブロックのアドレス
を入れる。Ｔ１＊式は、ヒープ・マネージャによって返
されたメモリを指すポインタをＴ１データ構造にキャス
トする。メモリ要求のサイズが既知のものであったステ
ートメントＳ２とは対照的に、ステートメントＳ４は、
アレイ内の要素の数がコンパイル時に未知のものである
ヒープからのＴ２データ構造のアレイを割り振る。
【００３１】段階１は、ステートメントＳ２〜Ｓ５内の
ヒープ・アロケータへの呼び出しに対応する<T1,8,24
>、<T2,4,24>、<T2,4,unknown>、<T3,4,16>という１組
のトリプルＲを生成する。段階２は、<T1,malloc_8_24,
free_8_24>、<T2,malloc_8_24,free_8_24>、<T3,malloc
_4_16,free_4_16>という１組のトリプルＳを生成する。
それぞれのトリプルＳの第２および第３の構成要素は、
ヒープからのメモリの割振りおよび割振り解除を行うた
めのルーチンをそれぞれ示している。たとえば、malloc
_8_24は、ダブル・ワード（８バイト）で位置合せされ
た２４バイトのメモリの割振りを行う。Ｔ２の位置合せ
要件は４バイトであるが、それに対応するカスタム・ヒ
ープ・マネージャの位置合せ要件は８バイトである。と
いうのは、Ｔ１とＴ２の両方のデータ構造が同じサイズ
を有し、それぞれの位置合せ要件のうちの大きい方が両
方のデータ構造に使用されるからである。
【００３２】図１１は、カスタム・ヒープ・マネージャ
・ルーチンを使用するよう段階３で更新された元のプロ
グラム表現に対応する、更新されたプログラム表現を示
している。ステートメントＳ２、Ｓ３、Ｓ５に示すよう
に、メモリ要求のサイズがコンパイル時に既知のもので
ある場合、そのプログラムは対応するカストマイズ・ヒ
ープ・マネージャ・ルーチンによって更新されている。
図１１のステートメントＳ４が示すように、メモリ要求
のサイズがコンパイル時に未知のものである場合、位置
合せ要件に対応するカストマイズ・ヒープ・マネージャ
によってヒープから対応するメモリ・ブロックが割り振
られる。
【００３３】この例示的な実施の形態では、カスタム・
ヒープ・マネージャ・ルーチンが３つの個別記憶プール
を使用する可能性がある。第１のプールは、ダブル・ワ
ードで位置合せされる２４バイトのサイズを有するメモ
リ要求に使用することができる。第２のプールは、１ワ
ード位置合せ要件を有する１６バイトの記憶域に関する
メモリ要求に使用することができる。第３のプールは、
メモリ要求のサイズとは無関係に１ワード位置合せ要件
を有するデータ構造を記憶するために使用することがで
きる。
【００３４】図１２は、Ｃ＋＋で作成され、明示的にメ
モリを管理するオブジェクト指向アプリケーション（元
のプログラム表現）を示している。図１３は、それに対
応する更新されたプログラム表現を示している。図１２
のプログラム表現は、図１０のプログラムと同じ３つの
データ構造Ｔ１、Ｔ２、Ｔ３を含む。図１２のプログラ
ムに適用される段階１および段階２は、図９に示すプロ
グラム用に生成されるものと同じ複数組のトリプレット
ＲおよびＳを生成する。
【００３５】メモリ要求のサイズがコンパイル時に未知
のものである場合、段階３は、コンパイル時に未知のサ
イズを有するＴ２データ構造のアレイを割り振るときに
malloc_4およびfree_4への同じ呼出しを生成する。しか
し、メモリ要求のサイズがコンパイル時に既知のもので
ある場合、呼び出されるUpdateProgramルーチンは、図
１０および図１１のプログラム用とは異なるものであ
る。図９に示すように呼び出されるUpdateProgramは、
新しいメソッドnewおよびdeleteを追加するようにヒー
プ割振りを行ったデータ構造のクラス宣言を更新するも
のである。
【００３６】更新され、図１３に示すように、Ｔ１およ
びＴ２のnewおよびdeleteはmalloc_8_24およびfree_8_2
4をそれぞれ呼び出す。Ｔ２のnew[]およびdelete[]はma
lloc_4およびfree_4をそれぞれ呼び出す。Ｔ３のnewお
よびdeleteはmalloc_4_16およびfree_4_16をそれぞれ呼
び出す。図１３に示す更新されたプログラム表現では、
ステートメントｓ２、ｓ３、ｓ５（ｓ６、ｓ７、ｓ８）
におけるnew（delete）への呼出しは、Ｔ１〜Ｔ３のク
ラス定義で定義されたnew（delete）の定義を呼び出
す。たとえば、ステートメントｓ２におけるnewへの呼
出しは、クラスＴ１で定義され、malloc_8_24を呼び出
す、カストマイズされたnewルーチンを呼び出すもので
ある。あるクラスがnew（またはdelete）メソッドを指
定変更しない場合、デフォルトのヒープ・マネージャ・
ルーチンを使用して、malloc（またはfree）を直接呼び
出す。
【００３７】本発明によるメモリ管理方法を使用するこ
とによってもたらされるメモリ使用効率の改善の利点に
ついて、図１４〜１９に関連して説明する。図１４〜１
９の各行は４バイトのメモリを表している。図１４〜１
６は２つのデータ構造１０２からなる記憶域に対応する
メモリ・ブロックを示している。図１７〜１９は３つの
データ構造１０２からなる記憶域に対応するメモリ・ブ
ロックを示している。
【００３８】図１４は、従来のメモリ管理技法により２
つのデータ構造１０２からなるアレイを記憶するために
割り振られたメモリ・ブロック１４００を示している。
図１に関連して記述した例と同様に、ヘッダを使用して
メモリ・ブロックのサイズを示す。というのは、様々な
サイズのブロックが同じ記憶プールに記憶され、ダブル
・ワード位置合せ要件のためにヘッダ埋込みが必要にな
るからである。この従来のメモリ管理技法では、３２の
倍数であるサイズを有する所定のブロック・サイズでメ
モリが割り振られるものと想定している。必要なメモリ
のサイズは３２バイトであって、偶然、３２の倍数にな
るので、その結果、内部断片化は一切発生しない。
【００３９】図１５および図１６は、それぞれメモリ要
求のサイズが既知のものである場合と未知のものである
場合に本発明により２つのデータ構造１０２からなるア
レイを記憶するためのメモリ・ブロック１５００、１６
００を示している。サイズが既知のものである場合、同
じプール内のすべてのブロックは同じサイズになるの
で、メモリ・ブロック１５００はヘッダを必要としな
い。また、メモリ・ブロック１５００は正しい位置合せ
で終わるので、内部断片化を含まない。メモリ・ブロッ
ク１６００のサイズはコンパイル時に未知のものなの
で、４バイトのヘッダを含む。また、メモリ・ブロック
１６００は４バイトであるそれ自体の位置合せ要件に応
じてプール内に記憶されるので、内部断片化を含まな
い。
【００４０】図１７は、従来のメモリ管理技法により３
つのデータ構造１０２からなるアレイを記憶するために
割り振られたメモリ・ブロック１７００を示している。
ブロック１４００と比較すると、追加のデータ構造１０
２に加え、ブロック１７００は２０バイトの内部断片化
を含む。というのは、３２の倍数であるサイズでブロッ
クが割り振られるからである。図１８および図１９は、
それぞれメモリ要求のサイズが既知のものである場合と
未知のものである場合に本発明により３つのデータ構造
１０２からなるアレイを記憶するためのメモリ・ブロッ
ク１８００、１９００を示している。ブロック１５００
に関して説明したのと同じ理由により、メモリ・ブロッ
ク１８００はヘッダを必要とせず、内部断片化を一切含
まない。また、ブロック１６００に関して説明したのと
同じ理由により、メモリ・ブロック１９００は４バイト
のヘッダを含み、内部断片化を一切含まない。本発明に
よるメモリ使用効率の改善について、以下の表１に示
す。
【表１】
【００４１】本発明の例示的な実施の形態では、実行前
に実現可能なメモリ管理の方法を提供する。オフライン
・プロファイリングと比較すると、本発明の例示的な実
施の形態は、実行統計を収集するためにソース・コード
を備える必要がないことにより、節約をもたらすことが
できる。さらに、オフライン・プロファイリングに基づ
くメモリ管理は、本発明の例示的な実施の形態のものと
同程度に予測可能なパフォーマンスを提供することがで
きない。というのは、プログラム実行は可変かつ予測不
能である場合が多く、実際のプログラム実行はプロファ
イリングした実行とは異なる可能性があるからである。
【００４２】本発明の例示的な実施の形態におけるメモ
リ管理の方法は、予測した位置合せ要件または最悪の場
合の位置合せ要件ではなく、実際の位置合せ要件を考慮
する。この結果、位置合せ要件に関する想定を行う方法
と比較すると、内部断片化が低減される可能性がある。
【００４３】本発明は、ソース・コード・プログラム表
現に適用されるものとして前述されている。当業者には
既知の通り、本発明は、ソース・コード・プログラム表
現に限定されず、コンパイル済みコード、実行可能コー
ド、複数言語用の中間コードなどを含みかつこれらに限
定されない他のプログラム表現にも適用できるものであ
る。
【００４４】プロファイリング統計に基づくメモリ管理
とは対照的に、本発明の例示的な実施の形態によるプロ
グラム分析は、可変プログラム入力のための信頼でき一
貫したメモリ管理を可能にする。本発明による例示的な
方法は、ステートメントの実行頻度に関する情報を使用
するよう適合させることができる。たとえば、どのデー
タ構造を激しく使用するかを推定する技法を使用して、
適切なプール・サイズおよび位置合せを決定することが
できる。あるいは、プロファイリングとプログラム分析
を組み合わせて、どのプール・サイズが最も頻繁に要求
されるかを判定することができる。次に、この頻度情報
を使用して、あるプール用のメモリの再割振りを行うか
または複数のプールを組み合わせることができる。
【００４５】元のヒープ・マネージャが大きいデータ・
ブロックと小さいデータ・ブロックの両方について大き
いブロックのヒープ記憶域を割り振る場合、大きいデー
タ・ブロックに比べ、小さいデータ・ブロックの方が断
片化およびヘッダに関するスペース・オーバヘッドが比
較的高くなる可能性がある。大きい記憶ブロックの場合
に断片化およびヘッダのオーバヘッドを低減すると、全
体的なスペース削減への影響が小さくなる可能性があ
る。本発明の例示的な実施の形態では、本発明によるメ
モリ管理の方法を使用して、所定のサイズより小さい記
憶ブロックの割振りおよび割振り解除を行うためのカス
タム・ヒープ・マネージャを提供する。他の例示的な実
施の形態では、ヒープ割振りによる未使用スペースのた
めに、しきいパーセント分だけ要求サイズを上回って割
り振られるブロックのサイズが増大する場合に、カスタ
ム・ヒープ・マネージャが記憶ブロックの割振りおよび
割振り解除を行う。このしきいパーセントは、たとえ
ば、１０％〜２０％の範囲になる可能性がある。
【００４６】適応または動的コンパイラとも呼ばれるリ
アルタイム最適化コンパイラは、プログラム表現のうち
の今後の実行用の部分を適応的に再コンパイルするため
に、プログラム表現の一部分の現行実行の動作を使用す
る。当業者には既知の通り、本発明によるメモリ管理の
方法は、リアルタイム最適化コンパイラに組み込むこと
ができる。
【００４７】当業者には既知の通り、本発明の例示的な
実施の形態は、特定のプログラム表現に応じてデータ構
造用の様々なタイプ、サイズ、位置合せ要件に適応させ
ることができる。たとえば、あるプログラム表現では、
他のサイズのメモリに関するメモリ要求に比べ、既知の
特定のサイズのメモリに関するメモリ要求の方が少なく
なる場合がある。このようなサイズはコンパイル時に既
知のものである可能性があるが、本発明の例示的な実施
の形態では、そのサイズに基づくのでなく、その位置合
せ要件に応じて、このような少数のメモリ要求の割振り
および割振り解除を行うことができる。
【００４８】
【００４９】
【図面の簡単な説明】
【図１】データ構造の記憶域に対応するメモリ・ブロッ
クを示す図である。
【図２】本発明の例示的な実施の形態によるコンピュー
タ・システムを示す図である。
【図３】本発明による例示的な方法を示す流れ図であ
る。
【図４】本発明の例示的な実施の形態によるコンパイラ
を示す流れ図である。
【図５】本発明による他の例示的な方法を示す流れ図で
ある。
【図６】本発明によりメモリ管理を実行するための例示
的なアルゴリズムを示す図である。
【図７】本発明によりメモリ管理を実行するための例示
的なアルゴリズムを示す図である。
【図８】本発明によりメモリ管理を実行するための例示
的なアルゴリズムを示す図である。
【図９】本発明によりメモリ管理を実行するための例示
的なアルゴリズムを示す図である。
【図１０】本発明によりメモリ管理を実行するための例
示的なアルゴリズムを示す図である。
【図１１】本発明によりメモリ管理を実行するための例
示的なアルゴリズムを示す図である。
【図１２】本発明によりメモリ管理を実行するための例
示的なアルゴリズムを示す図である。
【図１３】本発明によりメモリ管理を実行するための例
示的なアルゴリズムを示す図である。
【図１４】従来のメモリ管理の方法により２つのデータ
構造を記憶するためのメモリ・ブロックを示す図であ
る。
【図１５】メモリ要求のサイズが既知のものである場合
に本発明により２つのデータ構造を記憶するためのメモ
リ・ブロックを示す図である。
【図１６】メモリ要求のサイズが未知のものである場合
に本発明により２つのデータ構造を記憶するためのメモ
リ・ブロックを示す図である。
【図１７】従来のメモリ管理の方法により３つのデータ
構造を記憶するためのメモリ・ブロックを示す図であ
る。
【図１８】メモリ要求のサイズが既知のものである場合
に本発明により３つのデータ構造を記憶するためのメモ
リ・ブロックを示す図である。
【図１９】メモリ要求のサイズが未知のものである場合
に本発明により３つのデータ構造を記憶するためのメモ
リ・ブロックを示す図である。
【符号の説明】 ２００ コンピュータ・システム ２０２ アプリケーション・プログラム ２０４ コンピュータ・プラットフォーム ２０８ オペレーティング・システム ２１２ ハードウェア・ユニット ２１４ ランダム・アクセス・メモリ（ＲＡＭ） ２１６ 中央演算処理装置（ＣＰＵ） ２１８ 入出力（Ｉ／Ｏ）インタフェース ２２６ 端末 ２３０ データ記憶装置 ２３４ 印刷装置
フロントページの続き (56)参考文献 特開 昭63−140338（ＪＰ，Ａ) 特開 平９−212369（ＪＰ，Ａ) 特開 昭63−163930（ＪＰ，Ａ) 特開 平８−153037（ＪＰ，Ａ) 特開 平７−129408（ＪＰ，Ａ) (58)調査した分野(Int.Cl.7，ＤＢ名) G06F 12/00 - 12/06 G06F 9/45

Claims (6)

    (57)【特許請求の範囲】
  1. 【請求項１】メモリ使用効率を増すための方法にして、 （ａ）複数のデータ構造のそれぞれに対応する位置合せ
    要件およびサイズ要件を測定するステップと、 （ｂ）前記位置合せ要件および前記サイズ要件に基づい
    てデータ・メモリ内に前記複数のデータ構造からなる記
    憶域を配置するステップと、 （ｃ）プログラム・メモリからプログラム表現を読み取
    るステップとを含み、 前記プログラム表現が前記複数のデータ構造のうちの１
    つのデータ構造に対応する元のヒープ・マネージャへの
    呼出しを含み、前記元のヒープ・マネージャが前記１つ
    のデータ構造に対応する前記データ・メモリの第１の部
    分の割振りおよび割振り解除を行うように適応され、 ステップ（ｂ）が選択的に （ｂ１）前記元のヒープ・マネージャに対応するカスタ
    ム・ヒープ・マネージャを生成するステップと、 （ｂ２）前記元のヒープ・マネージャへの前記呼出しを
    前記カスタム・ヒープ・マネージャへの呼出しで置き換
    えるステップとを含み、 前記カスタム・ヒープ・マネージャが前記１つのデータ
    構造の前記位置合せ要件および前記サイズ要件のうちの
    少なくとも一方に応じて前記データ・メモリの第２の部
    分の割振りおよび割振り解除を行うように適応される 、 メモリ使用効率を増すための方法。
  2. 【請求項２】前記１つのデータ構造の前記サイズ要件が
    未知のものである場合に、前記１つのデータ構造の前記
    位置合せ要件に応じて前記データ・メモリの前記第２の
    部分の割振りおよび割振り解除を行うように適応された
    前記カスタム・ヒープ・マネージャへの呼出しで前記元
    のヒープ・マネージャへの呼出しが置き換えられる、請
    求項１に記載のメモリ使用効率を増すための方法。
  3. 【請求項３】前記１つのデータ構造の前記サイズ要件が
    既知のものである場合に、前記１つのデータ構造の前記
    サイズ要件に応じて前記データ・メモリの前記第２の部
    分の割振りおよび割振り解除を行うように適応された前
    記カスタム・ヒープ・マネージャへの呼出しで前記元の
    ヒープ・マネージャへの呼出しが置き換えられる、請求
    項１に記載のメモリ使用効率を増すための方法。
  4. 【請求項４】前記複数のデータ構造のうちの選択したデ
    ータ構造が前記１つのデータ構造の前記サイズ要件に等
    しいサイズ要件を有し、前記選択したデータ構造の最大
    位置合せ要件に等しい位置合せ要件に応じて前記データ
    ・メモリの前記第２の部分の割振りおよび割振り解除を
    行うように前記カスタム・ヒープ・マネージャが適応さ
    れる、請求項３に記載のメモリ使用効率を増すための方
    法。
  5. 【請求項５】前記１つのデータ構造が所定のサイズより
    小さいサイズ要件を有する場合にステップ（ｂ１）およ
    び（ｂ２）が選択的に実行される、請求項１に記載のメ
    モリ使用効率を増すための方法。
  6. 【請求項６】前記データ・メモリ内の個別記憶プールが
    前記カスタム・ヒープ・マネージャに割り振られる、請
    求項１に記載のメモリ使用効率を増すための方法。
JP2000031065A 1999-02-10 2000-02-08 メモリ使用効率を増すための方法 Expired - Fee Related JP3422743B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/247495 1999-02-10
US09/247,495 US6401182B1 (en) 1999-02-10 1999-02-10 Method and apparatus for memory management

Publications (2)

Publication Number Publication Date
JP2000242551A JP2000242551A (ja) 2000-09-08
JP3422743B2 true JP3422743B2 (ja) 2003-06-30

Family

ID=22935146

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000031065A Expired - Fee Related JP3422743B2 (ja) 1999-02-10 2000-02-08 メモリ使用効率を増すための方法

Country Status (4)

Country Link
US (1) US6401182B1 (ja)
JP (1) JP3422743B2 (ja)
KR (1) KR100349958B1 (ja)
TW (1) TW460783B (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6546551B1 (en) * 1999-09-28 2003-04-08 International Business Machines Corporation Method for accurately extracting library-based object-oriented applications
US6697074B2 (en) * 2000-11-28 2004-02-24 Nintendo Co., Ltd. Graphics system interface
US6985916B2 (en) * 2002-08-29 2006-01-10 International Business Machines Corporation Method, system, and article of manufacture for returning physical volumes
US7100015B1 (en) * 2003-09-15 2006-08-29 Sun Microsystems, Inc. Redirecting external memory allocation operations to an internal memory manager
DE602004026822D1 (de) * 2004-02-27 2010-06-10 Ericsson Telefon Ab L M Programmieren eines Flash-Speichers
US7506329B1 (en) * 2004-05-04 2009-03-17 Sun Microsystems, Inc. Method and system for targeting profile gathering through real-time data
US7774787B2 (en) * 2005-01-11 2010-08-10 Microsoft Corporation Method for specifying and verifying multi-threaded object-oriented programs with invariants
US7590978B2 (en) 2005-04-15 2009-09-15 Microsoft Corporation Inferring object invariant method and system
US7559054B2 (en) * 2005-04-19 2009-07-07 Microsoft Corporation Abstract interpretation with a congruence abstract domain and/or a heap succession abstract domain
US7809918B1 (en) * 2005-07-22 2010-10-05 American Megatrends, Inc. Method, apparatus, and computer-readable medium for providing physical memory management functions
US7908454B2 (en) * 2007-06-26 2011-03-15 Microsoft Corporation Application-specific heap management
WO2010122674A1 (ja) * 2009-04-23 2010-10-28 株式会社日立製作所 計算機システム及びその制御方法
US8386418B2 (en) * 2009-11-30 2013-02-26 International Business Machines Corporation System and method for an intelligent storage service catalog
US8522216B2 (en) 2010-05-04 2013-08-27 Oracle International Corporation Memory leak detection
US8504878B2 (en) * 2010-05-04 2013-08-06 Oracle International Corporation Statistical analysis of heap dynamics for memory leak investigations
US9213530B2 (en) * 2013-08-15 2015-12-15 Oracle International Corporation Runtime memory throttling
US9372990B2 (en) 2014-08-29 2016-06-21 International Business Machines Corporation Detecting heap spraying on a computer
US10515430B2 (en) * 2015-11-03 2019-12-24 International Business Machines Corporation Allocating device buffer on GPGPU for an object with metadata using access boundary alignment

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5335332A (en) * 1991-12-24 1994-08-02 International Business Machines Corporation Method and system for stack memory alignment utilizing recursion
US5784699A (en) * 1996-05-24 1998-07-21 Oracle Corporation Dynamic memory allocation in a computer using a bit map index
US5903900A (en) * 1997-04-23 1999-05-11 Sun Microsystems, Inc. Method and apparatus for optimizing exact garbage collection of array nodes in a carded heap
CA2212316C (en) * 1997-07-31 2001-02-13 Ibm Canada Limited - Ibm Canada Limitee A method of recognizing fixed and variable sized data objects in memory

Also Published As

Publication number Publication date
TW460783B (en) 2001-10-21
KR20000076636A (ko) 2000-12-26
KR100349958B1 (ko) 2002-08-23
US6401182B1 (en) 2002-06-04
JP2000242551A (ja) 2000-09-08

Similar Documents

Publication Publication Date Title
JP3422743B2 (ja) メモリ使用効率を増すための方法
US6845501B2 (en) Method and apparatus for enabling a compiler to reduce cache misses by performing pre-fetches in the event of context switch
KR100686418B1 (ko) 멀티-스레드 가상머신에서 메모리 할당방법 및 그 장치
US9086952B2 (en) Memory management and method for allocation using free-list
US7313797B2 (en) Uniprocessor operating system design facilitating fast context switching
US8510710B2 (en) System and method of using pooled thread-local character arrays
Kistler et al. Automated data-member layout of heap objects to improve memory-hierarchy performance
EP1594061B1 (en) Methods and systems for grouping and managing memory instructions
EP1260901A2 (en) Method and apparatus for managing hashed objects
US7089557B2 (en) Data processing system and method for high-efficiency multitasking
US5963982A (en) Defragmentation of stored data without pointer indirection
US5940621A (en) Language independent optimal size-based storage allocation
JPH10124327A (ja) インストラクションキャッシュミス率削減方法
US20070300210A1 (en) Compiling device, list vector area assignment optimization method, and computer-readable recording medium having compiler program recorded thereon
US8006238B2 (en) Workload partitioning in a parallel system with hetergeneous alignment constraints
US7356812B2 (en) Passing parameters by implicit reference
US6571387B1 (en) Method and computer program product for global minimization of sign-extension and zero-extension operations
US6240500B1 (en) Method for dynamically placing procedures of a program in a memory
US7299318B2 (en) Method for reducing cache conflict misses
US7120776B2 (en) Method and apparatus for efficient runtime memory access in a database
CN116113927A (zh) 用于函数调用中可重复使用和相对索引的寄存器资源分配的方法和装置
JP3264901B2 (ja) コンパイル装置及びコンパイル方法
US20080034022A1 (en) System and method for updating references when incrementally compacting a heap
JPH0666052B2 (ja) メモリ内容を機械レジスタに自動的に写像する計算機
JP4260895B2 (ja) マイクロコントローラにおける複数フォーマットアドレス指定

Legal Events

Date Code Title Description
FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080425

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees