One of the great frustrations of being a user is to find that a computer program is complaining about lack of memory when one knows full well that one has allocated at least ten times as much memory to the program as it would ever need to do its job. The reason for such error messages usually has to do with the programmer setting a fixed reasonable limit to a particular data structure and then locking it up into an array whose bound is specified by a constant. While the use of arrays can increase the speed of a program, it also means that the user cannot increase the capacity of the program without obtaining the source code and recompiling it, which is usually a daunting option.
The alternative is to use the heap for all data structures that can grow in proportion to the size of the user's input. This rule has been followed rigorously in FunnelWeb. This means that as memory spaces increase, users will be able to hand their version of FunnelWeb more memory without having to recompile it.
Some problems arose early on the MacintoshMacintosh in the use of the heap. It seems that some of the allocations I was attempting to make were failing for some obscure reason, possibly my fault. Whatever it was, it went away when I replaced direct calls to mallocmalloc with calls to a mini package I wrote (called memory) that allocated large chunks of memory and then doled out small pieces as required by the rest of the program.memorypackage
Having a package to manage all the memory allocation had two other benefits.
First, only one check was required in the entire program to see if memory had run out (in the memory package), and if that failed, the program could be brought to a screaming halt. This organization was far preferable to having each piece of code that needed to allocate memory having to check to see if malloc had failed.
Second, the decision to construct a mini-shell within FunnelWeb to support regression testing meant that FunnelWeb proper could be run many times in any given invocation of FunnelWeb. As a consequence it was necessary to make sure that there was no memory leakagememoryleakage between invocations of FunnelWeb proper. This was accomplished by reworking the memory package to operate a watermark system. The user of the package, when requesting memory, could request temporary or permanent. If permanent, the memory package forgot that it had allocated the memory. If temporary, the memory package places the allocated block on a list. There was then a function in the memory package that could be called to deallocate all the temporary memory. Thus, so long as all requests for memory within FunnelWeb proper were for temporary memory, and that memory was freed at the end of every run, one could be sure that there was no memory leakage.