Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you haven't looked at tcmalloc, you might want to take a look. Basing your implementation off of its concepts might be a good start. Key points:</p> <ul> <li>Determine a set of size classes. (Each allocation will be fulfilled by using an entry from an equal or greater sized allocation.)</li> <li>Use one size-class per page. (All instances in a page are the same size.)</li> <li>Use per-thread freelists to avoid atomic operations on every alloc/dealloc</li> <li>When a per-thread freelist is too large, move some of the instances back to the central freelist. Try to move back allocations from the same page.</li> <li>When a per-thread freelist is empty, take some from the central freelist. Try to take contiguous entries.</li> <li><strong>Important:</strong> You probably know this, but make sure your design will minimize false sharing.</li> </ul> <p>Additional things you can do that tcmalloc can't:</p> <ul> <li><p>Try to enable locality of reference by using finer-grained allocation pools. For example, if a few thousand objects will be accessed together, then it is best if they are close together in memory. (To minimize cache missed and TLB faults.) If you allocate these instances from their own threadcache, then they should have fairly good locality.</p></li> <li><p>If you know in advance which instances will be long-lived and which will not, then allocate them from separate thread caches. If you do not know, then periodically copy the old instances using a threadcache for allocation and update old references to the new instances.</p></li> </ul>
 

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