たぶんmallocの実装について、ほとんど何もわかっていないです。
ごみためのような場末のPGですら、K&Rとglibcとdlmallocの違いくらいを把握しています。
付け足すと、BoehmGCの歴史と偉大さも把握しています。
ところが、2020年ももう終わろうかという今、
glibcでメモリの断片化が疑われる
などと騒ぐシトたちの目撃情報が寄せられました。
そりゃまぁメモリ不足ぎりぎりまでメモリを確保した状態では断片化は無視できないでしょう。
ただし、それは断片化が問題なのではなくて、単なるメモリ不足ですよね。
そもそも「断片化」を定義できていないシトたちというわけですね。
断片化が原因で、全メモリの25%が空きなのに、メモリが確保できない、そんな状況が「断片化が問題となっている」状況です。
全メモリの5%しか空きがない状況で、メモリが確保できない、それは断片化が原因ではありません。そんな要求仕様はないものねだりです。
動的メモリ確保を捨てればきっと（断片化の駆逐を）実現できるでしょうが、メモリ使用の効率の低下は5%どころではないでしょう。(みんなが多めに確保するから)
こういう手合いは定性的な話しかできないので見分けるのは簡単です。
こういう手合いが「トレードオフ」というとき、実際にはトレードオフではありません。トレードオフの用法がイミフだからです。
最後になりましたが、ほとんど断片化は起きず、オーダーも線形だと、動画で説明されているのを、これほど有名なのに観ずに、メモリ確保のトラブルシューティングをするというのは、正気の沙汰ではないと思います。
もちろん、どのような実装にも穴はあり、不得意な状況はあるでしょう。
おかしなことを主張する手合いが、真実を突いていることは確かにありますが、この場合は、問題の定義を間違えているだけなのです。
dlmallocなんて、ソースをダウンロードすれば恐ろしくプアな環境でもコンパイルできてしまいます。ヘッダを読めばコンパイルスイッチのマクロも明確です。
そんなことはずっと前から同じなのです。知っていてもなんの技術的優位性もありませんが、知らないのはモグリなわけです。common senseですから。
なんといってもごみためですら、知っているんですよ？それを知らないでいたのなら、ただただ反省するべきでしょう。
