1

このアロケータは、静的メモリを持つ組み込みシステム内で使用されます (つまり、利用可能なシステム ヒープがないため、「ヒープ」は単に「char heap[4096]」になります)。

「小さなメモリ アロケータ」はたくさんあるようですが、本当に小さなメモリ アロケータを処理できるものを探しています。私は、CPU の使用量が少なく、メモリの使用量が少ない 16 バイトの典型的なサイズについて話しています。

典型的な割り当てサイズが <= 16 バイト、まれな割り当てが <= 64 バイト、「100 万分の 1」の割り当てが最大 192 バイトであることを考慮すると、これらの 4096 バイトをそれぞれ 16 バイトの 255 ページに単純に切り刻むことを考えます。ビットマップと「次の空きチャンク」ポインターを持っています。したがって、検索するのではなく、メモリが使用可能な場合は、適切なチャンクがマークされ、関数はポインターを返します。最後に到達すると、必要なサイズの適切なスロットが検索されます。システムの性質上、以前のブロックは「次の空きチャンク」が「ヒープ」の最後に到達するまでに解放されているはずです。

そう、

このようなものがすでに存在することを誰かが知っていますか？そうでない場合、誰かが私の理論に穴を開けることができますか? または、彼らはより良いものを提案できますか？

C のみ、C++ はありません。(アプリケーション全体は <= 64KB に収まる必要があり、これまでのところ約 40K のグラフィックがあります...)

4

1 に答える 1

1

OP: 誰でも私の理論に穴を開けることができますか?

前半を読んで、ビット配列を使用して使用法を記録する解決策を考え出し、後半で概説したのと同じことを効果的に思いつきました。

ここに穴があります。16 バイト ブロックをハードコーディングしないでください。開発の開始時に、ビット マップが、たとえば 20 または 24 バイト ブロックで動作できるようにします。この間、ブロックの端にタグ情報とセンチネルを配置することをお勧めします。したがって、 double free() 、割り当て外の使用などをより簡単に追跡できます。もちろん、価格はより小さな有効なプールです。

デバッグ段階の後、自信を持って 16 バイト ソリューションを使用してください。

必ず 0 <= 合計割り当て <= (2048 - オーバーヘッド) を追跡し、ビットマップと比較してチェックできるようにしてください。

デバッグの場合は、解放されたブロックを「0xDEAD」などで埋めて、不注意による解放の使用エラーを強制することを検討してください。

于 2013-09-14T03:01:28.823 に答える