share/doc/papers/malloc/conclusion.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 Conclusion and experience.
  12 .NH
  13 Conclusion and experience.
  14 .PP
  15 In general the performance differences between gnumalloc and this
  16 malloc are not that big.
  17 The major difference comes when primary storage is seriously
  18 over-committed, in which case gnumalloc
  19 wastes time paging in pages it's not going to use.
  20 In such cases as much as a factor of five in wall-clock time has
  21 been seen in difference.
  22 Apart from that gnumalloc and this implementation are pretty
  23 much head-on performance-wise.
  24 .PP
  25 Several legacy programs in the BSD 4.4 Lite distribution had
  26 code that depended on the memory returned from malloc
  27 being zeroed.  In a couple of cases, free(3) was called more than
  28 once for the same allocation, and a few cases even called free(3)
  29 with pointers to objects in the data section or on the stack.
  30 .PP
  31 A couple of users have reported that using this malloc on other
  32 platforms yielded "pretty impressive results", but no hard benchmarks
  33 have been made.
  34 .ds RH Acknowledgements & references.
  35 .NH
  36 Acknowledgements & references.
  37 .PP
  38 The first implementation of this algorithm was actually a file system,
  39 done in assembler using 5-hole ``Baudot'' paper tape for a drum storage
  40 device attached to a 20 bit germanium transistor computer with 2000 words
  41 of memory, but that was many years ago.
  42 .PP
  43 Peter Wemm <peter@FreeBSD.org> came up with the idea to store the
  44 page-directory in mmap(2)'ed memory instead of in the heap.
  45 This has proven to be a good move.
  46 .PP
  47 Lars Fredriksen <fredriks@mcs.com> found and identified a
  48 fence-post bug in the code.