Mac OS memory management
|
|
Historically, the Mac OS used a form of memory management that has fallen out of favour in modern systems. Criticism of this approach was one of the key areas addressed by the change to Mac OS X.
The original problem for the designers of the Macintosh was how to make optimum use of the 128K of RAM that the machine was equipped with. Since at that time the machine could only run one application program at a time, and there was no permanent secondary storage, the designers implemented a simple scheme which worked well with those particular constraints. Unfortunately that design choice did not scale well with the development of the machine, creating various difficulties for both programmers and users.
| Contents |
Fragmentation
The chief worry of the original designers appears to have been fragmentation - that is, repeated allocation and deallocation of memory through pointers leads to many small isolated areas of memory which cannot be used because they are too small, even though the total free memory may be sufficient to satisfy a particular request for memory. To solve this, Apple designers used the concept of a relocatable handle, a reference to memory which allowed the actual data referred to be moved without invalidating the handle. Apple's scheme was simple - a handle was simply a pointer into a (non relocatable) table of further pointers, which in turn pointed to the data. If a memory request required compaction of memory, this was done and the table, called the master pointer block, was updated. The machine itself implemented two areas in the machine available for this scheme - the system heap (used for the OS), and the application heap. As long as only one application at a time was run, the system worked well. Since the entire application heap was dissolved when the app quit, fragmentation was minimized.
Unfortunately in addressing the fragmentation problem, all other issues were overlooked. The system heap was not protected from errant applications, and this was frequently the cause of major system problems and crashes. In addition, the handle-based approach also opened up a source of programming errors, where pointers to data within such relocatable blocks could not be guaranteed to remain valid across calls that might cause memory to move. In reality this was almost every system API that existed. Thus the onus was on the programmer not to create such pointers, or at least manage them very carefully. Since many programmers were not generally familiar with this approach, early Mac programs suffered frequently from faults arising from this - faults that very often went undetected until long after shipment.
Palm OS uses a similar scheme for memory management. However, the Palm version makes programmer error more difficult. For instance, in Mac OS to convert a handle to a pointer, a program just de-references the handle directly. However, if the handle is not locked, the pointer can become invalid quickly. Calls to lock and unlock handles are not balanced; ten calls to HLock are undone by a single call to HUnlock. In Palm OS, handles are opaque type and must be de-referenced with MemHandleLock. When a Palm application is finished with a handle, it calls MemHandleUnlock. The Palm OS keeps a lock count for blocks; after three calls to MemHandleLock, a block will only become unlocked after three calls to MemHandleUnlock.
MultiFinder
The situation worsened with the advent of MultiFinder, which was a way for the Mac to run multiple applications at once. This was a necessary step forward for users, who found the one-app-at-a-time approach very limiting. However, because Apple was now committed to its memory management model, as well as compatibility with existing applications, it was forced to adopt a scheme where each application was allocated its own heap from the available RAM. The amount of actual RAM allocated to each heap was set by a value coded into each application, set by the programmer. Invariably this value wasn't enough for particular kinds of work, so the value setting had to be exposed to the user to allow them to tweak the heap size to suit their own requirements. This exposure of a technical implementation detail was very much against the grain of the Mac user philosophy, but unfortunately Apple were too stubborn to fix this and so this approach stuck until the advent of OS X. Apart from exposing users to esoteric technicalities, it was inefficient, since an application would grab (unwillingly) all of its alloted RAM, even if it left most of it subsequently unused. Another application might be memory starved, but was unable to utilise the free memory "owned" by another application.
MultiFinder became the Finder in System 7, and by then the scheme was utterly entrenched. Apple made some attempts to work around the obvious limitations - temporary memory was one, where an app could "borrow" free RAM that lay outside of its heap for short periods, but this was unpopular with programmers so it largely failed to solve the problem. There was also an early virtual memory scheme, which attempted to solve the issue by making more memory available by paging unused portions to disk, but for most users, this did nothing but slow everything down without solving the memory problems themselves. By this time all machines had permanent hard disks and MMU chips, and so were equipped to adopt a far better approach. For some reason, Apple never made this a priority until OS X, even though several schemes were suggested by outside developers that would retain compatibility while solving the overall memory management problem. Third party replacements for the Mac OS memory manager, such as Optimem, showed it could be done.
32-bit clean
Originally the Macintosh had just 128K of RAM, growing to 1MB by the time of the Mac Plus. The 68000 CPU is a full 32-bit processor, but early versions made only 24 physical address lines available, since 232 bytes of memory seemed a very unlikely prospect indeed at that time. The 24 lines allow addressing up to 8MB, and that must have seemed more than enough. Since memory space of all types was tight, it was efficient to use the otherwise unused high 8 bits of addresses as storage for flags or other data. The original memory manager, up until the advent of System 7, did just this. Each block of memory had associated with it flags such as locked, purgeable, resource, etc, and these were stored in the high 8 bits of each address in the master pointer table. When used as an actual address, these bits were masked off. Additionally, the Classic Macintoshes also used the high-order bits of the 24-bit address bus to reference peripheral devices, further limiting the amount of memory expansion available.
While a good use of very limited space, this design led to future problems. In theory the architects of the system were free to change this without affecting the APIs at all, but in practice many programmers accessed the flags directly rather than use the APIs provided to manipulate them. By doing this they rendered their applications incompatible with true 32-bit addressing, and this became known as not being "32-bit clean". However it wasn't all the application programmers' fault - a number of published APIs and documented techniques were also not 32-bit clean - anywhere that the upper 8 bits of an address got used for other purposes. A lack of 32-bit cleanliness in applications became an issue for backward compatibility, and another minor headache for developers.
System 7 was the first version of the OS able to address more than 8MB, and featured a 32-bit clean memory manager and replacement techniques for all those areas that previously used the high address bits. However it was quite a while before applications were updated to remove the 24-bit dependencies, and the system provided a way to switch back to 24-bit mode if application incompatibilities were found. By the time of migration to the PowerPC and System 7.1.2, 32-bit cleanliness was mandatory for creating native applications.
Object orientation
The rise of object-oriented languages for programming the Mac — first Object Pascal, then later C++ — also caused problems for the memory model adopted. At first, it would seem natural that objects would be implemented via handles, to gain the advantage of being relocatable. Unfortunately, these languages as they were used pointers for objects, which would lead to fragmentation issues. A solution, implemented by the THINK (later Symantec) compilers, was to use Handles internally for objects, but use a pointer syntax to access them. This seemed a good idea at first, but soon deep problems emerged, since programmers could not tell whether they were dealing with a relocatable or fixed block, and so had no way to know whether to take on the task of locking objects or not. Needless to say this led to huge numbers of bugs and problems with these early object implementations. Later compilers did not attempt to do this, but used real pointers, often implementing their own memory allocation schemes to workaround the Mac OS memory model.
While the Mac OS memory model, with all its inherent problems, remained this way right through to Mac OS 9, due to severe application compatibility constraints, the increasing availability of cheap RAM meant that by and large most users could upgrade their way out of a corner. The memory wasn't used efficiently, but it was abundant enough that the issue never became critical. This is perhaps ironic given that the purpose of the original design was to maximise the use of very limited amounts of memory. Mac OS X finally does away with the whole scheme, implementing a modern sparse virtual memory scheme. A subset of the older memory model APIs still exist for compatibility as part of Carbon, but map to the modern memory manager (a threadsafe malloc implementation) underneath. Apple recommends that new code use malloc and free.ms:pengurusan ingatan OS Mac