Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>A standard BSD-style memory allocator basically works like this:</strong></p> <ul> <li>It keeps a linked list of pre-allocated memory blocks for sizes 2^k for k&lt;=12 (for example).</li> <li>In reality, each list for a given k is composed of memory-blocks from different <em>areas</em>, see below.</li> <li>A malloc request for n bytes is serviced by calculating n', the closest 2^k >= n, then looking up the first <em>area</em> in the list for k, and then returning the first free block in the free-list for the given <em>area</em>.</li> <li>When there is no pre-allocated memory block for size 2^k, an <em>area</em> is allocated, an area being some larger piece of continuous memory, say a 4kB piece of memory. This piece of memory is then chopped up into pieces that are 2^k bytes. At the beginning of the continuous memory area there is book-keeping information such as where to find the linked list of free blocks within the area. A bitmap can also be used, but a linked list typically has better cache behavior (you want the next allocated block to return memory that is already in the cache).</li> <li>The reason for using <em>areas</em> is that free(ptr) can be implemented efficiently. ptr &amp; 0xfffff000 in this example points to the beginning of the <em>area</em> which contains the book-keeping structures and makes it possible to link the memory block back into the area.</li> <li>The BSD allocator will waste space by always returning a memory block 2^k in size, but it can reuse the memory of the block to keep the free-list, which is a nice property. Also allocation is blazingly fast.</li> </ul> <p><strong>Modifications to the above general idea include:</strong></p> <ul> <li>Using anonymous mmap for large allocations. This shifts the work over to the kernel for handling large mallocs and avoids wasting a lot of memory in these cases.</li> <li>The GNU version of malloc have special cases for non-power-of-two buckets. There is nothing inherent in the BSD allocator that requires returning 2^k memory blocks, only that there are pre-defined bucket sizes. The GNU allocator has more buckets and thus waste less space.</li> <li>Sharing memory between threads is a tricky subject. Lock-contention during allocation is an important consideration, so in the GNU allocator for example will eagerly create extra <em>areas</em> for different threads for a given bucket size if it ever encounters lock-contention during allocation. </li> </ul>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload