Glibc malloc internal

malloc の旅（ glibc 編） kosaki ＠ぬまづ

今日は何の話？ libc でもっとも良く使われる関数、 malloc と free の実装の解説もっと一般的に言うと、プロセスのアドレス空間のうち、 heap 領域とよばれる、場所を操作する関数の説明解説というと聞こえはいいが、そんな大層なものじゃない

Linux での process address space model kernel stack text mmap data bss heap 矢印はデータ量の増加とともに、伸びる方向使用中使用中使用中今日は、ここ、 heap と呼ばれる領域のお話 low high free free free

古典的 malloc プログラミング言語 C （いわゆる K&R) で紹介された初期の Unix の malloc 実装使用中使用中使用中 free listの head 使用中・ free list を使って空きメモリを管理・プロセス全体でただ１つの Heap を使う・ malloc するときに管理領域分だけ多く allocate して先頭に管理領域を付加 ( どこかに管理領域がないと free するときに開放 size がわからない ) ・割り付け strategy は first fit. union header{ struct{ union header* ptr; unsigned size; }s; long alignment; };

malloc のアルゴリズム使用中使用中使用中 free listの head 使用中このぐらい欲しいＸ足りない１．まず、 list head から先頭ポインタを get ２．空き領域が十分か調べる・・・・小さすぎた

malloc のアルゴリズム使用中使用中使用中 free listの head 使用中Ｘまた足りないＸこのぐらい欲しい１．まず、 list head から先頭ポインタを get ２．空き領域が十分か調べる３．ポインタを list の次の要素に進める４．また空き領域が十分か調べるうむむ。。また小さい

malloc のアルゴリズム使用中使用中使用中 free listの head 使用中１．まず、 list head から先頭ポインタを get ２．空き領域が十分か調べる３．ポインタを list の次の要素に進める４．また空き領域が十分か調べる５．また、ポインタを次の要素に進める６．またまた、空き領域を調べる今度はあった！！ＸＯＫＸこのぐらい欲しい

malloc のアルゴリズム使用中使用中使用中 free listの head 使用中１．まず、 list head から先頭ポインタを get ２．空き領域が十分か調べる３．ポインタを list の次の要素に進める４．また空き領域が十分か調べる５．また、ポインタを次の要素に進める６．またまた、空き領域を調べる７．空き領域を２つに分けて、 free list をつなぎなおす８． list head を更新今確保した領域最後に探索が失敗した場所（アロケートされたメモリの１つ前の要素）を指すように変更

実は・・・使用中使用中使用中 free listの head 使用中実はもう１つ先を探すと、もっといい場所があったのに・・・ＸＸこのぐらい欲しい今確保した領域

free のアルゴリズム使用中使用中使用中 free listの head 使用中 free したい領域１． free list head から最初のポインタをゲット２．最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) ３． p < bp < next が成立しないので次へ bp p next

free のアルゴリズム使用中使用中使用中 free listの head 使用中 free したい領域 bp p next １． free list head から最初のポインタをゲット２．最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) ３． p < bp < next が成立しないので次へ４． p を次の要素に進める 5 ．次のポインタをゲット 6 ． p < bp < next が成立した

free のアルゴリズム使用中使用中使用中 free listの head 使用中 bp p 7 ． p と bp は隣接していない (p + p->s.size != bp) ので併合しない next １． free list head から最初のポインタをゲット２．最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) ３． p < bp < next が成立しないので次へ４． p を次の要素に進める 5 ．次のポインタをゲット 6 ． p < bp < next が成立した 8. bp と p->s.ptr は隣接しているので (bp + bp->s.size == next) 併合 free したい領域

free のアルゴリズム使用中使用中使用中 free listの head 使用中 bp p 7 ． p と bp は隣接していない (p + p->s.size != bp) ので併合しない next １． free list head から最初のポインタをゲット２．最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) ３． p < bp < next が成立しないので次へ４． p を次の要素に進める 5 ．次のポインタをゲット 6 ． p < bp < next が成立した 8. bp と p->s.ptr は隣接しているので (bp + bp->s.size == next) 併合 9. free list head を今開放した要素を指すよう動かす

次に malloc の特殊なケース heap にまったく空きがなくて heap 自体を拡張するケースを説明します

ヒープ拡張使用中 free listの head 使用中このぐらい欲しい heap は無限ではないのでいつか足りなくなるＸ足りない

ヒープ拡張使用中 free listの head 使用中このぐらい欲しい heap は無限ではないのでいつか足りなくなるＸ足りないＸ

ヒープ拡張使用中 free listの head 使用中このぐらい欲しい heap は無限ではないのでいつか足りなくなるＸ足りないＸＸ

ヒープ拡張使用中 free listの head 使用中このぐらい欲しい heap は無限ではないのでいつか足りなくなるＸＸＸ ptr と free list の head が再び一致（一周してしまった）

ヒープ拡張使用中 free listの head 使用中このぐらい欲しい heap は無限ではないのでいつか足りなくなるここで brk システムコールで heap 領域を一気に伸ばす brk は heap 最後尾アドレスを変更するＡＰＩ heap 最後尾 heap 最後尾

ヒープ拡張使用中使用中 heap は無限ではないのでいつか足りなくなる heap 最後尾今確保した領域増えた領域を 2 つにわけ、先頭をユーザに返却。残りを free list につなぐ free listの head

素朴な brk の実装 0. データセグメントには静的データとスタックが入っている 1. 現在値＋増加分で (kernel 内で ) malloc 2. 新しいメモリにメモリコピー 3. 古いデータを mfree 4 スタックを末尾にメモリコピー 5. スタックと静的データの間をゼロクリア new memory data data stack stack 出典： Lions ’ Commentary on UNIX 増加分 data stack data stack data stack data stack data stack

つまりカーネル brk がくそ遅いあんまり brk 呼ばなくてもいいように、ユーザー空間で「なるべく brk しない。するときはガバッと一気に取る」方針でいくとかいう価値観で実装されておりまする

さて実は brk も、イマドキの Linux では大幅に高速になっているのだが、それは今回は考えない事にする今はｂｒｋが遅いって前提で malloc の高速化を考えていくぜい脱線終わり

K&R malloc のいいところ単純コードサイズが小さい。（組み込みとかも malloc はいまだにこんな形しとるよ）フラグメンテーションが進まない限り malloc は O(1) プログラム全体で数十回しか malloc しないような小規模プログラムではとてもうまく動く

K&R malloc のダメなところ小さい malloc が多発するとフラグメンテーションがすぐ進む free が O(n) brk が呼ばれる状況では一回 freelist を一周する必要がある（リストが数万個もあれば、なにそのキャッシュ・フラッシング・コード状態）フラグメンテーションが進むとメモリ効率も急激に悪化

時代は変わった・・・イマドキなプログラミング GUI スクリプト言語や Java C++ プログラミング等々は、まさに小さい malloc が連発される

最大の問題はなんだろう？ここは、とりあえずフラグメンテーションが最大の問題だと仮定しようフラグメンテーションさえ解決すればメモリ使用効率 UP! 使用メモリ量が減れば、それだけキャッシュに載る確率 UP! なんかｶｺ ( ･∀･ ) ｲｲ !

とゆーわけで、時代は best fit アロケータなのである

で、 Just Idea に従って実装してみる

アドレス順をやめて、サイズ順にソートしてみる使用中使用中使用中 free listの head 使用中 free の時に、隣接要素と併合することが不可能に・・・・よけいフラグメンテーションが進みました本末転倒

やっぱり malloc header にメンバを増やすしかない struct malloc_chunk { INTERNAL_SIZE_T prev_size; INTERNAL_SIZE_T size; struct malloc_chunk* fd; struct malloc_chunk* bk; }; 使用中使用中使用中 free listの head 使用中変数名を glibc にあわせたので、だいぶ雰囲気が変わったけど気にしない address space の prev, next はポインタで持たずサイズで保持している。

何が変わったのか良くなったところ free が typical で O(n) から O(1) へフラグメンテーションによる空間の無駄が減る悪くなったところ malloc が typical で O(1) から O(n) へヘッダサイズが増えて空間効率ダウン

だめだめですむしろ此処からが本題

ヘッダのダイエットが必要ですまず、 free list のポインタ、 bk, fd は割り付け済みブロックには必要ないこれは単純に削ればいいアクセス方法には注意 prev_size size fd bk malloc_chunk 構造体にキャストしてアクセスするので一見、 fd, bk メンバがあるように見えるが、実はそこはユーザアプリに使われてしまっているのでアクセスするとメモリ破壊ソースコードからは読み取りにくい・・

ダイエットはつづくよ・・・よーく考えると prev_size メンバは free 時の合併処理のみに必要とゆーことは、 prev が free 状態のときのみ必要 prev_size は prev が free の時のみ記録したいちょっとまってどうやって、 prev が free 状態か調べればいいんだっけ？（卵と鶏問題）

下位 2bit は絶対０になるよね glibc malloc は実際には内部で 8 の倍数に切り上げるから、下位３ bit は 0 size メンバは２つのポインタの差を記録しているのだから、当然、同じく下位 3bit が０ 32bit なシステムのポインタって・・０ 31 １２ポインタ 0 0

というわけで prev_size size fd bk size fd bk use free free prev_size size use size 1 0 size メンバの再下位 bit を prev が USE 状態かを記録するビットとして使う（図中の　　　が最下位ビットを示している）再下位が０なら prev_size メンバがある。１１ free() 関数で chunk_p = (malloc_chunk*)(((char*)ptr) - sizeof(size_t)*2); なんてやってるけど、 size メンバ以外はあるかどうか分からない構造体の型とメモリ上のデータ構造がまるで一致していない香ばしい構造 -> 読みにくさの主原因ブロック１ブロック２ブロック３ブロック４

時系列で見ると prev_size size fd bk use free free prev_size size fd bk 0 １１ prev_size size fd bk use free free prev_size size fd bk 0 １ prev_size size fd bk malloc １１ prev_size size fd bk prev_size size fd bk 余分に確保するメモリは４バイトのみ。 request2size() が req + sizeof( malloc_chunk) ではなく req + sizeof(size_t) なのはここに原因があった！！ malloc 編 malloc ヘッダ malloc ボディ（使用中） malloc ボディ（ free ）当然だけど、 malloc ヘッダから突き抜けている malloc_chunk メンバはアクセスしたらエライ事になります fd,bk メンバはユーザに使われてしまうので壊される

時系列で見ると use free 1 １１１ prev_size size fd bk prev_size size fd bk use prev_size size fd bk prev_size size fd bk free free 1 １ 0 １ prev_size size fd bk prev_size size fd bk use prev_size size fd bk prev_size size fd bk free の時に初めて fd, bk, prev_size メンバが書き込まれる size メンバ以外は、 malloc 時には確保してなかったのだがどうせ free じゃーん。あいてるじゃーん。という訳で勝手に使ってる。ソース上はとってもメモリ破壊ちっく free free 編ここで prev_in_use フラグが１に

ダイエットは出来たのである意味、本日の code reading の最難関部分は突破 (^-^; （他の部分は、ちゃんと C 言語ちっくな C のソースコード (?) なので）次は最大の課題。 malloc() が typical で O(n) じゃーん。問題を片付ける

ここでアイデア別に free list で、１つのリストに全部つながなくてもいいよね？サイズは絶対８の倍数なんだから、サイズ１６用のリスト、サイズ２４用のリスト・・・・ってやったら best fist かつ O(1) じゃね？

small bin 16 24 32 40 504 ･･･ size index 2 63 3 4 5 chunks これで小さいサイズの malloc が /* 8 の倍数に切り上げ */ size = request2size(req); if( size <= 512 ) { bin_index = size/8; chunk = bins[bin_index].bk; unlink(chunk); /* remove freelist */ return chunk + sizeof(size_t)*2; } このぐらい簡単に終わる構造体とかはたいてい、このぐらいのサイズにおさまるよね？ best fit どころか、 just fit アロケータですよ。と 8 8 8 8 8 bin width free list head の配列

さらに改良 512byte over の部分が手付かずでも、大きいサイズにも 8byte おきに bin を用意するのは現実的じゃないでもリストを複数もつ。というアイデアは悪くない

large bin 588 652 716 780 ･･･ size index 65 123 66 67 68 64 64 64 64 32K bin width 124 32K 125 250K 126 250k 127 ∞ グラフにするとこんなカンジ bin width bin index bin index が大きくなるにつれ、あつかう block size の幅が指数的に大きくなるように調整小さいサイズのほうが数が多いので、リストにつながる数を平均化するための施策大きなサイズ用のリストヘッドも 64 個つくる･･･ 512 4k ･･･ 750k more

でもどう頑張っても、一番ラストの bin は一杯つながってしまうんだよね画像とか扱うと平気で数十 M とか malloc するし・・・・あーあ、 Heap をもう１つ用意できたらでかいメモリを完全に分離できるのに・・

anonymous mmap とは？ mmap は、本来ファイルをメモリにマップするシステムコールでも fd 引数に “ /dev/zero” を渡すことにより、メモリ確保 API として使用可能この API を使って、 Huge Block( デフォルトで 128K byte 以上 ) は heap からではなく、 mmap で直接 kernel から取得する

またしても size メンバの下位 bit を０ 31 １２ size 0 0 0 IS_MMAPED PREV_IN_USE 下から２ bit 目を mmap から取得したよーん。という意味で使うことにする。この bit が ON なら free list からではなく MMAP で取得しているので、 free 時に freelist につながずに、いきなり munmap() する

データ構造図解使用中使用中使用中使用中使用中 (huge) 使用中 (huge) bins ※ １見やすくするために、リストをつなぐ線の種類を少しずつ変えてある ※ ２ Huge かつ free 状態はありえない。開放と同時に OS に返却するから

この方法の利点 Huge Block も malloc, free ともに O(1) フラグメンテーション、むっさ起きにくい（リスト管理してないんだから当たり前）メモリの無駄が少ない（でっかいメモリは同じサイズで再度 malloc される確率は低いので、すぐさま OS に返却するのは賢い戦略）

ここまでの結果良くなったところ malloc が typical で O(1) free が typical で O(1) フラグメンテーションがすごく起きにくくヘッダサイズは実質４バイト brk が発生するときに、 K&R malloc では freelist を一周する必要があったのが、要求サイズより大きい bin を検索するだけでよくなった。平均で探索コスト 1/2 悪くなったところなんかあったっけ？

でも！それでも！しばしば、 K&R malloc に負けるんです。これが実は large size block の malloc – free –malloc – free と繰り返す割り当てが遅い

K&R free を振り返ってみる使用中使用中使用中 free listの head 使用中 bp p next 9. free list head を今開放した要素を指すよう動かす今開放した要素ここがポイント

キャッシュと局所参照性 heap メモリーに一番アクセスする確率が高いのは malloc 直後と free 直前である free されたばかりのメモリはキャッシュに載ってる確率が高いそこから優先してメモリ確保することは malloc 直後のアクセスでキャッシュミスしなくなるということキャッシュのヒット率重要

バッファの遅延合体 free が呼ばれたときに、すぐに隣と併合＆ free list につなぐ処理をやめる最初にこのアイデアを実装したのは SVR4 らしい ( 最前線 UNIX のカーネルより ) malloc – free – malloc – free という非常によくあるアクセスパターンでメモリブロックの分離・併合・分離・併合という無駄な処理が避けられる。かつ、 free された順に時系列にリストにつながっているので、リスト先頭の block をアプリに返せばキャッシュヒット率向上

バッファの遅延合体その２ gligc malloc では最低確保サイズが 32 なので bins[0] と bins[1] は使ってない bins[1] をこの遅延されてる block をつなげるリストのリストヘッドとして特別な意味で用いるソースコード上は unsorted_chunk と呼ばれているが、ソートしない＝時系列順である。リストをたぐって、要求サイズと一致するものを検索要求サイズと一致しないものは、この時点で、隣と併合して実際の free 処理

マクロな視点で話をすると malloc の呼び出しパターンはたいてい以下のような経過をへるアプリ起動時はやたら malloc が呼ばれる。 free はほとんど呼ばれないその後、 malloc と free がほぼ交互に呼ばれる定常状態に入る GUI の画面遷移のような、なんからの契機で、 free がひたすら呼ばれ、次に malloc がひたすら呼ばれるデータ構造の大転換がおこるそしてまた定常状態に・・・・

malloc の定常状態とバースト状態バースト状態バースト状態このとき、遅延併合が裏目に出る。遅延併合リストに要素が一杯たまるからメモリ使用量定常状態遅延併合は裏目にでることもあるが、いちばんありがちな、定常状態で高速化されるのでモトがとれる

まだもうちょっとだけ続くんじゃ

みんな大好きマルチスレッド猫まっしぐら！

素朴な lock malloc(size_t sz){ lock(); ptr = internal_malloc(sz); unlock(); return ptr; } ご冗談でしょう。ファインマンさんたんじゅんに、関数全体を mutex で保護してみた

本当はこうしたい使用中使用中使用中使用中使用中使用中使用中使用中 bins 使用中使用中使用中使用中 bins bins スレッド１スレッド２スレッド３スレッド１専用 heap スレッド 2 専用 heap スレッド 3 専用 heap ロックのいらない素敵な世界

それは流石に無理アプリがいくつスレッドをつくるか事前に知る方法はない１つのスレッドが最大どのくらいのメモリを使うのか事前に知る方法はない ITRON だと両方ともコンパイル時に決まるのに・・

そこで以下のように実行時に新しい heap を作っていく

Arena 生成使用中使用中使用中使用中 bins スレッド１ main_arena main_arena == 今まで説明してきた heap アクセスロック arena 構造体

使用中使用中使用中使用中スレッド１ main_arena アクセスロックアクセス、しかし、ロックとれず bins arena 構造体スレッド 2 別のスレッドが malloc を同時に呼ぶと、ロック取得 (mutex_trylock) に失敗 Arena 生成スレッド２

Arena 生成スレッド２使用中使用中使用中使用中スレッド１ main_arena アクセスロックスレッド 2 新しい自分専用 heap を mmap で作成この altanative heap の仕組みを arena と呼んでいる。 TLS(thread local strage) に自分用 arena を覚えておくのでスレッドが増えるか 1M 使い切るかしない限り二度とバッティングしない bins arena 構造体とってきたメモリの先頭を arena 構造体（ bin 配列などが入っている構造体）として使う 1M free mmap arena 同士は list でつなげる

Arena 生成スレッド３使用中使用中使用中使用中スレッド１ main_arena スレッド 2 bins arena 構造体 free アクセススレッド 3 アクセス次のスレッドも、ロック競合が起きるまでは main_arena を使い続ける

Arena 生成スレッド３使用中使用中使用中使用中スレッド１ main_arena アクセスロックスレッド 2 bins arena 構造体 free アクセススレッド 3 アクセスロックがぶつかったら・・・・

Arena 生成スレッド３使用中使用中使用中使用中スレッド１ main_arena アクセスロックスレッド 2 bins arena 構造体 free アクセススレッド 3 アクセス arena list を、たぐって次々とロック取得をチャレンジすべて失敗したら、また新しい自分専用 arena を作る。

Arena 生成スレッド３使用中使用中使用中使用中スレッド１ main_arena アクセスロックスレッド 2 bins arena 構造体 free アクセススレッド 3 mmap いきなり arena 生成をしないのはスレッド２がすでに終了していたときに、その専用 arena が無駄になるのを防ぐためこれにより、スレッド生成直後は色々な arena でロック競合するがそのうちに、 1 スレッド・ 1 アリーナに収束する free

１スレッド：１ Arena の隠れた利点 SMP マシンでは、別の CPU からアクセスしたメモリは自分 CPU のキャッシュには乗らないのでラストアクセスを単純に管理してはうまくいかないしかし、ユーザ空間から自分がどの CPU で動いているのか明に意識するのは無理（いつのまにか勝手に変わるし）そこでカーネルがもつスレッドの CPU affinity スケジューリングに着目して、自分スレッドがアクセスしたデータは自分 CPU でアクセスした確率が高いと考えるスレッド専用メモリ＝キャッシュヒット率がものすごく Up!

ところで free するときに、自分の所属する arena ってどうやって見つけるんだっけ？

だめアイデア１ TLS から arena を取得 -> 自分専用 arena を作る前に何回か main_arena から取得している分がある。それは、 main_arena に戻さないと。

だめアイデア２それぞれの malloc header に arena へのポインタを追加する -> なんのために死ぬ思いでヘッダを４バイトまで削ったと思ってるんです？

だめアイデア３ main_arena （唯一のグローバル変数）から arena のリストをたどって・・・ -> O(n) の検索はダメだっつってんだろ！

結局どうしたか？ arena を絶対 1M align されるようにメモリを確保する。すると、 ptr & ~0xFFFFF するだけで arena へのポインタが得られるようにする

課題 1 main_arena はグローバル変数なんだけど・・・０ 31 １２ size 0 0 0 IS_MMAPED PREV_IN_USE -> 毎度おなじみ size メンバハックのお時間でございま～す♪ IS_NON_MAINARENA

課題 2 Linux に 1M align を保障するメモリ確保システムコールってないんだけど -> 以下のちょっとトリッキーな方法で可能　　　　（次ページ参照）

Arena で 1M にそろえる方法図解 0x100000 0x200000 こういうメモリ確保がしたいしかし mmap では出来ない。 low high use free free １ M アライン

Arena で 1M にそろえる方法図解 0x100000 0x200000 2 倍のサイズで mmap ただし PROT_NONE 0x100000 0x200000 余分な場所を munmap READ も WRITE も EXEC も不可なメモリ確保というのはメモリを確保しないが、アドレススペースは確保するというのと同義 1M アラインされた場所から size 1M で PROT_READ | PROT_WRITE | PROT_EXEC で remap. 0x100000 0x200000

まとめ小さい malloc は回数がすごくたくさん呼ばれるので、 O(n) ではダメフラグメンテーションを防ぐには Huge 　 Block は Heap を分けるのが効果的キャッシュヒット率を上げるには、参照局所性超重要 per Thread なデータ構造は per CPU なデータ構造のよい近似値

glibc malloc のダメなところ Huge Block が絶対 page align されてしまうので、キャッシュが競合しやすい（ HPC 分野ではこの機能は OFF にするのが一般的）もう一工夫すれば、 Arena へのロック自体なくせる（これが問題になるような heavy allocation アプリは自前 heap 管理をしてるので効果は見えにくいかも）最新の dlmalloc は large-bin の管理がリストからバイナリツリーに変更されて高速化が図られている（でも使用率がいまいち低いので効果は微妙か？）

終わりに変えて glibc malloc は、今日のスライド 90 枚にわたる色々なアイデアが int_malloc() という１つの関数にごった煮で詰め込んであるので、すごく読みにくいおまいら、ソースコードのコメントにうそを書くなと小一時間・・おまいら、関数分割ぐらいしろと小二時間・・・おまいら、構造体の型とメモリ上のデータ構造は合わせておけと小三時間・・・これを見ると Linux kernel ってなんて読みやすいのかと・・・・

ご清聴ありがとうございました！つかれた～ (≧ω≦) ゞ

Glibc malloc internal

More Related Content

Glibc malloc internal