ArenaID

 

The member variable arenaID contains the identity of the Arena object as the name suggests. At a glance, the arenaID need not have any structure in it, and a simple integer seems to meet the needs. However, it is profoundly ineffective to allocate tiny objects and huge objects within the same Arena mainly because the resulting fragmentations which would diverse in sizes through the operations would severely degrade the performance of the internal operations for finding suitable free chunks for allocation.

The solutions for the bottleneck of the mixture of tiny and huge chunks within the same Arena must focus on the grouping of chunks by their sizes, which can be implemented by the array of bins (See Section 2.4.1). Where are the bins in the persistent storage implementation? The Arenas will surely and rightfully suffice.

  

Figure 3.12: Internal Structure of ArenaID

In the Figure 3.12, the internal structure of the type ArenaID is shown. The value m is obtained by the calculation (arenaID >> 24) & 0x3f. The value indicates the range of the size of chunks to be allocated in the Arena. The value also shows the minimum size of the free chunks in the Arena, which means that no free chunks smaller than the size are generated through the allocation operations.

The range is shown by the expression $2^{{\tt m} + 4} \leq {\tt size} < 2^{{\tt m} + 5}$. For example, when m = 4, the range is $256 \leq {\tt size} < 512$. To be more precise, the size is not the size of the object to be mapped, but the size of the chunk which contain the Chunk object and the persistent object. As the smallest chunk size is 16 = 2⁴ bytes, 4 is added to m.

On the other hand, the variable n is assigned by just incrementing the last arenaID of the same range.