nebel@wam.umd.edu (Chris D. Nebel) (02/06/91)
I got to wondering about this one late one night: why does Multifinder have
this business of application partitions? Why couldn't it have been written
so that all applications simply share one big heap zone? This would have
a number of advantages: users don't have to know anything about partition
sizes, you don't have wasted memory because of apps only using small portions
of their partition, having enough contiguous free memory to run a program
becomes much less of a problem, and programmers don't have to worry about
special Multifinder temporary memory.
The only problem I could think of was that the system has to know who created
which blocks, so it can know what to throw away when a program quits
("unexpectedly" or otherwise). It seems to me, though, that this would be
fairly easy to do, and it wouldn't break anything that didn't use fake handles
or rely on the format of block headers, which they shouldn't have been doing
anyway.
Since this scheme is obviously :) so much better and is trivial :) :) to
implement, why wasn't it done? Am I missing something obvious?
Chris Nebel
nebel@wam.umd.edustevec@Apple.COM (Steve Christensen) (02/06/91)
In article <1991Feb5.182501.4325@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes: >I got to wondering about this one late one night: why does Multifinder have >this business of application partitions? Why couldn't it have been written >so that all applications simply share one big heap zone? This would have >a number of advantages: users don't have to know anything about partition >sizes, you don't have wasted memory because of apps only using small portions >of their partition, having enough contiguous free memory to run a program >becomes much less of a problem, and programmers don't have to worry about >special Multifinder temporary memory. > >The only problem I could think of was that the system has to know who created >which blocks, so it can know what to throw away when a program quits >("unexpectedly" or otherwise). It seems to me, though, that this would be >fairly easy to do, and it wouldn't break anything that didn't use fake handles >or rely on the format of block headers, which they shouldn't have been doing >anyway. > >Since this scheme is obviously :) so much better and is trivial :) :) to >implement, why wasn't it done? Am I missing something obvious? The Mac memory model consists of a system heap and an application heap. Apps are written with this model in mind. The MultiFinder model is the same in that from an app's perspective, it still has a system and application heap. Having one big heap actually complicates the situation. Picture several apps running in a common heap competing for memory. How does an app determine if it has enough memory to run when another app could soon gobble up a big chunk of the heap? How does the system manage ownership of heap blocks? While you do occasionally need to tweak the partition size, it's usually set correctly for most applications, and if it's not, a quick change in the Finder will fix it permanently... steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Christensen | Apple Computer, Inc. | Disclaimer: | 20525 Mariani Ave, MS-81CS | the above may be stevec@apple.com | Cupertino, CA 95014 | a lie...or not.
marykuca@sol.UVic.CA (Brent Marykuca) (02/06/91)
In article <1991Feb5.182501.4325@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes: [ Some stuff about a late-night thought concerning putting all applications into one big heap zone ] >The only problem I could think of was that the system has to know who created >which blocks, so it can know what to throw away when a program quits >("unexpectedly" or otherwise). It seems to me, though, that this would be >fairly easy to do, and it wouldn't break anything that didn't use fake handles >or rely on the format of block headers, which they shouldn't have been doing >anyway. > >Since this scheme is obviously :) so much better and is trivial :) :) to >implement, why wasn't it done? Am I missing something obvious? > >Chris Nebel >nebel@wam.umd.edu Wow, Chris, you got me thinking there. Here's a problem: The stack. Where would you put them all (one for each application)? I suppose you could allocate some arbitrary maximum stack space in a nonrelocatable block somewhere, but then you run into the situation where a stack overflow could write into another application's (or the OS's) memory. At least with a multifinder partition you only destroy your own data :) Still, there doesn't seem to be any compelling reason why your scheme is absolutely going to fail. My guess is that the true answer to the question "why wasn't it done" probably boils down to something like "Because that's the way Switcher did it." Cheers, Brent -- Brent Marykuca (marykuca@sol.UVic.CA) Apple Research Partnership Program Computing User Services
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/06/91)
In article <48874@apple.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >While you do occasionally need to tweak the partition size, it's usually set >correctly for most applications, and if it's not, a quick change in the Finder >will fix it permanently... How much memory do you have in your mac, Steve? 8 meg? More? It's easy to "fix applications permanently" when you have a lot of RAM to play with. It is a much bigger problem for all those people with 1M and 2.5M machines. (I see this from both sides, having one Mac at 8M and one at 2M.) If *I* were going to revise the mac's memory management model (and the tooth fairy were doing the programming), I'd want: 1. Protection 2. Dynamic partition sizing (with perhaps min and max limits) 3. Virtual memory In that order, too. Dynamic partition sizing would help all those people with 68000 macs, for whom VM is useless, and who are the most likely to be tight on memory anyway. (4M of memory is $200; that's a sizeable chunk of change compared to a $900 Classic, but is hardly worth noticing on a $10000 fx.) -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
ph@cci632.UUCP (Pete Hoch) (02/06/91)
nebel@wam.umd.edu (Chris D. Nebel) writes: > I got to wondering about this one late one night: why does Multifinder have > this business of application partitions? Why couldn't it have been written > so that all applications simply share one big heap zone? This would have > a number of advantages: users don't have to know anything about partition > sizes, you don't have wasted memory because of apps only using small portions > of their partition, having enough contiguous free memory to run a program > becomes much less of a problem, and programmers don't have to worry about > special Multifinder temporary memory. It seems to me you are asking, 'Why didn't Apple impliment a demand paging system in Multifinder?'. Or at least something like that. As I understand it, the first reason is that applications cannot run in supervisor mode when you do this. Now Apple has been saying for years, "Do not run is suppervisor mode.". But I don't think you actualy break now if you do it. Next you need protected memory to do this. Since this is not planned for system 7.0 I would not expect paging to be implimented soon. The last thing that I can think of is I imagine many programs assume a contiguous memory space. This obviously would not be the case in sharing one application heap. Pete
stevec@Apple.COM (Steve Christensen) (02/07/91)
dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >stevec@Apple.COM (Steve Christensen) writes: >>While you do occasionally need to tweak the partition size, it's usually set >>correctly for most applications, and if it's not, a quick change in the Finder >>will fix it permanently... > >How much memory do you have in your mac, Steve? 8 meg? More? It's easy >to "fix applications permanently" when you have a lot of RAM to play with. >It is a much bigger problem for all those people with 1M and 2.5M machines. >(I see this from both sides, having one Mac at 8M and one at 2M.) <blush> Well, I do have 8 meg in my $10K IIfx (quite nice, BTW), and 2 meg in a lowly 68000 Mac. I wasn't trying to sound insensitive--just explaining things as I understand them. >If *I* were going to revise the mac's memory management model (and the tooth >fairy were doing the programming), I'd want: > >1. Protection >2. Dynamic partition sizing (with perhaps min and max limits) >3. Virtual memory > >In that order, too. > >Dynamic partition sizing would help all those people with 68000 macs, for >whom VM is useless, and who are the most likely to be tight on memory >anyway. (4M of memory is $200; that's a sizeable chunk of change compared >to a $900 Classic, but is hardly worth noticing on a $10000 fx.) Dynamic partition sizing is a nice idea, but what happens to an app when memory it thought it had (perhaps checked once at launch time to see if it could run at all?) suddenly disappears because another app needed it? If the min and max you mentioned are fixed at launch time, don't we already have that (at least the min part) in the Get Info window? steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Christensen | Apple Computer, Inc. | Disclaimer: | 20525 Mariani Ave, MS-81CS | the above may be stevec@apple.com | Cupertino, CA 95014 | a lie...or not.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/08/91)
In article <48914@apple.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: >Dynamic partition sizing is a nice idea, but what happens to an app when >memory it thought it had (perhaps checked once at launch time to see if it >could run at all?) First, I would suggest you set the minimum so the app has enough to run. Second, any app that decides at launch how much memory it has is on thin ice anyway; there are DA's and other unexpected drains on memory. (Besides, *I* don't use any Microsoft applications :-)) >suddenly disappears because another app needed it? I dunno about most people, but I assume ANY call that can allocate memory might fail, and try to be graceful about it. And, compare: Sorry, but there isn't enough memory to do that; perhaps you should quit something else to make room. [OK] with: Sorry, but there isn't enough memory to do that; perhaps you should quit this application, change its multifinder partition size, quit some other application, and launch this application again. When you're done working with "Mondo Document", you might want to quit again, reset the multifinder partition size, and start this application up in a more reasonable size. [OK] >If the >min and max you mentioned are fixed at launch time, don't we already have that >(at least the min part) in the Get Info window? Actually, you have both the min and the max part; they're just the same; "You can use as little as 512K of memory, or as much as 512K of memory, or anything in between." I'm not really arguing that dynamic sizing could be done (I did stipulate that the tooth fairy do the programming, you recall), just that it would be nice. (Though who'd have thought that the HyperDrive or Switcher could have been done?) I was really hoping that the Multifinder temporary memory calls were going to address this issue. Unfortunately, they seem to be so "temporary" as to be practically useless for anything except disk buffers; you really have to go out of your way to allocate and use them. It would be nice (for example) if my GrowZone function could move an ordinary handle into temporary space for a while, and flag it as such, to be moved back later (say, next time through my event loop). Unfortunately, I can't use the standard handle calls on the thing, so every piece of my program has to know whether it's dealing with a real handle or an mf temp handle; yuck. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
keith@Apple.COM (Keith Rollin) (02/09/91)
In article <1991Feb5.182501.4325@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes: >I got to wondering about this one late one night: why does Multifinder have >this business of application partitions? Why couldn't it have been written >so that all applications simply share one big heap zone? This would have There's been a lot of talk on this, but I don't think I've seen this reason against your suggestion yet. There are some programs out there (for instance, FileMaker), that find out how much memory is available, and allocate it all for themselves. They then do their own memory management from it (either with their own routines or by treating it as a sub-zone). If you were to run such a program on a 128Meg Mac, it would take all that memory, and not let anyone else run. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
Invader@cup.portal.com (Michael K Donegan) (02/09/91)
Anyone who thinks this is a great idea should buy an MS-DOS machine and run Windows. Then they can experience their application degrading when another program is running because it is hogging up all the memory. They can enjoy the long swap times in switching between applications. They can thrill when their program that runs fine on one machine completely chokes on another. It is a pain to have to set the partition size, especially if you need more in the middle of something else, but the alternative is just as painful if not more. At least this way apps can be tuned to a known quantity. When the developer tells you that you need 1M to run, it probably means that he tested it that way and that your 1M partition is not going to be significantly different. If I don't have a real paging system with protection, I'll take the Mac multifinder scheme any day. Memory is cheap these days. mkd
mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (02/11/91)
In article <0B010004.qtlrta@outpost.UUCP>, peirce@outpost.UUCP (Michael Peirce) writes: >My memory is rather rusty, but I recall a hack that provided multiple >applications running in a single large heap. It was either slightly >before Switcher or contemporary with it. > >It sort of worked OK. Lots of programs seemed to work for a while, >then eventually did something unfriendly and would then go out to lunch. > >I don't recall what this was called, and it fadded away quickly with >the coming of Switcher. Does anyone remember this and what it was >called? Could this be Andy Herzfeld's Servant ? I especially liked the built-in ResEdit. -- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
ericsc@microsoft.UUCP (Eric SCHLEGEL) (02/12/91)
In article <91041.160007CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >*HOWEVER*, now that we've determined that having one heap shared by all >applications is in fact feasible, the real question is "Why didn't Apple >do it that way when they wrote MultiFinder." I suspect it's because the >application structure makes some pretty heavy demands on things like global >variables, etc. Remember that every application has to have its own A5 >world! I don't know if this is still the case, but at one time, QuickDraw assumed that it could use the space between the top of the application heap and the stack as scratch space. Obviously this assumption breaks if we start embedding stacks inside a global heap. -eric
nebel@cscwam.umd.edu (Chris D. Nebel) (02/12/91)
In article <91041.160007CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >*HOWEVER*, now that we've determined that having one heap shared by all >applications is in fact feasible, the real question is "Why didn't Apple >do it that way when they wrote MultiFinder." I suspect it's because the >application structure makes some pretty heavy demands on things like global >variables, etc. Remember that every application has to have its own A5 >world! Every application has to have its own A5 world now, under the existing scheme. You have to deal with switching stacks and A5 worlds no matter how you implement multitasking. The problem is where are you going to put them, since in the single-application model, they exist outside the heap. Really, though, there's no reason they couldn't be allocated as non-relocatable blocks in the global heap. Someone pointed out that there is a problem with putting an application's stack inside the global heap, since it might trash some other app if it gets too big. (Under the current scheme, it'll only kill itself.) You can get around this by allocating the stack directly above the CODE 0 and CODE 1 resources of the parent app, since they're always there and locked. So unless the stack gets very big very fast, it will only stomp on its own application. (Yes, I know having a real memory manager would make the problem go away, but lots of people don't have them!) The only good objection I've heard so far is that some apps decide to suck up all of availible memory immediately. Under a global heap system, this is decidedly anti-social behaviour, and as such would eventually go away. In the meantime, though, you could have an option in the Get Info box that said "limit this app to at most -- K of memory." By default, it would be however much memory you had, and unless an app was anti-social, you'd never have to touch it. C. Tate is right; global heap management is obviously possible. My question is -- since everything I've heard so far indicates that global heap MM would have been just as easy (or hard :) to implement as the partition scheme Apple actually came up with, and since global-heap-style has a number of distinct advantages, why did they go with partitions? Chris Nebel nebel@wam.umd.edu
gillies@m.cs.uiuc.edu (Don Gillies) (02/12/91)
There exist systems (Xerox Star) where every new stack frame is allocated from the heap. These systems have blazing fast memory managers, to make procedure calls suitably fast. In the Xerox implementation, all stacks shared a fixed pool of frames (this was necessary to get fast allocation). You could still run out of stack, without using up the entire heap. But then again, stack overflow was a system error, not a memory smash, as it is in current mac applications. Don Gillies | University of Illinois at Urbana-Champaign gillies@cs.uiuc.edu | Digital Computer Lab, 1304 W. Springfield, Urbana IL ---------------------+------------------------------------------------------ "UGH! WAR! ... What is it GOOD FOR? ABSOLUTELY NOTHING!" - the song "WAR" by Edwin Starr, circa 1965 --
gelphman@adobe.COM (David Gelphman) (02/12/91)
In article <0B010004.qtlrta@outpost.UUCP> peirce@outpost.UUCP writes: > >My memory is rather rusty, but I recall a hack that provided multiple >applications running in a single large heap. It was either slightly >before Switcher or contemporary with it. ... >I don't recall what this was called, and it fadded away quickly with >the coming of Switcher. Does anyone remember this and what it was >called? There was a very cool piece of software called MultiMac which allowed you to run multiple applications with background processing. It was definitely before MultiFinder but did allow the screen to be shared (unlike Switcher). Evidently it was hard coded to use the 64K Roms and died when the 128K Rom came out. The version I saw was a great demo but you couldn't use it for real work. I never heard anything about the memory management approach it took. David
fry@zariski.harvard.edu (David Fry) (02/12/91)
In article <11033@adobe.UUCP> gelphman@adobe.UUCP (David Gelphman) writes: > There was a very cool piece of software called MultiMac which >allowed you to run multiple applications with background processing. >It was definitely before MultiFinder but did allow the screen to be >shared (unlike Switcher). Evidently it was hard coded to use the >64K Roms and died when the 128K Rom came out. The version I saw >was a great demo but you couldn't use it for real work. I never heard >anything about the memory management approach it took. If I remember correctly, a European (French?) man's name was attached to this, but the popular rumor was that only Andy Hertzfeld could have written it since it made use of undocumented hooks in the ROMs. Does anyone have any information about that? Was it an inspiration for MultiFinder? David Fry fry@math.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
phils@chaos.cs.brandeis.edu (Phil Shapiro) (02/13/91)
In article <11033@adobe.UUCP> gelphman@adobe.COM (David Gelphman) writes: In article <0B010004.qtlrta@outpost.UUCP> peirce@outpost.UUCP writes: > >My memory is rather rusty, but I recall a hack that provided multiple >applications running in a single large heap. It was either slightly >before Switcher or contemporary with it. ... >I don't recall what this was called, and it fadded away quickly with >the coming of Switcher. Does anyone remember this and what it was >called? There was a very cool piece of software called MultiMac which allowed you to run multiple applications with background processing. It was definitely before MultiFinder but did allow the screen to be shared (unlike Switcher). Evidently it was hard coded to use the 64K Roms and died when the 128K Rom came out. The version I saw was a great demo but you couldn't use it for real work. I never heard anything about the memory management approach it took. Yeah, MultiMac was *way* cool... I saw a copy, and yes, it only worked on 64K ROM macs. It has this neato config screen that had slots for each application, and it had "priority" sliders that let you assign some sort of CPU percentage to each app, on the fly. You would also tell it how much memory to assign to each program. Alas, it was also way buggy. :-(. I don't remember who the author was ... "Jan" somebody, I think... -phil -- Phil Shapiro Technical Support Analyst Language Products Group Symantec Corporation Internet: phils@chaos.cs.brandeis.edu
andyb@tardis.wimsey.bc.ca (Andy Babinszki) (02/13/91)
In article <1991Feb7.161131.15262@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > In article <48914@apple.Apple.COM> stevec@Apple.COM (Steve Christensen) writes: > >Dynamic partition sizing is a nice idea, but what happens to an app when > >memory it thought it had (perhaps checked once at launch time to see if it > >could run at all?) > > First, I would suggest you set the minimum so the app has enough to run. > > ... deletions ... > Point of Interest: Michael Peirce ( author of Public Folder ) has created "AppSizer" a CDEV that allows you to change the Multifinder memory size at launch time, either temporarily or permanently. Andy. ----------------------------------------------------------------------- Andy Babinszki - andyb@tardis.wimsey.bc.ca