- ベストアンサー
メモリ管理
Cでメモリー管理に関して次のようなLIBがあればいいなと思っています。 目的:使うたびに確保、開放では効率がわるいので共通の領域を使いまわす 条件:XXXMallocで使用するサイズはバラバラ (1)メモリーをまとめて「XXXLIBの領域」用に確保 (2)XXXMallocを実行するとメモリ管理が「XXXLIBの領域」から切り出してくる ここで足りなければ自動で大目に確保 (3)不要になったらXXXReleseで開放し、あとで使いまわしする こんなものが存在する事を知っている方は教えてください。
- みんなの回答 (6)
- 専門家の回答
質問者が選んだベストアンサー
malloc/freeのヒープ実装も、 近いことやってたりすることが多々あるわけですがご存知ですか? (本当に素直に毎回OSからメモリ取ったりせず、内部で使いまわしたり) どこのライブラリをお使いですか? で、既出のような例えばサイズが同じとかタイミングが保証できるとか 「汎用でない、美味しい条件」がないかぎり、mallocでもそう差はないと思います。 で、この手の条件がある場合のパターンがメモリプールで、 これだと格段に早く/効率よくなりえますが、一般には汎用性が犠牲になります(使い方に条件が付く)。これも既出。
その他の回答 (5)
- Oh-Orange
- ベストアンサー率63% (854/1345)
★標準ライブラリなどでは malloc / free 関数ぐらいでしょう。 ・回答者 No.5 さんと同じように私も以前にメモリプールを扱う自作ライブラリを作成して 使っていました。もちろん、今でも大量のデータを確保や解放を繰り返すタイプのソフト では、自前のライブラリからメモリを確保/解放をしています。 ・質問者さんも暇があれば1度、メモリ管理のライブラリを自作してみるのはどうでしょう。 ヒント: ・私の作ったメモリ管理ライブラリは、昔の MS-DOS 時代のメモリ管理ブロック(MCB)を ヒントにメモリのデータを鎖のように繋ぎ管理させました。しかし、このままでは単方向で しか空き領域を検索できないので確保領域を探すのに時間が掛かります。そこで空き領域用に 空きデータを鎖のように繋ぎ単方向リスト管理させます。これで、開き領域の検索が少し高速 になります。それとメモリを解放するときには、開き領域のチェインに登録させますが、同時 に開き領域の合併処理も行います。→この合併処理の工夫がポイントです。私は使用・未使用 の独自メモリマップをテーブルとして用意して、そこから合併するかの判定を行いました。 ・また、メモリ領域が不足したら realloc などで容量を拡張します。 ただし、拡張するとポインタ位置がずれたりしますので、データはポインタ管理ではなくて 先頭メモリブロックからのオフセット値で管理して、データの読み書き時にポインタに変換して 操作を行います。 最後に: ・上記のはメモリ管理の一例です。 ・もっとよいメモリ管理のライブラリをそのうち作成する予定ですが、今現在は保留状態です。 ・以上。参考にして下さい。
お礼
ご回答ありがとうございます。 メモリ管理は自前で作成することになりそうです。 空きデータを鎖のように繋ぐ方法、オフセット値の管理は大変参考になります。
- noocyte
- ベストアンサー率58% (171/291)
私は昔,2種類のメモリプール (固定長データ用と可変長データ用) ライブラリを作り,今でも時々使ってます. (いずれ暇なときに自分のサイトで公開しようかとも考えていますが.) 可変長データ用は #2 さんが書かれているように,最初に大きな領域を 確保しておき,先頭から順に要求されたサイズを割り当てていく方式です. これだと malloc/free を1回ずつ呼べばよく,高速化できます. ただし割り当てた領域を個別に解放することはできません. また,さまざまなサイズのデータが混在するので,できるだけ隙間が できないようにするために,割り当てる際にはサイズだけでなく アラインメントも指定する仕様にしています. # malloc() の実装に興味を持っている人でも,意外とアラインメントの # ことを知らない人が多いことを以前知って驚きました.
お礼
返事が遅くなりました。アラインメントは今回勉強させていただきました。ありがとうございます。
- koko_u
- ベストアンサー率12% (14/116)
>条件:XXXMallocで使用するサイズはバラバラ アロケーションされるサイズがバラバラでは malloc & free に敵う実装は凡人には無理。
お礼
返事が遅くなってすみません。参考になりました。
- jacta
- ベストアンサー率26% (845/3158)
メモリプールがそれに該当するかと思います。既成の機能が使えるかどうかは環境に依存します。例えば、μITRONでは、cre_mplでメモリプールを生成し、get_mplでメモリブロックを獲得、rel_mplで解放します。メモリプール全体が不要になれば、丸ごとdel_mplで破棄できます。 アプリケーションでの用途によっては、もっと簡単な実装も可能です。例えば、特定のモード内でだけ使うアロケータであれば、次の割り当て位置を指すポインタだけを単純に進めていき、モードから抜ける際にまとめて解放する等です。 排他制御も不要になるケースが多いので、mallocに比べて桁違いに高速になる可能性があります。
お礼
返事が遅くなってすみません。μITRONのページを見て見ました。イメージに近いものです。 アプリケーションでの用途はサイズがバラバラで使いまわすので、つくりは簡単にはいかなそうです。
要はアドレス管理だけをできればよいので、自分で作れそうですね。 ただ、どれくらいの効率が良くなるかわからないですし、バグると致命的になりそうなので自分は遊び以外で使う気はしませんが。
お礼
返事が遅くなってすみません。たしかにリスクはありますよね。
お礼
回答が遅くなり生ました。 malloc/freeが近いことやっている件は知りませんでした。 lib名は環境が手元にないので不明ですがOSはlinuxです。 mallocでもそう差はないというのはサンプルで試して見ることにします。 たいへん参考になりました。