1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
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>
|
