巨大なメモリ割り当ての場合、glibcはヒープを使用せずに、代わりに無名メモリマッピングを用いてメモリを割り当てます。
char *p = malloc(sizeof(char) * 100);
サイズが大きいと通常とは異なり、内部的に無名メモリマッピングを行っているようです。
void *p = mmap(NULL, 512 * 1024, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
mmap
mallocでサイズの大きい領域を確保しようと失敗してしまいます。
このヒープ領域が巨大なメモリ領域確保に向いていない理由を教えてください。
わたしの持っている本にはこう書いてあります。
mallocの古典的な実装方法では、データセグメントを2の累乗のサイズの領域が並んだ状態に分割し、要求されたサイズに最も違い領域を返すことでメモリ割り当て要求に応えます。(省略)
このアルゴリズムをバディメモリ割り当て方式という言います。
速度面と簡潔性という点では効果がありますが、2種類のフラグメンテーションという問題をはらんでいます。
この方式では、あるメモリ割り当てが他のメモリ領域をその場に固定してしまい、glibcが未使用メモリをカーネルへ返却できなくなる場合もあり得ます。
2つのメモリ領域、領域A,領域Bを割り当てた場合を考えてみましょう。領域Aがbreakpointに隣接しており、領域Bは領域Aに続いているとします。
プログラムが領域Bを解放したとしても、領域Aが解放されない限り、glibcはbreakpointを移動できません。
この方式では長時間存在するメモリ領域が他のメモリ領域をメモリ上に固定してしまうのです。
このことが常に問題になるとは限りません。glibcは毎回メモリをシステムへ返却しないためです。
一般的に、ヒープはメモリ解放のたびに縮小されず、glibcが以降のメモリ割り当てに備えて未使用メモリを管理します。
glibcは現在割り当てられているメモリサイズよりもヒープサイズが十分に大きいを判断した場合のみデータセグメントを縮小します。
しかし巨大なメモリ領域を割り当てれば、この縮小処理が行われなくなることもあり得ます。
.....?
最後の方がわかりません。
現在割り当てられているメモリサイズとはどこのメモリを指しているんですかね?
巨大なメモリ領域を割り当てると、なんで縮小処理が行われなくなるんですかね?
リンク内容
**malloc()**はbrkやsbrk()でbreak pointをズラし、ヒープ領域に線形リストを作成しているのかな(?)
**free()**内で確かにbreak pointを元に位置に戻してはいません。
縮小作業はmain()に入る前に行われているのでしょう。
わかる方いましたら、教えてください。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/08/05 11:51
2017/08/05 11:58