juh@cs.hut.fi (Juha Hyv|nen) (05/30/90)
In article <1990May29.145842.18701@kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: +------------------------ ! In article <JUH.90May29144638@hutcs.hut.fi>, juh@cs.hut.fi (Juha ! Hyv|nen) writes: ! ! > About Finder box: ! > Total Memory: 1024 K Largest block: 64 K ! ^^^^ ! > Appl A 300 K ! > Finder 160 K ! > System 500 K ! ! > Application B requires 200 K. If I quit the Finder can I launch B? ! ! No. You'd end up with two blocks - one 64K and one 160K. These can't be ! recombined to one larger block, since the application blocks (heaps) ! can't move. +........................ Why can't (application) heaps move? Is it the same in all (operating) systems or is it just the way Apple choose to do? Does an application (in other systems) have to have contiguous memory to run or is it just to make things easier? +------------------------ ! If you launch and quit many applications, in no particular order, it's ! fully possible you could end up with three apps running, > 1 MB free, but ! only 300 k as the largest block. This is called heap fragmentation. +........................ So to defragment the heap, I have to quit some applications -- and then launch them again. How do I know which applications? Why doesn't the "About Finder" dialogue show the heap fragmentation? And perhaps a "Combine free memory" button, too. Something like this... ------------------------------------------- System 400 K ::::xxxxxxxxxxxx ------------------------------------------- Finder 160 K :xxxxxx Appl A 100 K :xxx --------- ***** 100 K :::: | Combine | Appl B 200 K ::xxxxxx | free | ***** 64 K ::: | memory | ------------------------------------------- --------- I assume memory defragmentation is difficult to implement -- otherwise it would have been already done in the current system (wouldn't it). If the defragmentation cannot be implemented, at least the above tells me I only have to quit B (and launch it again) to combine the free memory manually. / (.__o .. /_/ __/ Juha Hyvonen ! / ! !/ ) ! juh@cs.hut.fi ------
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (05/31/90)
In article <JUH.90May30163659@hutcs.hut.fi> juh@cs.hut.fi (Juha Hyv|nen) writes: >Why can't (application) heaps move? Is it the same in all (operating) >systems or is it just the way Apple choose to do? Because running applications have absolute pointers to items in the heap (e.g. return addresses for procedure calls), and these cannot be identified out of context and modified after the program is started. This is also true in Unix systems that run on non-memory-managed hardware. If you have an MMU, you can make each application think it starts at some fixed address, and then physically move applications by rewriting the MMU mapping registers (so that the application ALWAYS thinks it runs at that address). The pre-680[23]0 MACs do not have memory management. Even if they did, there is too much of the OS that depends on being able to produce address references to multiple application spaces in a unique manner (the Window Manager for instance, and various things that run out of the System Heap). Marc Kaufman (kaufman@Neon.stanford.edu)
edgar@shape.mps.ohio-state.edu (Gerald Edgar) (05/31/90)
* Why doesn't
* the "About Finder" dialogue show the heap fragmentation?
I second this. I have found the addresses of the existing heaps from
Macsbug's "HZ" command. It would be more helpful if they were labeled.
--
Gerald A. Edgar
Department of Mathematics Bitnet: EDGAR@OHSTPY
The Ohio State University Internet: edgar@mps.ohio-state.edu
Columbus, OH 43210 ...!{att,pyramid}!osu-cis!shape.mps.ohio-state.edu!edgarnick@lfcs.ed.ac.uk (Nick Rothwell) (05/31/90)
In article <JUH.90May30163659@hutcs.hut.fi>, juh@cs (Juha Hyv|nen) writes: >Why can't (application) heaps move? Is it the same in all (operating) >systems or is it just the way Apple choose to do? Because the applications will have pointers to things in the heap, so their addresses mustn't change. The whole point behind handles is that stuff can be moved transparently under the application under certain well-defined circumstances (when the application is required not to hold onto dereferenced handles). Even so, there's a call to create a *pointer* to a heap object, and handles can be locked, so the problem is still there. Moving an entire application around is, I would surmise, much more complicated. I don't know of any systems which can move application data areas in physical memory without using handles or somesuch. Moving code is sometimes achievable since code can usually be made position-independent and relocatable. Virtual memory solves these problems, of course, since then the fragmentation of the application's memory is virtual (sic), and shouldn't cause physical fragmentation; things can be moved in physical memory (or to/from disk) without the virtual addresses changing. This implies that VM makes the whole handles business obselete (yes?) Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Ich weiss jetzt was kein Engel weiss
d88-jwa@nada.kth.se (Jon W{tte) (05/31/90)
In article <JUH.90May30163659@hutcs.hut.fi>, juh@cs.hut.fi (Juha Hyv|nen) writes: > Why can't (application) heaps move? Is it the same in all (operating) > systems or is it just the way Apple choose to do? Think about it - if you have a program running, it has a stack. This stack contains many things, among them pointers to variables (in the heap) and return addresses from JSRs. If you moved the heap, these would point out into unknown space, and crash the application (machine ?) > Does an application (in other systems) have to have contiguous memory > to run or is it just to make things easier? Most OSes require contiguous memory. UNIX, VMS and the likes solve this with additional hardware (i.e. a MMU) and virtual memory. These features will be in System 7, for those who have a MMU or 68030. > So to defragment the heap, I have to quit some applications -- and > then launch them again. How do I know which applications? Why doesn't You don't > the "About Finder" dialogue show the heap fragmentation? And perhaps a > "Combine free memory" button, too. Something like this... It probably would be confusing to naive users... > I assume memory defragmentation is difficult to implement -- otherwise You really can't - unless you quit the applications you move. Select "Set Startup" and "Active Applications", and then select "Restart" is a good way of defragmenting if you've got too deep...\ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
philip@Kermit.Stanford.EDU (Philip Machanick) (06/01/90)
In article <4372@castle.ed.ac.uk>, nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > Virtual memory solves these problems, of course, since then the > fragmentation of the application's memory is virtual (sic), and > shouldn't cause physical fragmentation; things can be moved in > physical memory (or to/from disk) without the virtual addresses > changing. > > This implies that VM makes the whole handles business obsolete (yes?) No it doesn't (sigh). Apple is still using 1 address space for everything (I've been told - I don't have a copy of System 7). This means there will _still_ be fragmentation even with VM, but you'll be able to hide it better by allocating a large virtual address space. Philip Machanick philip@pescadero.stanford.edu
dce@smsc.sony.com (David Elliott) (06/01/90)
In article <4372@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >This implies that VM makes the whole handles business obselete (yes?) Well, I'd say that it implies that VM could make handles obsolete, but it is my understanding that System 7's use of VM can't. In a "virtual machine" type of VM (a la BSD Unix), every process has (or can have) the same starting address and can have basically the same address space. Thus, each process more or less "owns" the entire machine while it is running, and VM is used to make this possible. As a result, something like MacOS handles isn't really needed in general (though this doesn't mean that the concept is totally alien, as people familiar with vi and most Unix compilers can see). My understanding of MacOS VM is that it allows the machine to appear as though it has up to 14MB of total RAM by backing real memory with disk space. A system with 8MB of RAM won't even use VM until more than 8MB of memory is being used (I would like to be proved wrong on this). For applications running under MultiFinder, this won't mean that their SIZE resources will be ignored. You will be able to run more applications, but they will still have to run in the requested area of memory. Sadly, this does you little good if you tend to keep few processes running because of memory protection problems (I hardly ever run out of memory on my 8MB system because of this). I would assume, though I've never heard this said, that the biggest improvement would be in the system heap, which is already dynamically sized. Even if Apple were to modify MacOS so that each process lived within a virtual machine environment, handles are still very useful, as they make it possible to deal with seldom-used resources in a very nice way. Why waste VM on a resource that you won't be using? Without adding some kind of disk buffer cacheing, handles are still the only game in town. In any case, I would suspect that handles will become unused by the OS long before there are system trap calls that don't use them. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "If I had a hat the size of Oklahoma, I'd be a happy person."
gilgalad@dip.eecs.umich.edu (Ralph Seguin) (06/02/90)
In article <1990Jun1.053103.8277@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >In article <4372@castle.ed.ac.uk>, nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > >> Virtual memory solves these problems, of course, since then the >> fragmentation of the application's memory is virtual (sic), and > >No it doesn't (sigh). Apple is still using 1 address space for everything Right. You can still fragment virtual memory. This is also quite a bad thing, since it will increase paging activity quite a bit. I wish that people would use proper memory allocation techniques 8-( See ya, Ralph gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | In order to get infinitely many monkeys to type 565 South Zeeb Rd. | something that actually makes sense, you need to Ann Arbor, MI 48103 | have infinitely many monkey editors as well. (313) 662-1506
kyt@cunixd.cc.columbia.edu (Kok Yong Tan) (06/06/90)
In article <1990Jun1.053103.8277@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >No it doesn't (sigh). Apple is still using 1 address space for everything >(I've been told - I don't have a copy of System 7). This means there will >_still_ be fragmentation even with VM, but you'll be able to hide it better >by allocating a large virtual address space. > Sounds like a case of sweeping the problem deeper under the rug. :-) =============================================================================== Kok-Yong Tan can be contacted via: | "Oscularis fundamentum!" InterNet: kyt@cunixd.cc.columbia.edu | - Annoyed Latin scholar CompuServe: 75046,256 | America Online: Lallang | ===============================================================================