![]() 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. That design choice did not scale well with the development of the machine, creating various difficulties for both programmers and users. Since at that time the machine could only run one application program at a time, and there was no fixed secondary storage, the engineers implemented a simple scheme which worked well with those particular constraints. ![]() The original problem for the engineers of the Macintosh was how to make optimum use of the 128 KB of RAM with which the machine was equipped, on Motorola 68000-based computer hardware that does not support virtual memory. Criticism of this approach was one of the key areas addressed by the change to Mac OS X. Historically, the classic Mac OS used a form of memory management that has fallen out of favor in modern systems. "About This Computer" Mac OS 9.1 window showing the memory consumption of each open application and the system software itself ( September 2020) ( Learn how and when to remove this template message) Please help improve it to make it understandable to non-experts, without removing the technical details. This article may be too technical for most readers to understand.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |