Mac/mwerks/malloc/README

   1
   2                 What is this?
   3                 -------------
   4 This package is a memory allocator for the Macintosh. It was initially
   5 implemented for use with the MetroWerks CodeWarrior compiler on the
   6 PowerPC Mac, but may also be useful (in a more limited way) for use
   7 with MW 68K or Think compilers.
   8
   9 This is distribution 1.1, dated May 28, 1997.
  10
  11                 How does it work?
  12                 -----------------
  13 Actually, 99% of the code comes straight from the old old BSD-unix
  14 "fast malloc", only the interface to the low-level memory allocator
  15 and the handling of large blocks is different. The allocator follows
  16 one of two strategies, based upon block size:
  17 - for small blocks (anything up to 8K, as distributed), the size is
  18   rounded up to the next power of two, and that much is
  19   allocated. Realloc, etc. understand about this. Small blocks are
  20   packed into 8K segments.
  21 - Larger blocks are allocated directly using NewPtr().
  22
  23                 Why should I want it?
  24                 ---------------------
  25 The reason for writing this is that I've had serious problems with MW
  26 malloc, especially in one piece of software, the Python
  27 interpreter. Python is a very-high level interpreted language, and
  28 spends very large amounts of time in malloc. Moreover, it reallocs()
  29 like there's no tomorrow, and allocates and frees tiny and huge blocks
  30 intermixedly. After some time running, this caused two things (using
  31 the original MW malloc): memory useage grew exponentially and so did
  32 runtime. MetroWerks have tried to be helpful, but I have been unable
  33 to provide them with simple sample-programs that showed the problem:
  34 it seems to be something to do with fragmentation and only happens
  35 under very heavy use.
  36
  37 The 68K MW malloc has the same problems, and the Think C malloc
  38 has a similar one: it shows the same growth problem but not the
  39 increase in runtime.
  40
  41 Two additional reasons for using it:
  42 - It is blindingly fast.
  43 - It has pretty good range checking and such (enabled with a #define),
  44   so it'll help you catch various programming errors like referencing
  45   outside the bounds of the malloced block.
  46
  47 One reason for not using it:
  48 - It is rather wasteful of memory. Small blocks, on average, occupy
  49   25% more memory than they need, and the allocation in 8K chunks
  50   wastes another 50K (on average). Also, memory is never returned from
  51   malloc()s pool to the Memory Manager.
  52
  53                 How do I use it?
  54                 ----------------
  55 You may want to look at the source: most debugging options are off by
  56 default, and so is returning cache-aligned blocks. Near the top of
  57 malloc.c you will see a couple of defines you can turn on.
  58
  59 For MW PPC: simply add the sources to your project. Due to the way the
  60 linker works all mallocs will use the new malloc, even the malloc
  61 calls that come from the libraries.
  62
  63 For MW 68K: ditto, only supposedly the library malloc calls will still
  64 use the original malloc. The two packages don't bite each other,
  65 however, so there shouldn't be any problems.
  66
  67 For Think: more work, but you can rebuild the ANSI library with this
  68 malloc, since the Think distribution contains everything you need for
  69 this.
  70
  71                 Is that all?
  72                 ------------
  73
  74 Yes. Let me finish off by asking that you send bug reports, fixes,
  75 enhancement, etc to me at the address below.
  76
  77                                 Jack Jansen
  78                                 Centrum voor Wiskunde en Informatica
  79                                 Kruislaan 413
  80                                 1098 SJ  Amsterdam
  81                                 the Netherlands
  82
  83                                 <Jack.Jansen@cwi.nl>
  84