🚀 go-pugleaf

In article <MWM.90Oct5145603@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes:
> 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.

This is more or less true, modulo FACC, RAD:, and other long-running potential
memory hogs. Also consider that there aren't that many Amiga programs that
support virtual memory at all.

> The
> Amiga generally doesn't have limits except those imposed by hardware,
> and I feel no urge to start a trend towards doing so.

1> stack 4000

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

Not an arbitrary limit... a user-settable limit. Which is a feature.

> Fine, you've paged out all the blocks. Who now owns the the blocks?

The system.

> 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.

Elementary optimisation: don't free the blocks until you've finished the
current operation.

> Not a good idea. So
> you change this loop to free each block. Now who owns the blocks? The
> library routine free.

For allocating fixed size blocks like this, I'd call AllocMem and FreeMem
myself.

> So you have to implement your own memory allocation
> strategy, that supports giving freed memory back to the system.

Why? It's already there.

> This
> is going to add confusion to the editor, and is a worse than useless
> for systems that have real VM.

#ifdef Amiga
freeblock(b) { FreeMem(b, BLOCKSIZE); }
#else
freeblock(b) { free(b); }
#endif

Simply shocking!
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.