MOOSE

[Michael David WINIKOFF]

> About part D. of the rev. -72, "Design principles".
> The OS should, in addition to what Dennis mentions, keep track of the
> resources used by any application, so that the system will be able
> to unload the resources that are left after an application crash, and thereby
> save resources and make the system more fool proof.

Yes. It allready does this for memory.
There's little point (IMHO) in doing this for memory but not for other resources

> 
> 
> About part  II, the Kernel - A. General Memory Management
> Dennis mentions something about compiler dependance and memory allocation.
> If some of you have been programming Windows, you are familiar with .def
> files, definition files. Each program source code has got one of these.
> They tells the windows shell what code parts that should be swapped to
> disk first.
> Imagine a dialog with the user. The user goes through this dialog one or
> two times in a month, then there are no need for this code to reside in
> memory at all, until the user requests it. Now, an OS could use several
> algorithms to make sure that this code part will be put onto disk pretty
> fast. Now algorithms are a good thing, but they don't know a thing about
> the world, or the program at all, do they. No, but the programmer(s) knows
> everything about the use of the program that is worth knowing, doesn't he.
> Right. Instead of making smart-dumb algorithms who finds out what code
> parts should be unloaded, the programmer marks the code blocks with
> priority levels. These levels then makes the desicion data for the unloading
> algorithm. After all, the programmer knows best, doesn't he... :->

I don't like this ...
	(1) It's a hack
	(2) The programmer can't anticipate what other's do with his/her
		program -- if I use the program in a different way the 
		performance is likely to be ABYSMAL.
	(3) Why not make life easier for the programmer?

	And I didn;t even mention that programmers DON'T know everything about 
	their code (otherwise debugging would be dead easy :-) or that they
	can't anticipate the size/speed of memory/disks or what other programs
	are going to be using up memory at the same time.
> 
> 
> Have a nice day everyone.
> 
> Arff
> 
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@sofus.dhhalden.no--
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.