![]() Apart from exposing users to esoteric technicalities, it was inefficient, since an application would be made to grab all of its allotted RAM, even if it left most of it subsequently unused. While popular among "power users", this exposure of a technical implementation detail was against the grain of the Mac user philosophy. ![]() Sometimes 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. ![]() The amount of actual RAM allocated to each heap was set by a value coded into the metadata of each application, set by the programmer. 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. This was a necessary step forward for users, who found the one-app-at-a-time approach very limiting. The situation worsened with the advent of Switcher, which was a way for a Mac with 512KB or more of memory to run multiple applications at once. Memory Leaks and Stale ReferencesĪwareness and discipline are also necessary to avoid memory "leaks" (failure to deallocate within the scope of the allocation) and to avoid references to stale handles after release (which usually resulted in a hard crash-annoying on a single-tasking system, potentially disastrous if other programs are running). Palm OS and Windows keep a lock count for blocks after three calls to MemHandleLock, a block will only become unlocked after three calls to MemHandleUnlock.Īddressing the problem of nested locks and unlocks can be straightforward (although tedious) by employing various methods, but these intrude upon the readability of the associated code block and require awareness and discipline on the part of the coder. When a Palm or Windows application is finished with a handle, it calls MemHandleUnlock or Global/LocalUnlock. In Palm OS and Windows, handles are an opaque type and must be de-referenced with MemHandleLock on Palm OS or Global/LocalLock on Windows. Calls to lock and unlock handles are not balanced ten calls to HLock are undone by a single call to HUnlock. For instance, in Mac OS, to convert a handle to a pointer, a program just de-references the handle directly, but if the handle is not locked, the pointer can become invalid quickly. Palm OS and 16-bit Windows use a similar scheme for memory management, but the Palm and Windows versions make programmer error more difficult. Since many programmers were not generally familiar with this approach, early Mac programs suffered frequently from faults arising from this. ![]() Thus the onus was on the programmer not to create such pointers, or at least manage them very carefully by dereferencing all handles after every such API call. Because of the transparency of system-owned data structures at the time, the APIs could do little to solve this. This was a real problem for almost every system API that existed. 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. The memory management system had weaknesses the system heap was not protected from errant applications, as would have been possible if the system architecture had supported memory protection, and this was frequently the cause of system problems and crashes. Since the entire application heap was dissolved when the application quit, fragmentation was minimized. As long as only one application at a time was run, the system worked well. The machine itself implemented two areas in memory available for this scheme - the system heap (used for the OS), and the application heap. If a memory request required compaction of memory, this was done and the table, called the master pointer block, was updated. 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. To solve this, Apple engineers used the concept of a relocatable handle, a reference to memory which allowed the actual data referred to be moved without invalidating the handle. The primary concern of the original engineers appears to have been fragmentation - that is, the repeated allocation and deallocation of memory through pointers leading 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |