The Killer INIT

When an INIT causes a problem, you’ll hear ten people shout in unison, "Have you increased the size of your System Heap?" There are utilities out there that let you manually make the System Heap bigger in an effort to fix crashes due to INITs. However this isn’t much of a solution. In some cases, increasing the size of your System Heap by 20K or so can be beneficial, because it gives the System Heap a little breathing room. If you still experience problems, increasing the System Heap more probably won’t help you. It is kind of like this:

You are in a room with a sadistic murder wielding a nasty looking knife, who definitely doesn’t mean well for you. The bigger the room, the better chance you have to escape from him. Heck, if he is out of shape and the room is big enough, he may never catch you. But one day when you least expect it…

The same goes for the System Heap size method of "curing" crashes. Here are the common causes of problems INITs can run into, and what you can do about them:

PROBLEM #1 — Many INITs are simply badly written. No amount of fudging will help you avoid crashes from a badly written INIT, or two INITs that don’t get along together. True, increasing the size of your System Heap may delay the inevitable. For instance, some INITs don’t even bother to check if they actually have enough memory to do what they want, and increasing your System Heap a little (20K or so) should help this. But if an INIT is badly written, there may be nothing you can do about it. Increasing your System Heap memory to fix a blatant programming error is just a waste of memory.

PROBLEM #2 — Many INITs don’t bother to have ‘sysz’s, thus the INIT31 mechanism has no way of knowing how much memory to give to the INIT. In this case, increasing the size of your System Heap DOES INDEED cure! However the ‘sysz’ method has been documented by Apple for years, and I’d be suspicious of an INIT that doesn’t take advantage of ‘sysz’ anyway.

PROBLEM #3 — To understand this problem, I’ll need to tell you a bit more about heaps. Heaps are called heaps for good reason. Imagine a big laundry basket into which you throw all your clothes. Heaps work in a similar manner. Fortunately for programmers, a maid called Memory Manager takes care of this mess. I call her Martha (just one of those things that keeps you sane when dealing with something that is NEVER wrong).

When you want to put something in a heap, you ask Martha for the space for it, and she gives it to you if she can. Like all good maids, Martha knows that there is less space in a messy heap. So if she can’t give you what you ask for immediately, she takes everything in the heap and cleans it up a bit to free up more room. This is a nice thing, but we all know the problem of coming into your room after someone else cleaned it – you can never find anything! Many INITs have this problem as well, and it is absolutely their fault, not Martha’s. She can tell you where anything is, but some INITs don’t bother to ask, they simply assume they know the location of their little chunk of memory and crash.

There is one other twist to this situation as well. If Martha cleans everything up, and there still isn’t enough room to satisfy a request for memory, she starts throwing things out. But it again isn’t her fault, these things are specifically marked "Throw me out if you need the space." If an INIT doesn’t take this into account, crash.

Since the System Heap is shared by system software and all of your INITs, it is particularly active. However the whole scheme can and should work. Quite well in fact.

In this situation, expanding your System Heap can delay crashes, because if Martha never has to move things or throw things out, badly written software will work most of the time. Realize though that you are sacrificing your precious memory to correct a defect in the software for which you paid good money.

PROBLEM #4 — This is a tricky one that many programmers don’t understand fully. Earlier I described the ‘sysz’ method for telling INIT31 how much memory an INIT needs to loads. It works as advertised, but there is a rub.

The System Heap is shared memory, it is one big basket into which many hens put their eggs. Lets say we have an INIT called "Longcut" that has a ‘sysz’ specifying that it needs 50K of memory. INIT31 will free up 50K of memory, load the hypothetical "Longcut" INIT, and all should be well.

However, let’s say "Longcut" doesn’t use all 50K of the memory it asks for at start up time. Let’s say it uses 10K of memory at start up time to install itself, reserving the rest for later on when it actually works its magic. This is actually a very common situation. Logic would tell you that there should be 40K of memory left over that "Longcut" can count on being there, right? WRONG!

As I said before, the System Heap is shared memory. If an INIT asks for more memory than it actually uses at start up time, whatever it doesn’t use isn’t reserved for it automatically; instead it is thrown "back in the pot," and can be used up by anyone. So later on when "Longcut" thinks it has room to spare, it actually might not and then, crash.

Of course, some programmers know ways to properly program around this situation, but this particular situation is not well known. In this case, increasing System Heap memory can be beneficial as well, but only in a limited sense. Only the programmers know how much memory their INITs really need, and they should be the ones to fix the problem.