プログラミングの概念として、記憶に関する本を読んでいます。後の章の1つで、著者はWord arenaを多用していますが、決して定義していません。私は言葉の意味とそれが記憶にどのように関係しているかを探しましたが、何も見つかりませんでした。著者がこの用語を使用するいくつかのコンテキストを以下に示します。
「シリアル化の次の例には、特定のarenaからのメモリ割り当てと呼ばれる戦略が組み込まれています。」
「...これは、メモリリークを処理するとき、または特定のarenaから割り当てるときに役立ちます。」
「...メモリの割り当てを解除する場合は、arena全体の割り当てを解除します。」
著者は、1つの章で100回以上この用語を使用しています。用語集の唯一の定義は次のとおりです。
アリーナからの割り当て-最初にアリーナを割り当て、次にプログラム自体によって(プロセスメモリマネージャーによって)アリーナ内の割り当て/割り当て解除を管理する手法。複雑なデータ構造とオブジェクトの圧縮とシリアル化、またはセーフティクリティカルシステムやフォールトトレラントシステムのメモリ管理に使用されます。
これらのコンテキストがあれば、誰でもarenaを定義できますか?
アリーナとは、一度割り当てたメモリの一部を手作業で管理するために使用する、大きくて連続したメモリのことです。例えば:
char * arena = malloc(HUGE_NUMBER);
unsigned int current = 0;
void * my_malloc(size_t n) { current += n; return arena + current - n; }
ポイントは、メモリ割り当ての動作を完全に制御できることです。制御できないのは、初期割り当てのための単一のライブラリ呼び出しだけです。
一般的な使用例の1つは、各アリーナが単一の固定サイズのメモリブロックを割り当てるためだけに使用される場合です。その場合、非常に効率的な再生アルゴリズムを作成できます。もう1つのユースケースは、「タスク」ごとに1つのアリーナを用意することです。タスクを完了すると、アリーナ全体を一度に解放でき、個々の割り当て解除を追跡する必要がなくなります。
これらの手法はそれぞれ非常に専門的であり、通常、自分が何をしているか、そして通常のライブラリー割り当てが十分でない理由を正確に知っている場合にのみ役立ちます。優れたメモリアロケーターは既に多くの魔法を実行することに注意してください。メモリを自分で処理し始める前に、十分ではないという十分な証拠が必要です。
これと一緒に行きます 可能な答えとして。
•Memory Arena (also known as break space)--the area where dynamic runtime memory is stored. The memory arena consists of the heap and unused memory. The heap is where all user-allocated memory is located. The heap grows up from a lower memory address to a higher memory address.
ウィキペディアの同義語 :地域、ゾーン、アリーナ、エリア、またはメモリコンテキストを追加します。
基本的には、OSから取得したメモリであり、それを一気に解放することができます。これの利点は、malloc()
の繰り返しの小さな呼び出しが高コストになる可能性があることです(すべてのメモリ割り当てにはパフォーマンスコストがあります:プログラムの論理アドレス空間にメモリを割り当てるのにかかる時間と割り当てるのにかかる時間物理メモリへのアドレス空間)ボールパークを知っているかのように、メモリの大きな塊を取得し、必要に応じて変数に渡すことができます。
「ヒープ」の同義語と考えてください。通常、プロセスにはヒープ/アリーナが1つしかなく、そこからすべてのメモリ割り当てが発生します。
ただし、一連の割り当てをグループ化する状況がある場合があります(たとえば、パフォーマンスのため、断片化を回避するためなど)。その場合は、新しいヒープ/アリーナを割り当てる方が適切です。その後、任意の割り当てに対して、どのヒープから割り当てるかを決定できます。
たとえば、同じサイズの多数のオブジェクトが頻繁に割り当ておよび割り当て解除されるパーティクルシステムがあるとします。メモリの断片化を回避するために、それらのパーティクルにのみ使用されるヒープから各パーティクルを割り当てることができ、他のすべての割り当てはデフォルトのヒープから行われます。
http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html から:
Libc.so.x共有ライブラリにはglibcコンポーネントが含まれており、ヒープコードはその中にあります。現在のヒープの実装では、アリーナと呼ばれる複数の独立したサブヒープを使用します。各アリーナには、同時実行保護のための独自のミューテックスがあります。したがって、プロセスのヒープ内に十分なアリーナがあり、スレッドのヒープアクセスをそれらの間で均等に分散するメカニズムがあれば、ミューテックスの競合の可能性は最小限に抑えられます。これは、割り当てに適していることがわかります。 malloc()では、現在のスレッドの現在のターゲットアリーナのミューテックスがフリー(trylock)かどうかを確認するテストが行われます。その場合、アリーナはロックされ、割り当てが進行します。ミューテックスがビジーの場合、残りの各アリーナが順番に試行され、ミューテックスがビジーでない場合に使用されます。ブロックせずにアリーナをロックできない場合、新しいアリーナが作成されます。定義上、このアリーナはまだロックされていないため、ブロックなしで割り当てを続行できます。最後に、スレッドによって最後に使用されたアリーナのIDはスレッドローカルストレージに保持され、その後、そのスレッドによってmalloc()が次に呼び出されるときに最初に試行するアリーナとして使用されます。したがって、malloc()へのすべての呼び出しはブロックせずに続行します。
次のリンクも参照できます。
http://www.codeproject.com/Articles/44850/Arena-Allocator-DTOR-and-Embedded-Preallocated-Buf