Path: utzoo!attcan!uunet!coherent!dplatt From: dplatt@coherent.com (Dave Platt) Newsgroups: comp.sys.mac.programmer Subject: Re: System 7.0 Q & A Keywords: Low Memory Globals Message-ID: <25141@coherent.com> Date: 18 May 89 06:18:35 GMT References: <30353@apple.Apple.COM> <4666@okstate.UUCP> <1787@internal.Apple.COM> <7266@hoptoad.uucp> <13472@dartvax.Dartmouth.EDU> <7321@hoptoad.uucp> <30935@apple.Apple.COM> <811@key.COM> Reply-To: dplatt@coherent.com (Dave Platt) Organization: Coherent Thought Inc., Palo Alto CA Lines: 96 In article <811@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: > After watching this line of discussion for a while, I can't keep still > any longer. Could somebody please explain to me WHY all the applications > in a Mac with PMMU have to share their low-memory globals? Why not give > each one a copy? (That's what the 2nd 'M' in PMMU is for, right? 'Mapping'?) True... you can do this, _if_ it's possible for the kernel of the system (the portion running in supervisor state, or whatever the equivalent is) to keep things consistent in the face of N different copies of the low-memory globals. Having multiple, individual-application copies of some of these globals isn't a conceptual problem. In particular, globals that reflect the state of only the application owning them (i.e., globals that are local... if that makes sense) can be cloned safely. CurApName, for example, isn't a problem. However... globals that _truly_ reflect the state of the overall machine may present a different problem. For example, globals such as the pointers to the heads of important system queues should not (must not!) be allowed to diverge between applications... otherwise, the truly system-global information can get badly out of sync between different applications. SOMEbody has to keep these straight, or things will go seriously wrong! If Apple thought far enough ahead,'way back in the 128k toaster days, to place all of the application-specific globals in one set of pages, and all of the truly-globals in another, then this may not be a big problem. I'd be surprised if the current low-memory layout were partitioned anywhere near this cleanly, though. MultiFinder is clearly handling part of this problem already, when it "juggles" certain low-memory globals back and forth during context switches. It would have to do so differently if applications had their globals distinguished by the PMMU. And I'm not sure _how_ it could safely and certainly handle changes in the non-application-specific globals. > As for the system heap now, that's a more difficult problem. A possible > solution would be to split it into a 'clean' and a 'dirty' part; then share > the 'clean' (i.e., readonly) part and copy the 'dirty' part for each > application. Wastes some memory, but it's VIRTUAL memory now! Besides, even if > the entire system heap needs to be copied for each application, I'd be quite > willing to pay that price for protecting my applications from each other > (and from my own stupidity :-). Yes, that's distinctly more of a problem. And it may be worse than you think. Consider what happens if your application loads a resource from the System file (say, a FONT), and the memory manager is forced to compact the system heap in order to free up a large-enough contiguous block. CRUNCH! The compaction may move, purge, or coalesce blocks all over the System heap in one swell foop. All of a sudden, the entire heap is potentially dirty! To make matters a bit worse, you can't simply protect the System heap against modification by application code running in user-state. You must also protect it against modification by code in the OS itself that's performing tasks on behalf of the user! For instance, there's really no difference between the user storing blindly into the middle of the heap, and the user calling FSRead to read several hundred bytes into a buffer that's allocated in the System heap... either of these events can trash the universe. In order to prevent kernel-trashing-the-heap conditions, you must either add code to _every_ OS & toolbox routing that manipulates user-specified memory (checking the specified pointers for safety), or protect the System heap itself against modification _by_the_OS_, and then (when a store-violation occurs) decide whether the specified change to the heap is "valid". Both of these approaches are expensive in time and/or in programming effort, and they're tricky to get right. I suspect that you'd rapidly reach the point at which every application would have a completely separate copy of the System heap. This isn't too terrible a problem if you have virtual memory and a fast enough disk, but it does eliminate one of the major advantages of the MultiFinder approach (only one copy of any particular System resource is in physical memory at any one time). Every seen a small computer go into paging-death? It's not a pretty sight :-{. > That leaves thingies like drivers that must muck around with the system's > data. But those critters can trash any operating system (ask any UNIX victim). Yep. The Mac OS has more of these little critters, though... VBL tasks in the System heap, I/O endaction routines, and so forth. It's going to be interesting (to say the least!) to see how these sorts of features can either be replaced by safe alternatives, or sufficiently isolated from the guts of the system that they don't crash more than one application at a time. -- Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303