malloc

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

malloc(マロック, エムアロック)、freecallocreallocは、動的メモリ確保を行うC言語標準ライブラリ関数である[1][2][3]

mallocが使用する実際のメモリ確保機構には様々な実装がある。それらの性能は、実行時間と要求されるメモリの両面で様々である。

原理[編集]

C言語は通常メモリを「静的メモリ確保」か「自動メモリ確保」で管理する。静的変数は主記憶上にプログラムが存在する期間中ずっと確保されている。自動変数(局所変数)は通常コールスタック上に確保され、対応するサブルーチンが実行中の間だけ存在する。しかし、いずれの方法も限界があり、確保できるメモリ量(変数のサイズ)はコンパイル時に決められてしまう(C99で初めて可変長配列が可能になった[4])。必要なサイズが実行時でないと判明しない場合、例えばディスク上のファイルから任意のサイズのデータを読み込むような場合、固定サイズのデータオブジェクトだけでは不十分である。

確保されたメモリの生存期間(使用可能期間)も問題となる。静的でも自動的でも確保されたメモリの生存期間はあらゆる状況に対応できるものではない。スタック上のデータは複数の関数呼出をまたいで持続できないし、静的データは必要かどうかに関わらずプログラムが動作中ずっとメモリ領域を確保し続ける。しかし、そうではなく確保したメモリの生存期間をプログラマが自由にできる必要がある場合も多い。

これらの制限は動的メモリ確保を使用することで解決する。メモリの管理は明示的に行う必要が出てくるが、柔軟性が向上する。「ヒープ領域」はこのために用意されたメモリ領域である。C言語では、malloc関数を使ってヒープ領域からメモリブロックを確保する。プログラムはmallocの戻り値であるポインタを使って、そのメモリブロックにアクセスする。メモリブロックが不要になったら、そのポインタをfreeに渡して解放し、他の用途に再利用できるようにする。

ヒープではなくCのスタックフレームから実行時に動的にメモリを確保するライブラリルーチンもある(Unix系alloca()[5]Microsoft Windows のCランタイムライブラリの malloca()[6] など)。このように確保したメモリは呼び出した関数から抜ける時点で自動的に解放される。しかし、C99標準で可変長配列 (variable-length arrayがサポートされ、実行時に大きさを決定でき任意の静的スコープの範囲で存在するメモリ確保法ができたため、このようなメモリ確保法の必要性は薄れてきている。

C言語での動的メモリアロケーション[編集]

mallocは C 言語におけるヒープ領域からのメモリ確保に使われる基本関数である。その関数プロトタイプstdlib.hヘッダに次のように定義されている[1]

void *malloc(size_t size)

ここで、sizeバイトのメモリが確保される。確保が成功するとそのメモリブロックへのポインタが返される。

mallocが返すのは、void型へのポインタ (void *) であり、そのポインタが指す領域のデータ型が不明であることを示している。このポインタは、代入時、暗黙的に型変換され、必要なデータ型へのポインタ型となる。上記のとおりANSI Cにおいては、mallocのリターン値はvoid *型なので明示的に変換(キャスト)する必要が無いにもかかわらず、手動での型変換(キャスト)を行う人も存在する。明示的に型キャストする人がいるのは、型が厳密なC++ではエラーになるのと、かつてANSI以前の仕様のCにおいては、mallocchar *を返していたからである[7][8]

しかしstdlib.hをインクルードし忘れた場合、コンパイラはmallocがint型であるとみなす。これをキャストしているとインクルードし忘れたことに気づかないが、キャストしていないとコンパイル時にintをポインタ型変数に代入しようとしているとして何らかのメッセージが表示される[9][7][10]。例えば64ビットのシステムでLP64というデータモデルを採用している場合、longとポインタは64ビットだが、intは32ビットとなる。この場合stdlib.hをインクルードし忘れてそれに気づかないと、mallocが実際には64ビットのポインタを返すのに、32ビットの値を返すと暗に宣言したことになり、バグが生じる可能性がある。ただし、多くのコンパイラは宣言のない関数を使用していると(キャストの有無に関わらず)コンパイル時に警告を出す。

mallocで確保されたメモリは持続性がある。プログラム終了時か明示的にプログラマが解放しない限り存在し続ける。解放はfree関数で行われる。そのプロトタイプは次のようになる。

void free(void *pointer)

ここで、pointerの指すメモリブロックが解放される。

関連する関数[編集]

mallocはメモリブロックを確保して返すが、その領域は初期化されていない。必要に応じてメモリは個別に初期化する。例えば、memset関数で初期化したり、個別の代入文で初期化する。他にもcalloc(カロック、シーアロック)関数を使って、メモリ確保と初期化を行うこともできる。そのプロトタイプは以下のようになる。

void *calloc(size_t nelements, size_t bytes)

bytesのサイズのメモリ領域をnelements個格納できるメモリ領域を確保する。確保された領域はゼロで初期化される。

メモリブロックを大きくしたり小さくしたりできれば便利である。これはmallocfreeを組み合わせて、新たなメモリブロックを確保して内容を前のメモリブロックからコピーし、前のメモリブロックを解放することで実現できる。しかし、この方法は回りくどい。代わりにrealloc(リアロック)関数を使うことが出来る。そのプロトタイプは以下の通りである。

void *realloc(void *pointer, size_t bytes)

reallocは指定されたサイズのメモリ領域へのポインタを返す。新しいサイズが前のサイズより大きければブロックは大きくされ、逆ならば小さくされる。

vallocmallocとほとんど同じだが、メモリ確保がページ境界になる点が異なる。vallocで確保された領域へのポインタをreallocに渡すことはできない[1]。また、これは標準Cライブラリに含まれる関数ではない。

使用例[編集]

スタック上に10個の整数の配列を作成する一般的な方式は次の通りである:

int array[10];

同様の配列を動的に確保するには、以下のようなコードを使うことが出来る。

#include <stdlib.h>
 
/* 10個のintの配列のためのメモリを確保 */
int *ptr = malloc(sizeof (int) * 10);
if (NULL == ptr) {
    exit(EXIT_FAILURE); /* メモリを確保できなかったので、exit */
} else {
    /* 確保成功 */
    /* ここでその配列を使った処理を行う */
 
    /* 処理が完了したらそのメモリブロックを解放できる */
    free(ptr);  
    /* 解放したメモリへアクセスしてはならない。*/
    ptr = NULL; 
}

一般的なエラー[編集]

mallocや関連するC言語の関数の使用はバグの発生源になりやすい。

確保エラー[編集]

mallocは必ず成功するとは限らない。利用可能な空きメモリ領域がないとき、プログラムが限界値を超えてメモリを使用しようとしたときなど、mallocは ヌルポインタを返す。環境によって、このような状況の起きる可能性は異なる。多くのプログラムはmallocが失敗することを考慮していない。そのようなプログラムでmallocがヌルポインタを返してきたとき、プログラムはNULLに相当するアドレスにアクセスしてクラッシュするだろう。これは昔から設計上のミスとされているが、未だにそのようなプログラムが多い[11]。というのもメモリ確保に失敗するという状況は非常に珍しく、発生した場合には終了する以外にプログラミング上できることがない[12]からでもある。確保失敗をチェックすることはライブラリでは特に重要である。ライブラリはメモリ量が限られた状況でも使用される可能性がある。ライブラリ内でメモリ確保に失敗した場合、呼び出したアプリケーション側にエラーを通知して、アプリケーションプログラムに判断を委ねるのがよいとされる。

メモリリーク[編集]

mallocで確保したメモリブロックを使用しなくなってもfreeで解放せず、次々と新たなメモリブロックを確保していると空きメモリが少なくなってくる。これをメモリリークと呼ぶ。メモリリークによるメモリ消費が無視できない量に達するとページ置換アルゴリズムによってページアウトが発生し、システム性能が低下する。さらに仮想記憶の容量限界に達すると、システム内の他の全プロセスでメモリ確保が失敗してシステムがストールする。メモリリークは、利用のたびにプロセスの起動・終了が行われるプログラムにおいて、特に重要な問題を引き起こさないため、メモリリークが混入した状態で出荷される商用プログラムは多い。しかしながら、連続稼動が要求されるサーバコンピュータ上のプログラム(サービスデーモン)や、組み込みプログラム等の場合は、メモリリークは死活問題とされる。

解放後の使用[編集]

ポインタがfreeに渡された後でその領域への参照を行っても、その内容は未定義であり利用できない。しかし、ポインタ自体が残っていると使ってしまうことがある。次のコードはその例である。

int *ptr = malloc(sizeof *ptr);
free(ptr);
*ptr = 0; /* 何が起きるかわからない! */

このようなコードは予測不能の振る舞いをする。メモリが解放された後でシステムがその領域を他の用途に転用しているかもしれない。従って解放済みメモリ領域へのポインタを使った書き込みはプログラム内の別のデータを不正に書き換えてしまう。どういうデータを書き換えたかによって、その後のプログラムの動作は単なるデータ破壊で済むかもしれないし、クラッシュするかもしれない。特に破壊的なバグとしては、同じポインタを2回freeに渡してしまうことで、これを「二重解放; double free」と呼ぶ。これを防ぐため、解放した後でポインタ変数にNULLを格納することがある。というのもfree(NULL)は何もしないのである。

実装[編集]

メモリ管理の実装はオペレーティングシステム (OS) と(ハードウェア)アーキテクチャに大きく依存する。OSによってはmallocのためのアロケータを提供しているし、データ領域の制御関数を提供している場合もある。

同じ動的メモリアロケータでmallocだけでなくC++operator new も実装していることが多い。そこでこれを malloc ではなく「アロケータ」と呼ぶ。

ヒープ方式[編集]

IA-32アーキテクチャでのアロケータの実装には一般にヒープまたはデータセグメントが使用されている(セグメント方式)。 アロケータがメモリを確保するとき、ヒープに未使用領域がない場合はヒープを拡張することでメモリを確保する。

ヒープ方式はフラグメンテーションという問題がある。どのようなメモリ確保方式でもヒープではフラグメントが発生する。つまり、ヒープ上に飛び飛びに使用中領域と未使用領域が存在することになる。優秀なアロケータはヒープを拡張する前に未使用領域を再利用しようとする。しかし性能問題があるため、リアルタイムシステムでは代わりに「メモリプール」という方式を使う必要がある(特定サイズのメモリブロックのプールを予め用意しておく方式)。

ヒープ方式の欠点は、先頭位置が変更できないため、ヒープの最後の位置に使用中ブロックがある限り、ヒープを縮小することができないことである。従って、このような時は実際に使用しているメモリが少ないのにも関わらず、ヒープのアドレス空間に占める領域が拡大し続けるという問題が生じる。

mmapで確保した領域は、縮小したり開放したりすることができる。これらによって開放された領域は、OSのメモリ管理システムに委ねることになる。

dlmalloc[編集]

dlmalloc は Doug Lea が1987年に開発を始めた汎用アロケータ。パブリックドメインライセンス(CC0ライセンス)のオープンソースライブラリ。GNU Cライブラリ (glibc) の malloc は、dlmalloc を元に作られている[13]

ヒープ領域上のメモリは "chunk" という8バイト境界のデータ構造として確保され、その中にヘッダ部と利用可能なメモリがある。chunk および利用中フラグがあるため、8バイトまたは16バイトのオーバヘッドを含めたメモリ確保が必要である。アロケートされていないchunkも他のフリーなchunkへのポインタを持つため、chunkの最小サイズは24バイトとなっている[13]

アロケートされていないメモリは "bin" と呼ばれる同じサイズのchunkのグループに分けて管理される。binはchunkを双方向連結リストで連結したものである。

小さな領域 (<256B) を確保するときには2の累乗フリーリストが使われる。領域が不足したときは、より大きなサイズ用の領域からプールを確保する[13]

中程度の大きさの領域は、bitwiseトライ木により管理される。領域が不足したときは、(sbrkによる)ヒープの拡張が行われる。

大きな領域(デフォルト値は >= 256KB[14])は、mmap() が使える環境の場合、mmap() により直接確保される。この大きさならば、ページサイズ(通常4KB[15], CPUのアーキテクチャに依存する)単位でしか割り当てられないことによるオーバーヘッド、システムコールの遅さによるオーバーヘッドはほとんどない。一方で、先に述べたヒープ方式のアロケーションの問題が起こらないので、この方法が使われる。

FreeBSDとNetBSD[編集]

FreeBSD 7.0以降と NetBSD 5.0以降では、古い実装 (phkmalloc) をJason Evansが開発したjemallocに置換した。phkmalloc はマルチスレッド環境でのスケーラビリティに問題があった。ロックの衝突を防ぐため、jemallocはCPU毎に分離した "arena" と呼ばれる領域を用意する。実験によれば、スレッド数に比例して1秒間のmalloc回数が増えていくとき、phkmallocとdlmallocではスレッド数に反比例した性能を示した[16]

OpenBSD[編集]

OpenBSDmalloc関数の実装はmmapを使用している。ページサイズ以上の要求はmmapで行われ、ページサイズ未満ならmalloc内で管理しているメモリプールから割り当てる。そのメモリプールもmmapで確保したものである。freeを実行すると、munmapを使ってプロセスのアドレス空間からアンマップされて解放される。このシステムはアドレス空間のレイアウトをランダム化することによってセキュリティを高めるための設計でもあり、OpenBSDのmmapが持つギャップページ機能も利用している(mmapで確保した領域が仮想空間上で隣接しないようにする機能)。また、解放後の領域は仮想空間としてマッピングが存在しないため、解放後のアクセスの検出も容易である(普通ならセグメンテーション違反が発生してプログラムが終了する)。

Hoard[編集]

Hoardメモリアロケータ英語版は、スケーラブルなメモリ確保性能を目指したアロケータである。OpenBSDのアロケータと同様、Hoard はmmapのみを使用するが、64キロバイトのスーパーブロックと呼ばれる塊ごとにメモリを管理する。Hoardのヒープは論理的にグローバルな1つのヒープとプロセッサ毎のヒープに分けられている。さらにスレッド毎のキャッシュを持ち、制限された数のスーパーブロックを保持できる。確保はスレッド毎またはプロセッサ毎のヒープからのみ行い、解放されたスーパーブロックの多くはグローバルなヒープに戻して他のプロセッサが使えるようにする。このようにしてHoardではスレッド数に対してほぼ比例したスケーラビリティを維持しつつ、フラグメンテーションを最小に抑えている[17]

TCMalloc (thread-caching malloc)[編集]

スレッド毎に小さいメモリ確保のための領域を設ける。大きなメモリ確保にはmmapかsbrkを使用する。TCMallocはGoogleが開発したもので[18]、スレッドが終了した際にローカルな領域を掃除するガベージコレクション機能を備えている。マルチスレッド環境では、glibcのptmallocの2倍以上の性能を発揮するという[19][20]

カーネル内[編集]

OSのカーネルでもアプリケーションと同様にメモリ確保が必要である。カーネル内にもmalloc相当の関数はあるが、その実装はCライブラリのものとは大きく異なる。例えば、DMA用のバッファには特別な制限が課せられることがあるし、割り込み処理でメモリを動的に確保したい場合もある[21]。このため、カーネルの仮想記憶サブシステムと密に連携した malloc 実装が要求される。

最大確保サイズ[編集]

mallocが確保できるメモリブロックの最大サイズはシステムに依存する。特に物理メモリ量とOSの実装に依存する。理論上の最大値はsize_t型(メモリ領域のサイズを表す符号なし整数)である。その最大値は 2CHAR_BIT × sizeof(size_t) − 1か、C99標準の定数SIZE_MAXである。C言語標準は一回の確保で保証される最小値を提示している(C89では0x7FFF、C99では0xFFFF)。

C++での利用[編集]

C++でもmalloc関数は利用できるが、この利用は後述の問題を引き起こすため推奨されない。C++では言語の機能としてnew演算子delete演算子が用意されている[22]mallocで確保したメモリ領域に対してdeleteしたり、逆にnewで確保した領域をfreeしたりすると結果は未定義となる。mallocによって生まれたポインタとnewによって生まれたポインタの混在はバグの温床であり、また、new/delete演算子と違い、malloc/free関数ではクラスのコンストラクタデストラクタが呼ばれないという違いもあり、C++でのmallocは禁じ手の扱いである。

脚注[編集]

[ヘルプ]
  1. ^ a b ISO/IEC 9899:1999 specification. p. 313, § 7.20.3 "Memory management functions". http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf. 
  2. ^ Godse, Atul P.; Godse, Deepali A. (2008). Advanced C Programming. p. 6-28: Technical Publications. pp. 400. ISBN 978-81-8431-496-0. 
  3. ^ Summit, Steve. “C Programming Notes - Chapter 11: Memory Allocation”. 2011年10月30日閲覧。
  4. ^ gcc manual”. gnu.org. 2008年12月14日閲覧。
  5. ^ alloca”. Man.freebsd.org (2006年9月5日). 2011年9月18日閲覧。
  6. ^ malloca()”. MSDN Visual C++ Developer Center. 2009年3月12日閲覧。
  7. ^ a b Casting malloc”. Cprogramming.com. 2007年3月9日閲覧。
  8. ^ C FAQ 日本語訳 7.7
  9. ^ C FAQ 日本語訳 7.6
  10. ^ comp.lang.c FAQ list · Question 7.7b”. C-FAQ. 2007年3月9日閲覧。
  11. ^ 特にquick-hack的なコードの場合。行儀の良いまたは良くあるべきソース、例えばアプリケーション製品などでは必ずしも多いとは言えない
  12. ^ これも、前述と同様に、コードの異常系すなわち例外処理はアプリケーション製品では重要な要請である。
  13. ^ a b c Kaempf, Michel (2001). “Vudo malloc tricks”. Phrack (57): 8. http://phrack.org/issues.html?issue=57&id=8&mode=txt 2012年2月2日閲覧。. 
  14. ^ ftp://g.oswego.edu/pub/misc/malloc.c の DEFAULT_MMAP_THRESHOLD
  15. ^ Sanderson, Bruce (2004年12月12日). “RAM, Virtual Memory, Pagefile and all that stuff”. Microsoft Help and Support. 2012年7月11日閲覧。
  16. ^ Evans, Jason (2006年4月16日). “A Scalable Concurrent malloc(3) Implementation for FreeBSD”. 2012年3月18日閲覧。
  17. ^ Hoard: A Scalable Memory Allocator for Multithreaded Applications” (2000年). 2012年3月18日閲覧。
  18. ^ TCMalloc homepage
  19. ^ Ghemawat, Sanjay; Menage, Paul; TCMalloc : Thread-Caching Malloc
  20. ^ Callaghan, Mark (2009年1月18日). “High Availability MySQL: Double sysbench throughput with TCMalloc”. Mysqlha.blogspot.com. 2011年9月18日閲覧。
  21. ^ kmalloc()/kfree() include/linux/slab.h”. People.netfilter.org. 2011年9月18日閲覧。
  22. ^ Stroustrup, Bjarne (2008). Programming: Principles and Practice Using C++. 1009, §27.4 Free store: Addison Wesley. pp. 1236. ISBN 978-0-321-54372-1. 

関連項目[編集]

外部リンク[編集]