jcav@quads.uchicago.edu (john cavallino) (06/22/91)
In article <1991Jun21.235106.14465@mintaka.lcs.mit.edu> rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <5333@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >>In article <82@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >>>> Question: Why do you have to specify a size to the Mac OS? What's >>>>the point?" >>> >>>I believe I understand the difference now. Amiga applications take memory >>>dynamically as they need it. Macintosh applications, having been bred in >>>a single-tasking environment, instead check how much memory is available >>>and use it all. Under Mac Multitasking, you tell the OS how large a >>>contiguous chunk to give the application. Then when the application checks >>>to see how much memory it has, it gets returned a value proportional to how >>>much you specified. Interesting. Am I right? >> >>Sort of. Applications don't assume they hog the whole machine, but >>the memory manager has a hard time with non-contiguous space. This is >>because the mac uses relocatable chunks of memory. I don't see why >>that *must* be so. I can see that using non-contiguous space would be >>inefficient as hell, but I don't see why it would be impossible. If >>all blocks stayed put, that's a different story. > > From the way I interpret this, the Mac has some form garbage collection >to prevent memory defragmentation. I get the suspicous feeling that >the MacOS was developed originally in a language other than C, something >with a run-time memory manager and garbage collector. Am I right? The Mac OS was (and is) written entirely in 68000 machine language, but usually following Pascal calling conventions (many low-level routines use register-based conventions). The Finder used to be written in Pascal, but the entirely-rewritten System 7 version is in C++. The Memory Manager does garbage-collect relocatable blocks, but this has nothing to do with the implementation language. >I see nothing but disadvantages in this type of memory system for >modern computers > 1) Double indirection of pointers is slower > (yes you can lock a memory block, but why use handles in the first place? > I know I would be irritated if I had to constantly do a > ptr1->ptr2->mystuff when coding) It's not quite as bad as that :-). For one thing, no explicit intermediate pointer is necessary. > 2) garbage collection is expensive and it gets worse depending on > the amount of memory you have and the amount being used > > On modern computers an MMU can be used to defrag memory and private >memory pool managing can reduce it greatly. Can someone tell me >why Apple uses this type of memory management? Because no Mac had an MMU until 1987, and the Memory Manager was written in 1983 or earlier. > It still seems strange that you have to 'limit' or tell the OS >the maximum memory your app will need. The only thing that is close >to this on the Amiga is the need to predefine the stack size >(this is because 68000,68010, 68020 w/o MMU cannot have dynamic >stack growth without checking the stack constantly before pushing >anything on it, this slows down code a lot and places burdens on the >compiler) The Mac's application partition nastiness is a legacy of growing the operating system from a single-app-at-a-time to multiple-apps-simultaneously. The software engineers chose a scheme that most closely mimiced the original memory layout, for each application, in order to maximise backward compatibility. At this they succeeded amazingly well, but we are left with this annoying partition scheme. For a different scheme to work, the Memory Manager would have to be _entirely_ re-written, and such a change could not be applied as a boot-time patch, due to the fact that the heap (block-headers, free list, etc) is already initialized before patches are loaded. It would have to be put in a new ROM, and that would be a logistical nightmare. But it would be nice. What would have helped a lot would have been for System 7 VM to have given each application an independent protected virtual address space. Instead, the VM merely extends the existing unified address space to sizes larger than physical RAM. The reason for this is much internal bletcherousness in the Operating System that requires a single address space, such as the existence of a linked list of absolute addresses of all grafPorts in use, that bounces madly from partition to partition. Oh well. Backward compatibility sucks sometimes. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
torrie@cs.stanford.edu (Evan Torrie) (06/22/91)
jcav@quads.uchicago.edu (john cavallino) writes: > The Mac OS was (and is) written entirely in 68000 machine language, but ^^^^^^ I don't know how true this is anymore with System 7. I get the feeling that a lot of the new stuff was rewritten mainly in C. This would be consistent with their goals for a "portable" MacOS. > What would have helped a lot would have been for System 7 VM to have given > each application an independent protected virtual address space. Instead, > the VM merely extends the existing unified address space to sizes larger > than physical RAM. The reason for this is much internal bletcherousness in > the Operating System that requires a single address space, such as the > existence of a linked list of absolute addresses of all grafPorts in use, > that bounces madly from partition to partition. Oh well. > Backward compatibility sucks sometimes. Something I'm sure Apple realises, given their rumoured development of a non-Mac compatible OS (the legendary "Pink" which has been making the news rounds lately). -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Lay me place and bake me pie, I'm starving for me gravy... Leave my shoes and door unlocked, I might just slip away - hey - just for the day."
dant@ryptyde.UUCP (Daniel Tracy) (06/23/91)
Responding to the following: "For a different scheme to work, the Memory Manager would have to be _entirely_ re-written, and such a change could not be applied as a boot-time patch, due to the fact that the heap (block-headers, free list, etc) is already initialized before patches are loaded. It would have to be put in a new ROM, and that would be a logistical nightmare. But it would be nice." Do you mean the heap is initialized before INITs (in the System and out) are loaded, or do you mean before the System file is even opened? I had heard that code within the Data Fork of the System file patches the ROM upon startup, but I guess you're right (?). Couldn't the Heap be reinitialized? I mean, hell, if OS's of 286 machines can switch back to Real Mode by resetting the CPU without resetting the machine, surely we can do something!