| Jack Jansen | dffa123 | 1995-08-31 14:18:30 +0000 | [diff] [blame^] | 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.0, dated April 19, 1995. |
| 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 | For MW PPC: simply add the sources to your project. Due to the way the |
| 56 | linker works all mallocs will use the new malloc, even the malloc |
| 57 | calls that come from the libraries (if I'm informaed correctly). |
| 58 | |
| 59 | For MW 68K: ditto, only supposedly the library malloc calls will still |
| 60 | use the original malloc. The two packages don't bite each other, |
| 61 | however, so there shouldn't be any problems. |
| 62 | |
| 63 | For Think: more work, but you can rebuild the ANSI library with this |
| 64 | malloc, since the Think distribution contains everything you need for |
| 65 | this. |
| 66 | |
| 67 | Is that all? |
| 68 | ------------ |
| 69 | |
| 70 | Yes. Let me finish off by asking that you send bug reports, fixes, |
| 71 | enhancement, etc to me at the address below. |
| 72 | |
| 73 | Jack Jansen |
| 74 | Centrum voor Wiskunde en Informatica |
| 75 | Kruislaan 413 |
| 76 | 1098 SJ Amsterdam |
| 77 | the Netherlands |
| 78 | |
| 79 | <Jack.Jansen@cwi.nl> |
| 80 | |