mirror of
https://github.com/python/cpython.git
synced 2025-10-30 21:21:22 +00:00
84 lines
3.3 KiB
Text
84 lines
3.3 KiB
Text
|
|
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.1, dated May 28, 1997.
|
|
|
|
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?
|
|
----------------
|
|
You may want to look at the source: most debugging options are off by
|
|
default, and so is returning cache-aligned blocks. Near the top of
|
|
malloc.c you will see a couple of defines you can turn on.
|
|
|
|
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.
|
|
|
|
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>
|
|
|