Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>We overload the global new and delete operators where I work for many reasons:</p> <ul> <li><strong>pooling</strong> all small allocations -- decreases overhead, decreases fragmentation, can increase performance for small-alloc-heavy apps</li> <li><strong>framing</strong> allocations with a known lifetime -- ignore all the frees until the very end of this period, then free all of them together (admittedly we do this more with local operator overloads than global)</li> <li><strong>alignment</strong> adjustment -- to cacheline boundaries, etc</li> <li><strong>alloc fill</strong> -- helping to expose usage of uninitialized variables</li> <li><strong>free fill</strong> -- helping to expose usage of previously deleted memory</li> <li><strong>delayed free</strong> -- increasing the effectiveness of free fill, occasionally increasing performance</li> <li><strong>sentinels</strong> or <strong>fenceposts</strong> -- helping to expose buffer overruns, underruns, and the occasional wild pointer</li> <li><strong>redirecting</strong> allocations -- to account for NUMA, special memory areas, or even to keep separate systems separate in memory (for e.g. embedded scripting languages or DSLs)</li> <li><strong>garbage collection</strong> or cleanup -- again useful for those embedded scripting languages</li> <li><strong>heap verification</strong> -- you can walk through the heap data structure every N allocs/frees to make sure everything looks ok</li> <li><strong>accounting</strong>, including <strong>leak tracking</strong> and <strong>usage snapshots/statistics</strong> (stacks, allocation ages, etc)</li> </ul> <p>The idea of new/delete accounting is really flexible and powerful: you can, for example, record the entire callstack for the active thread whenever an alloc occurs, and aggregate statistics about that. You could ship the stack info over the network if you don't have space to keep it locally for whatever reason. The types of info you can gather here are only limited by your imagination (and performance, of course).</p> <p>We use global overloads because it's convenient to hang lots of common debugging functionality there, as well as make sweeping improvements across the entire app, based on the statistics we gather from those same overloads.</p> <p>We still do use custom allocators for individual types too; in many cases the speedup or capabilities you can get by providing custom allocators for e.g. a single point-of-use of an STL data structure far exceeds the general speedup you can get from the global overloads.</p> <p>Take a look at some of the allocators and debugging systems that are out there for C/C++ and you'll rapidly come up with these and other ideas:</p> <ul> <li><a href="http://valgrind.org/" rel="noreferrer">valgrind</a></li> <li><a href="http://directory.fsf.org/project/ElectricFence/" rel="noreferrer">electricfence</a></li> <li><a href="http://dmalloc.com/" rel="noreferrer">dmalloc</a></li> <li><a href="http://g.oswego.edu/dl/html/malloc.html" rel="noreferrer">dlmalloc</a></li> <li><a href="http://msdn.microsoft.com/en-us/library/ms220948.aspx" rel="noreferrer">Application Verifier</a></li> <li><a href="http://www.parasoft.com/jsp/products/home.jsp?product=Insure" rel="noreferrer">Insure++</a></li> <li><a href="http://en.wikipedia.org/wiki/BoundsChecker" rel="noreferrer">BoundsChecker</a></li> <li>...and many others... (the gamedev industry is a great place to look)</li> </ul> <p>(One old but seminal book is <a href="http://www.microsoft.com/mspress/books/1024.aspx" rel="noreferrer">Writing Solid Code</a>, which discusses many of the reasons you might want to provide custom allocators in C, most of which are still very relevant.)</p> <p>Obviously if you can use any of these fine tools you will want to do so rather than rolling your own.</p> <p>There are situations in which it is faster, easier, less of a business/legal hassle, nothing's available for your platform yet, or just more instructive: dig in and write a global overload.</p>
    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. 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.
 

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