🚀 go-pugleaf

In article <6694@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
   > Sorry, the number of buffers is unlimited, and will stay that way.
   > Besides which, a single buffer can grow arbitrarily large. [...] Since
   > the point of paging to disk is to allow editing of files larger than
   > memory, adding other strange constraints seems counterintuitive.

   The Amiga is a multitasking and (to some extent) multiuser system. It is
   desirable that it be possible to limit any program... particularly memory
   hogs... to less than "all available memory". The consequences of running out
   of memory in that background compile you're doing are much worse than those
   of running out of memory in an editor... it just gets slower (and on a hard
   disk, very little slower... it's still I/O bound on the user).

If there were a pre-defined way of giving programs specific memory
limits (ala OS/9), it might be worth thinking about. However, there
isn't. In fact, I've as yet to run across any Amiga program that had
such a facility, even though I've encountered a fair number that will
grow as needed, or even start by grabbing large chunks of memory. The
Amiga generally doesn't have limits except those imposed by hardware,
and I feel no urge to start a trend towards doing so. However, the
sources are available, and you're free to do it yourself.

   Gotta get those priorities straight.

Yup; more features/speed is far more important than adding arbitrary
limits.

   > 	   2) Provide a "flush out all buffers to disk" command in mg to 
   > 		   free up memory just before launching a memory hog
   > 		   application.

   > Not possible, mostly for portability reasons.

   This one went right over my head. What's so non-portable about a flush
   command? All the code has to be in there to manage paging blocks out
   anyway, so

   #ifdef AMIGA
		   case FLUSHCMD:
			   for(each block)
				   page_out(block);
   #endif

Fine, you've paged out all the blocks. Who now owns the the blocks?
Well, the editor does, as page_out is presumably used to free blocks
for reuse. Having it free blocks by default means you wind up freeing
& reallocating a slew of blocks to read a file in. Not a good idea. So
you change this loop to free each block. Now who owns the blocks? The
library routine free. Does it give it back to the system?  Maybe.
However, if it does so, you take a general performance hit in compiled
code (verified by experiment, posted as part of an earlier
discussion). So you have to implement your own memory allocation
strategy, that supports giving freed memory back to the system. This
is going to add confusion to the editor, and is a worse than useless
for systems that have real VM.

	<mike
--
It's been a hard day's night,				Mike Meyer
And I been working like a dog.				mwm@relay.pa.dec.com
It's been a hard day's night,				decwrl!mwm
I should be sleeping like a log.