Path: utzoo!attcan!uunet!super!udel!rochester!cornell!mailrus!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: free memory defragmentation
Message-ID: <73227@sun.uucp>
Date: 17 Oct 88 18:21:45 GMT
References: <9887@cup.portal.com> <3009@amiga.UUCP> <10003@cup.portal.com> <5005@cbmvax.UUCP>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 25

In article <5005@cbmvax.UUCP> (Dave Berezowski) writes:
>	Well you could keep ptrs to all your variables in one structure
>(sort of like a freelist) and periodically call a system routine
>like 'UnFragMemory' which would attempt to un-fragged memory by re-working
>all your variables (ie. all your memory use); copying the data as it
>needed to.
>	Regards, David Berezowski

Yes you could, this is sort of what the Macintosh does and it helps a lot.
Unfortunately it gets a bit weirder to program when AllocMem returns a 
(void **) rather than a (void *) [char * for you K&R folks]. There is a 
simpler way to minimize the damage and that is to build a "small memory"
manager. (I believe it was mentioned here before). Essentially, you 
add a could of "small" allocation routines AllocSmallMem and FreeSmallMem
which use a reserved "chunk" of memory. [You can reserve the memory by
using AllocMem() to get the chunk.] This keeps many of the problems 
associated with fragmenting memory with an 8 byte Alloc in the middle.
Note that it would not be as effective as it would if the system managed
it's own small memory pool (which Bryce has hinted it will). There is
of course SetFunction() for those of you who can't wait :-). 


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.