なぜ私たちは遅い `malloc`を持っていますか？

Question

私が知る限り、カスタムメモリマネージャはいくつかの中規模および大規模プロジェクトで使用されています。このrecent answerのsecurity.seは、パフォーマンス上の理由からOpenSSLのカスタムメモリアロケータが含まれており、最終的にHeartbleedの悪用を悪化させたという事実について説明しています。このold threadはメモリアロケータを扱います。特に、mallocが遅いためにカスタムメモリアロケータを書いているのに対して、汎用の最先端アロケータは簡単にビートを奪うという学術論文の回答リンクの1つですすべてのプロジェクトでホイールを再開発している開発者よりも問題が少なくなっています。

専門的にプログラムを作成していない人として、私はこの状態でどのようにして終わったのか、そこにこだわっているのは不思議です。スレッドの安全性などの微妙な問題がなければならないと思います。状況を間違って提示している場合は申し訳ありません。

mallocは、これらの「汎用の最先端のアロケータ」のパフォーマンスに合わせて開発され、最適化されないのはなぜですか？ OSや標準ライブラリの作成者にとっては、それが非常に重要な機能になるはずです。過去のLinuxカーネルでのスケジューラーの実装について多くの話を聞いたことがあります。たとえば、メモリアロケータの関心は多かれ少なかれ同じになると思います。どのように標準mallocは非常に多くの人々がカスタムアロケータを展開する必要があると感じて悪いですか？システムのプログラマがLinuxやWindowsにデフォルトまたはリンク時のオプションとして組み込まれていないのはなぜですか？

Answer 1

二つの問題があります。

1. は、単一の割り当て方式は、すべてのアプリケーションのニーズに合っていません。

2. Cライブラリの設計が不適切（設計されていない）でした。非宦官オペレーティングシステムの中には、アプリケーションが割り当て方式を選択できるように設定可能なメモリマネージャがあります。 eunuchs-landでは、解決策は自分のmalloc/free実装をアプリケーションにリンクすることです。

実際の標準malloc実装はありません（GNU LIBCはおそらく標準に最も近いでしょう）。 OSに付属するmallocの実装は、より多くのアプリケーションでうまく動作する傾向があります。