rnpantos@watdragon.waterloo.edu (Roger Pantos) (01/15/91)
I have a suggestion to the Powers That Be at Apple in charge of
implementing new System stuff:
How about creating a new trap that would allow applications to
allocate handle-based memory from the (dynamically-resizeable)
system heap? This would allow many programs to run with a minimal
"Multifinder partition", yet be able to get memory when they needed it.
It seems to be a real waste to give Qued/M 1024K to play with, if
all I'm editing is a 40K file. Under this scheme, you might only have to
close a few documents to free up enough memory to launch another
program, not kill an entire app.
(I'm aware that you can now ask for a chunk of memory from
Multifinder, but it must be "temporary" - there is no way that this
would replace an application's need to have a large heap space.)
There would not be any radical change from the application
programmer's point of view - handles are handles are handles, no
matter which heap they're in. You might have to check for low-memory
a little more carefully (gasp :-) but apart from that there's little
difference.
(The system would have to keep track of who owns what, so that
if an app died unexpectedly its memory could be freed up.)
It may not be so simple to implement, but I think that life under
Multifinder would improve enough to make it worthwhile.
Comments?
--
---
Roger Pantos rnpantos@watdragon.waterloo.edu 4B AM Hell :-)
My connection to the U of Waterloo is as a paying customer, not a spokesman.
-+- "Mac vs NeXT: just hit 'n'" -+-francis@uchicago.edu (Francis Stracke) (01/15/91)
In article <1991Jan15.010658.26241@watdragon.waterloo.edu> rnpantos@watdragon.waterloo.edu (Roger Pantos) writes: [...] How about creating a new trap that would allow applications to allocate handle-based memory from the (dynamically-resizeable) system heap? This would allow many programs to run with a minimal "Multifinder partition", yet be able to get memory when they needed it. It seems to be a real waste to give Qued/M 1024K to play with, if all I'm editing is a 40K file. Under this scheme, you might only have to close a few documents to free up enough memory to launch another program, not kill an entire app. [...] There is a very good reason for having speified sizes on MF partitions: it keeps programs from grabbing more memory than you want them to. This puts control in the hands of the user. The current setup does make it a little harder on the user, but it's not an unsolvable problem. In the example you gave (how many times have we used that phrase? :-), you could (1) kill some other app, (2) lower its partition size, and (3) relaunch it. It's the user's machine, not the programmer's. Let him allocate RAM as he sees fit. Granted, users (esp. of Macs) are often idiotic little snot-faces, but we don't want them to realize we think that-- they might get offended, & not use our programs. :-) -- ============================================================================== | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes | ==============================================================================
Jens@applelink.apple.com (Jens Peter Alfke) (01/16/91)
In article <1991Jan15.010658.26241@watdragon.waterloo.edu> rnpantos@watdragon.waterloo.edu (Roger Pantos) writes: > How about creating a new trap that would allow applications to > allocate handle-based memory from the (dynamically-resizeable) > system heap? This would allow many programs to run with a minimal > "Multifinder partition", yet be able to get memory when they needed it. The problem with having an app deal with blocks in several different heaps is that many traps that operate on handles (or ptrs) require that the handle's heap be the current zone, so you have to do SetZone() before and after the call or take the chance of bombing. This scheme would also make it even easier for one application to corrupt another app's data. It would also reduce performance since the System heap would have so many blocks in it. No, the real solution is to give every app its own address space, using virtual memory. The app thinks it has gigabytes of space (or however much/little the user wants to restrict it to) but only the memory it allocates actually exists in RAM or on disk. No app can access memory belonging to the system or to any other app. This is the way real operating systems like Unix do it, and it works very well. It definitely will require some modifications to the way Mac applications work, though... --Jens Peter Alfke Apple Computer