Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: Date: 5 Oct 90 21:56:03 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <6694@sugar.hackercorp.com> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 62 In-Reply-To: peter@sugar.hackercorp.com's message of 3 Oct 90 11:32:13 GMT 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.