diff options
| -rw-r--r-- | Mac/mwerks/malloc/README | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/Mac/mwerks/malloc/README b/Mac/mwerks/malloc/README new file mode 100644 index 0000000..59c2af1 --- /dev/null +++ b/Mac/mwerks/malloc/README @@ -0,0 +1,80 @@ + + What is this? + ------------- +This package is a memory allocator for the Macintosh. It was initially +implemented for use with the MetroWerks CodeWarrior compiler on the +PowerPC Mac, but may also be useful (in a more limited way) for use +with MW 68K or Think compilers. + +This is distribution 1.0, dated April 19, 1995. + + How does it work? + ----------------- +Actually, 99% of the code comes straight from the old old BSD-unix +"fast malloc", only the interface to the low-level memory allocator +and the handling of large blocks is different. The allocator follows +one of two strategies, based upon block size: +- for small blocks (anything up to 8K, as distributed), the size is + rounded up to the next power of two, and that much is + allocated. Realloc, etc. understand about this. Small blocks are + packed into 8K segments. +- Larger blocks are allocated directly using NewPtr(). + + Why should I want it? + --------------------- +The reason for writing this is that I've had serious problems with MW +malloc, especially in one piece of software, the Python +interpreter. Python is a very-high level interpreted language, and +spends very large amounts of time in malloc. Moreover, it reallocs() +like there's no tomorrow, and allocates and frees tiny and huge blocks +intermixedly. After some time running, this caused two things (using +the original MW malloc): memory useage grew exponentially and so did +runtime. MetroWerks have tried to be helpful, but I have been unable +to provide them with simple sample-programs that showed the problem: +it seems to be something to do with fragmentation and only happens +under very heavy use. + +The 68K MW malloc has the same problems, and the Think C malloc +has a similar one: it shows the same growth problem but not the +increase in runtime. + +Two additional reasons for using it: +- It is blindingly fast. +- It has pretty good range checking and such (enabled with a #define), + so it'll help you catch various programming errors like referencing + outside the bounds of the malloced block. + +One reason for not using it: +- It is rather wasteful of memory. Small blocks, on average, occupy + 25% more memory than they need, and the allocation in 8K chunks + wastes another 50K (on average). Also, memory is never returned from + malloc()s pool to the Memory Manager. + + How do I use it? + ---------------- +For MW PPC: simply add the sources to your project. Due to the way the +linker works all mallocs will use the new malloc, even the malloc +calls that come from the libraries (if I'm informaed correctly). + +For MW 68K: ditto, only supposedly the library malloc calls will still +use the original malloc. The two packages don't bite each other, +however, so there shouldn't be any problems. + +For Think: more work, but you can rebuild the ANSI library with this +malloc, since the Think distribution contains everything you need for +this. + + Is that all? + ------------ + +Yes. Let me finish off by asking that you send bug reports, fixes, +enhancement, etc to me at the address below. + + Jack Jansen + Centrum voor Wiskunde en Informatica + Kruislaan 413 + 1098 SJ Amsterdam + the Netherlands + + <Jack.Jansen@cwi.nl> + |