Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!sunybcs!bingvaxu!leah!uwmcsd1!marque!ddsw1!gryphon!jdow
From: jdow@gryphon.CTS.COM (Joanne Dow)
Newsgroups: comp.sys.amiga
Subject: Re: Memory Fragmentation Question
Message-ID: <1344@gryphon.CTS.COM>
Date: Wed, 26-Aug-87 19:33:32 EDT
Article-I.D.: gryphon.1344
Posted: Wed Aug 26 19:33:32 1987
Date-Received: Sat, 29-Aug-87 06:12:11 EDT
References: <556489503.138.te07.linesville.ibm032@andrew.cmu.edu> <184@sscafit-ab.arpa>
Reply-To: jdow@gryphon.CTS.COM (Joanne Dow)
Organization: Wizardess Designs
Lines: 52
Keywords: memory fragmentation binaries
Summary: Already done as much as possible

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.