Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!super!udel!gatech!bloom-beacon!apple!bionet!agate!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: free memory defragmentation
Message-ID: <8810112102.AA14661@cory.Berkeley.EDU>
Date: 11 Oct 88 21:02:50 GMT
Article-I.D.: cory.8810112102.AA14661
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 60

Dan Hankins Writes:
:I am considering writing a utility to take the free memory heap and
:defragment it.  This would involve looking at each of the nodes, reading
:them out into a linked list, sorting the linked list, and then
:concatenating all the adjacent blocks and then rebuilding the heap.
:
:This seems like such a simple idea, it amazes me that it has not occurred
:to anyone before.  Has it?  Would I be re-inventing the wheel?  If so,
:where could I find this utility?  I have a need for it.
:
:If no one has written one before, is there some quirk of the opsys that
:would prevent me from doing it?

	You can't re-arrange memory... task X allocates a chunk of memory
and has lots of pointers to it lying around.  You cannot simply move that
chunk somewhere else!

	The fragmentation is due solely to situations where programs 
allocate long-term memory like this:

	A allocates lots of short term memory, say, 64K
	B allocates a little long term memory, say, 8 bytes
	A deallocates its memory

	So now you have 64K freespace, 8 bytes allocate, and the rest free.
Thus, your original memory space is now fragmented.  BUT you cannot move
those 8 bytes somewhere else ... B has to do it by free'ing and re-allocating
it.

:I already envision that the second version would intercept calls to
:the system allocation and de-allocation functions and run in the background,
:only doing the de-fragmentation when a block is returned to the heap or
:when an allocation request fails.

	De-fragmentation is done automatically by FreeMem().  That is,
if you FreeMem() a block of memory which is adjacent to another free block,
those blocks are combined.

:Do too many programs fiddle with the heap themselves for this to be of any
:practical value?

	Well, it really isn't a heap technically.  I agree that fragmentation
is a problem, but not a big problem.   The problem occurs on machines that
have little memory to begin with (512K).  Once you get some extended
memory installed, the problem is essentially removed for the CHIP memory
section and only remains in the extended memory.  If you have enough extended
memory then this goes away too.

	With 2Meg of external memory I still have problems with some programs,
like the 16 bit version of compress.  Actually, that is the only program I
have problems with.

	Though I haven't done this much myself, it is always a good idea
to think about memory fragmentation when you intend to allocate long-term
storage.  For instance, if I write a little clock program that allocates
long term memory I should, every once in a while, reallocate it so the system
can compact the storage.  Other examples come to mind.  To be a solution,
though, the system software would also have to do this sort of thing.

					-Matt