share/doc/papers/malloc/alternatives.ms

   1 .\"
   2 .\" ----------------------------------------------------------------------------
   3 .\" "THE BEER-WARE LICENSE" (Revision 42):
   4 .\" <phk@FreeBSD.org> wrote this file.  As long as you retain this notice you
   5 .\" can do whatever you want with this stuff. If we meet some day, and you think
   6 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
   7 .\" ----------------------------------------------------------------------------
   8 .\"
   9 .\" $FreeBSD$
  10 .\"
  11 .ds RH Alternative implementations
  12 .NH
  13 Alternative implementations
  14 .PP
  15 These problems were actually the inspiration for the first alternative
  16 malloc implementations.
  17 Since their main aim was debugging, they would often use techniques
  18 like allocating a guard zone before and after the chunk,
  19 and possibly filling these guard zones
  20 with some pattern, so accesses outside the allocated chunk could be detected
  21 with some decent probability.
  22 Another widely used technique is to use tables to keep track of which
  23 chunks are actually in which state and so on.
  24 .PP
  25 This class of debugging has been taken to its practical extreme by
  26 the product "Purify" which does the entire memory-coloring exercise
  27 and not only keeps track of what is in use and what isn't, but also
  28 detects if the first reference is a read (which would return undefined
  29 values) and other such violations.
  30 .PP
  31 Later actual complete implementations of malloc arrived, but many of
  32 these still based their workings on the basic schema mentioned previously,
  33 disregarding that in the meantime virtual memory and paging have
  34 become the standard environment.
  35 .PP
  36 The most widely used "alternative" malloc is undoubtedly ``gnumalloc''
  37 which has received wide acclaim and certainly runs faster than
  38 most stock mallocs.  It does, however, tend to fare badly in
  39 cases where paging is the norm rather than the exception.
  40 .PP
  41 The particular malloc that prompted this work basically didn't bother
  42 reusing storage until the kernel forced it to do so by refusing
  43 further allocations with sbrk(2).
  44 That may make sense if you work alone on your own personal mainframe,
  45 but as a general policy it is less than optimal.