mazur%gmr.csnet@CSNET-RELAY.ARPA@caip.RUTGERS.EDU (03/04/86)
From: Chet Mazur <mazur%gmr.csnet@CSNET-RELAY.ARPA> if there any special reason memory seems to get fragmented for no reason. (i.e. a known bug in AmigaDos?) or are programmers "grabbing" memory and never returning it? ( allocating w/o freeing )? OR is it just me and my machine.... (alot of Guru's can be attrib. to problems w/ memory) thanks, Chet Mazur.
mykes@3comvax.UUCP (Mike Schwartz) (03/05/86)
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. I am sure that this is a known bug (to the folks at Amiga) in the OS, but until we get release 1.1.1 (or something) with some of the nastier bugs fixed, we will have to live with what we got. 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. I constantly find myself frustrated because 512K is not enough memory. If the Amiga had more Ram, I believe that most of the Fragmentation problems would go away. It is also possible to have over 400K "free" memory and not be able to load small (code size) programs which declare large arrays. I believe that Intuition and the OS are sound enough to develop for, however, but the multi-tasking abilities of the Amiga OS are crippled without good memory management. Anybody at Commodore-Amiga want to give us an idea when we can expect a new OS release with more bugs fixed?
mwm%ucbopal@BERKELEY.EDU (03/09/86)
From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> > 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." <mike