glibc mallocの解説 Video: https://youtu.be/0-vWT-t0UHg

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

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

4. 古典的 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; };

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

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

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

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

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

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

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

12. 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 したい 領域

13. 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 を今開放した要素を 指すよう動かす

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

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

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

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

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

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

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

21. やや脱線

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

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

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

32. やっぱり 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 はポインタで 持たずサイズで保持している。

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

38. というわけで 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 メンバ以外はあるかどうか 分からない 構造体の型とメモリ上のデータ構造がまるで 一致していない香ばしい構造 -> 読みにくさの主原因 ブロック１ ブロック２ ブロック３ ブロック４

39. 時系列で見ると 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 メンバはユーザに使われて しまうので壊される

40. 時系列で見ると 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 フラグが１に

43. 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 の配列

45. 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

47. その為の mmap です

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

82. 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

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