🚀 go-pugleaf

In article <73227@sun.uucp> cmcmanis%pepper@Sun.COM (Chuck McManis) writes:
>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 :-). 

     What is SetFunction?

     Would garbage collection techniques help?  For instance, memory could
be divided into two huge chunks.  All allocations would come from chunk A
until chunk A is full.  Then all allocations would come from chunk B, until
chunk B fills up.  Then back to A, and so on.

     Of course this would be a user-selectable option.  Could even allow
more than two chunks.


Dan Hankins