An Xtra-Friendly Macintosh C++ Allocator
source code by Francois Pottier and Gregory Jorgensen
Background
The default CodeWarrior C++ allocation and de-allocation routines, used by the C++ new and delete operators are relatively simple, and work pretty well when you're writing software applications. CodeWarrior's strategy is to allocate moderately-sized "pools" of non-relocatable memory (the default pool size is 64K), and return pointers to portions of these memory pools when you call the new operator. When memory is released using the delete operator, that chunk of the memory "pool" can be re-used in a later call to the new operator.
Unfortunately, one of the things that CodeWarrior's delete operator doesn't do is to release entire pools of memory when they become empty. This is not a huge problem within most application software, because the memory is likely to be re-used later on anyway. But if you're writing an Xtra or other type of code module that shares heap space with a host application, it causes something that looks like a big memory leak! Consider the following minimal example, which might be the main entrypoint for a simple string-checking code resource:
pascal int main (const char* str)
{
int returnValue = 0;
char* myStr = new char[strlen(string)];
strcpy(myStr,str);
/* manipulate & evaluate myStr here */
delete myStr;
return returnValue;
}
When the host application calls this routine from a code fragment or CODE resource, a 64K chunk of heap space is allocated, and not released when delete is called. What's worse, if the code module gets purged from memory (which can happen with many types of Xtras), any allocated pools will be permanently lost, since they are stored in static variables that will get trashed if the code module is unloaded.
This is terribly rude behavior for a code module to exhibit, and may eventually cause the host application to run out of memory, or thrash endlessly due to a fragmented heap.
One fallback solution to this problem is to recompile the C++ support libs with NEWMODE defined as NEWMODE_SIMPLE in the file New.cp. Unfortunately, this makes operators new and delete use NewPtr() and DisposePtr() for allocation and de-allocation. While this solves the "leakage" problem, it will also slow your code to a crawl if you do any amount of allocation and de-allocation.
What new_allocator.cp Does
The file new_allocator.cp, written by Francois Pottier and Gregory Jorgensen, redefines the standard C++ operators new and delete to work in a more fexible and efficient manner, and in a way that allows code fragments and CODE resources co-exist with their host applications much more harmoniously. The definitions for new and delete provided in new_allocator.cp have the following advantages over Metrowerks's definitions:
- Memory is taken from the application heap or temporary memory (preferrably the first) for greater flexibility. Taking memory from the temporary heap may prevent Xtras from failing when the host application is low on memory.
- Memory is allocated using locked handles, which won't fragment the area of a host application's heap used for non-relocatable blocks.
- Empty memory pools are released to the system.
- Less heap fragmentation, because the Metrowerks delete operator doesn't always join adjacent free blocks.
- If pool allocation fails, new doesn't revert to calling NewPtr() for each block. Using NewPtr() for allocations will slow your program to a crawl.
Using new_allocator.cp
Using new_allocator.cp and taking advantage of all its benefits is very easy. Simply add the file new_allocator.cp to your CodeWarrior project file, and recompile. That's it!
The file new_allocator.cp is distributed as freeware, and can be used in your projects without charge. All the authors ask is that you notify them if you find bugs or devise improvements to the code.
References
- Stroustrup, B. 1991. The C++ Programming Language, Second Edition. Reading, MA: Addison-Wesley.
