te07#@ANDREW.CMU.EDU (Tom Epperly) (08/20/87)
Am I correct in thinking that the Amiga's memory management causes memory to be gradually fragmented into a bunch of little chunks? If this is so, has anyone written a program to coalesce these small chunks into bigger chunks? I would appreciate both any information or programs that deal with this problem. If you are sending a program it is probably better to mail it directly to me rather than posting it on the bboard. Thanks, Tom Epperly **************************************************************** te07@andrew.cmu.edu (ARPANET) te07%tb.cc.cmu.edu@cmuccvma.bitnet (BITNET) te07@tb.cc.cmu.edu (CCNET) te07%tb.cc.cmu.edu@csnet-relay ****************************************************************
sean@ms.uky.edu (Sean Casey) (08/22/87)
In article <556489503.138.te07.linesville.ibm032@andrew.cmu.edu> te07#@ANDREW.CMU.EDU (Tom Epperly) writes: >Am I correct in thinking that the Amiga's memory management causes >memory to be gradually fragmented into a bunch of little chunks? If >this is so, has anyone written a program to coalesce these small chunks >into bigger chunks? Would that be necessary? Disk accesses take longer when a disk is fragmented, but memory accesses wouldn't. I really can't think of any reason why one would need to do this. Sean -- -- Sean Casey sean@ms.uky.edu, {uunet,cbosgd}!ukma!sean -- (the Empire guy) sean@ms.uky.csnet, sean@UKMA.BITNET -- "I...am a shrubber..." -- Roger the Shrubber
umdcs@umn-cs.UUCP (Jeff Wabik) (08/24/87)
In article <7154@g.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: > In article <556489503.138.te07.linesville.ibm032@andrew.cmu.edu> te07#@ANDREW.CMU.EDU (Tom Epperly) writes: > >Am I correct in thinking that the Amiga's memory management causes > >memory to be gradually fragmented into a bunch of little chunks? If > >this is so, has anyone written a program to coalesce these small chunks > >into bigger chunks? > Would that be necessary? Disk accesses take longer when a disk is > fragmented, but memory accesses wouldn't. I really can't think of > any reason why one would need to do this. You can't? How about the ability to allocate a hunk of consecutive memory large enough to run another task? Having 100k of free memory doesn't mean that you can run a 100k task, since there might be 51 other tasks running, each with 2K of "free" between them in physical memory. The Amiga, unfortunately(?) is not a virtual machine. Wasn't this something we learned in "Computer Science 1001"? As long as we're giving wish lists -- does there exist an equivalent to UNIX's "kill" for the Amiga? A light skimming of the RKM's doesn't yeild an easy solution to this problem aching to be answered. -Jeff ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> In no way officially representing myself. "Live Long and Program." -Spock, Star Trek IX, "The search for an efficient algorithm" ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
peter@sugar.UUCP (Peter da Silva) (08/24/87)
The Amiga already coalesces adjacent chunks, and you can't move other chunks around to free up space because on a 68000 without an MMU fixed adresses is all you got. The Mac uses a double indirection system to offset this, at some cost in performance: most programs lock memory anyway and don't use their handles... so you still have the problem. On the other hand, I haven't noticed much of a fragmentation problem in normal usage. I have a tool I call "Fuel Gauge" that shows me how my free chunks are distributed, and while the low 100K or so of RAM is badly fragmented above that there are usually just a couple of small chunks and one or maybe two real big ones. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
treid@sscafit-ab.arpa (Thomas F. Reid) (08/24/87)
[This is my first posting, line-eater, so go ahead...make my day!] In article <556489503.138.te07.linesville.ibm032@andrew.cmu.edu> te07#@ANDREW.CMU.EDU (Tom Epperly) writes: >Am I correct in thinking that the Amiga's memory management causes >memory to be gradually fragmented into a bunch of little chunks? If >this is so, has anyone written a program to coalesce these small chunks >into bigger chunks? I would appreciate both any information or >programs that deal with this problem. If you are sending a program it >is probably better to mail it directly to me rather than posting it on the >bboard. > >Thanks, > >Tom Epperly Such a program would INDEED be useful...from some of the posting on the net, I see that some of my "can't allocate xx bytes" could have been caused by memory fragmentation. That's for micro-EMACS; I suppose similar messages happen for other editors/programs as well. I guess to be really useful, the compiled program would have to be fairly small so it would fit in one of those small fragments, or does executable code not suffer from the fragmentation syndrome? Anywho, I'd like a copy, too, if anybody has a lil' demon like this. The place to post it is (probably) comp.binaries.amiga, no? BTW, is that newsgroup still going? I haven't seen anything new there in a while... Ciao for now, TomR // ARPANET: treid@afit-ab.arpa \X/
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/24/87)
>Such a program would INDEED be useful...from some of the posting on the >net, I see that some of my "can't allocate xx bytes" could have been caused >by memory fragmentation. That's for micro-EMACS; I suppose similar messages Its not really the actual executable that hurts (assuming it has been compiled with scatter loading enabled), but the fact that many such programs sometimes allocate incredibly huge chunks of memory when they don't have to. So, how bout a programmer's note: When designing a program try to design any memory allocation such that, although the total allocated memory may be huge, the individual contiguous chunks are not. -Matt
peter@sugar.UUCP (Peter da Silva) (08/26/87)
> [some ninny says he can't think of any problems with fragmentation] > You can't? How about the ability to allocate a hunk of consecutive memory > large enough to run another task? Having 100k of free memory doesn't mean > that you can run a 100k task, since there might be 51 other tasks running, > each with 2K of "free" between them in physical memory. The Amiga, > unfortunately(?) is not a virtual machine. Scatter loading. Except for Aztec 'C' programs in default mode (why does Aztec keep doing this: you can't write a nice, well-behaved, 'C' program without changing a bunch of defaults. Such an ugly wart on such a nice compiler.) programs on the Amiga can scatter-load. Potentially each seperate module can be loaded at a different location. There is a problem: screen and window memory needs to be contiguous... and then of course there's that RAM: 30K ripcord. but program loading shouldn't be a problem. > Wasn't this something we learned in "Computer Science 1001"? I never took CS 1001. Our introductory CS courses were CS1 and CS40. CS1 was in Fortrash with card decks. > As long as we're giving wish lists -- does there exist an equivalent to > UNIX's "kill" for the Amiga? A light skimming of the RKM's doesn't yeild > an easy solution to this problem aching to be answered. Nope. No resource tracking. Ack, oop. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->
jdow@gryphon.CTS.COM (Joanne Dow) (08/27/87)
In article <184@sscafit-ab.arpa> treid@ssc.UUCP (Thomas F. Reid) writes: >[This is my first posting, line-eater, so go ahead...make my day!] > >In article <556489503.138.te07.linesville.ibm032@andrew.cmu.edu> te07#@ANDREW.CMU.EDU (Tom Epperly) writes: >>Am I correct in thinking that the Amiga's memory management causes >>memory to be gradually fragmented into a bunch of little chunks? If >>this is so, has anyone written a program to coalesce these small chunks >>into bigger chunks? I would appreciate both any information or >>programs that deal with this problem. If you are sending a program it >>is probably better to mail it directly to me rather than posting it on the >>bboard. >> >>Thanks, >> >>Tom Epperly > >Such a program would INDEED be useful...from some of the posting on the >net, I see that some of my "can't allocate xx bytes" could have been caused >by memory fragmentation. That's for micro-EMACS; I suppose similar messages >happen for other editors/programs as well. I guess to be really useful, >the compiled program would have to be fairly small so it would fit in one >of those small fragments, or does executable code not suffer from the >fragmentation syndrome? Well, kemo sabe, memory deallocationsare already coalesced as much as possible. The real problem lies in the basic memory allocation scheme used on the Amiga. When an allocation is granted you get back a pointer to the actual memory address of the allocation. In order to allow garbage collection (as it is often called) the return would have to be a pointer to a pointer to the allocation. Then as the OS determined it could compact memory it could copy a hunk to a new location and redirect the pointer to it. The disadvantage here is that every memory access to an allocated hunk of memory would have to be doubly indirect and loadable modules would have tobe position independant code as they themselves might get moved. Things would run slower. But the memory free list would most of the time consist of a small number of large free spaces, one per memory device or type. ie. two SB2's would give a system with three large free hunks.) Anyway - if a piece of memory is deallocated that is adjacent, on either side, to an already free hunk it is merged with it to form one larger free space. (I have repeatedly verified this with my hack to the old frags utility.) -- <@_@> BIX:jdow INTERNET:jdow@gryphon.CTS.COM UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was better you left it in the bush with the other one.
andy@cbmvax.UUCP (09/01/87)
In article <567@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >There is a problem: screen and window memory needs to be contiguous... and >then of course there's that RAM: 30K ripcord. but program loading shouldn't >be a problem. The ripcord was removed for the release Workbench disk. (33.47) It does make sure it has enough for emergencies before starting. That, combined with the large buffers that copy uses (because no one wanted to special case ram:) sometimes causes problems. >> As long as we're giving wish lists -- does there exist an equivalent to >> UNIX's "kill" for the Amiga? A light skimming of the RKM's doesn't yeild >> an easy solution to this problem aching to be answered. > >Nope. No resource tracking. Ack, oop. There are a couple of libraries floating around that give resource tracking by giving replacing the AllocMem, FreeMem, etc. system routines. They all have impacts on performance. >-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.