Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!uwvax!caip!daemon From: mwm%ucbopal@BERKELEY.EDU Newsgroups: net.micro.amiga Subject: Re: fragmentation of memory Message-ID: <1483@caip.RUTGERS.EDU> Date: Sun, 9-Mar-86 08:15:16 EST Article-I.D.: caip.1483 Posted: Sun Mar 9 08:15:16 1986 Date-Received: Wed, 12-Mar-86 01:44:34 EST Sender: daemon@caip.RUTGERS.EDU Organization: Rutgers Univ., New Brunswick, N.J. Lines: 63 From: Mike (I'll be mellow when I'm dead) Meyer > I am convinced that the Amiga has definate problems with dynamic memory > allocation in the operating system. I can get reproducable Guru Meditations > several ways, althought they all seem to indicate memory allocation. And I'm convinced that the problem is deeper than that. I haven't finished wading through the ROM Kernal docs yet, so some of this speculation may be blatantly wrong, but here goes anyway. First thing: It's obvious from the Tech reference manual and the frags program that AmigaDOS is using the buddy system to do memory allocation. The buddy system is fast, but tends to be space expensive (see Knuth, vol 1, ppg arund 450). Since the Amiga, which (as a development machine) is memory starved, this is a serious problem. The buddy system also has some pathological cases, which you seem to trip over: >It is also possible to have over 400K "free" memory and >not be able to load small (code size) programs which declare large arrays. Second, AmigaDOS doesn't track the resource useage of a process. This means that you can't abort a task and gets all of it's resources back unless it's cooperating with you. So, when you say: >It seems as though the OS throws its hands up in the air and you get a >Task held error whenever the OS can't allocate a chunk of RAM big >enough for its needs. This is flat out unacceptable for a >multi-tasking computer. A well behaved OS without a MMU should put up >a requestor and RETRY to allocate the memory until it succeeds or >until the user clicks the abort button - no need for GURU MEDITATION. If it flat *can't* allocate the memory, then there isn't any choice but a Guru meditation. Since AmigaDOS can't abort the task, it will probably try and run without it. Chances are the program in question will keep running, trying to use the NULL handed back as valid memory (at least, most of the C code for Unix acts that way). You're dead under those conditions, and I'm willing to bet that a majority of the memory problems are caused by such activity. In fact, I wouldn't be suprised if Intuition has that problem. In the Amiga environment (no protection), the first fix is for the OS to track resource useage, so that it can kill processes without their co-operation (then we can also have a "kill" command!!!). The next step is to change the AmigaDOS memory allocator to do a "Need more memory, please close something" requestor, and give the user a couple of tries. If the user ABORTS, then it should kill the process. Under *no* conditions should the process be allowed to run if it can't get the memory it asked for - you can't trust it after that. Just to keep the Unix bigots from harping about it, I'll ask them to go run their favorite Unix system out of some vital resource. Swap is a good one, but inodes in a file system tends to work, too. Try typing ^S (assuming that's your stop character) on the console. sbrk(-1) on a paging system V can be entertaining, but I think they've fixed it on most of them. My favorite, of course, is "while (1); do; cat /etc/termcap > /dev/console; done" on a 3b20. OS/9 is probably better, being a real-time control system (crashes in such systems tend to be nasty, producing scrap metal instead of cars), but it probably has it's holes. This is why K&P wrote "The Elements of Programming Style."