Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!wuarchive!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Memory fragging
Message-ID: <1991May28.162254.31102@kuhub.cc.ukans.edu>
Date: 28 May 91 21:22:54 GMT
References: <1991May21.195251.16477@zorch.SF-Bay.ORG> <21795@cbmvax.commodore.com>  <2885@public.BTR.COM>
Organization: University of Kansas Academic Computing Services
Lines: 51

In article <2885@public.BTR.COM>, eeh@public.BTR.COM (Eduardo E. Horvath  eeh@btr.com) writes:
> I read the RKM Intuition manual at least five times trying to puzzle out
> the use for AllocRemember() and FreeRemeber().  I always thought I was
> missing something.  Why would anyone want to allocate a large number
> of memory blocks, and then forget what they allocated?  What is the
> reason for FreeRemeber(FALSE) ?

Well, Alloc/Free remember can be useful for backing out of a long
chain of allocations part-way through if you have an error.  For
instance I had window I built with 30 bazzillion gads and menu items.
During the build I used AllocRemember() and did a FreeRemember() if I
had a problem.  If I suceeded then I called FreeRemeber(FALSE) because
all the allocated memory was hanging off my window as the menu strip,
gads, etc.  So at death time I looped though killing each item.

Yeah, sounds dumb and was, but that was the idea between
FreeRemember(FALSE).  I ended up just FreeRemember(TRUE) after I
killed the window.  I also wrote my own Alloc/Free to track allocations, and
report mismatches in address and size, dangling allocations at program
exit, etc.  To avoid fragging I put the Remember struct in front of
the allocation and allocated one block instead of two.  I also have
manage my own malloc like private pools use (this
greatly helps fragmentation).  Really big things (>1K) I allocate
directly from the system, these aren't common.  Medium things (100-1K)
I allocate from a variable size pool, small things (<100 bytes) get
rounded up to 100 bytes and come out of a seperate pool.  This
seperate pool for really small things tremendously cuts fragging since
it is these things that come and go so fast and can fragment terrbily
(messages, etc).

I'm playing with some Alloc/Free replacements for exec.library that do
similar things as well as "best-fit" allocation instead of "first-fit".

The problem here is it really helps to have a task private tracking pool but
doing this on exec.library is tough (almost nobody OpenLibrary()s
exec.library).

One bit of expirimentation determined that rounding up all allocations
to the nearest power of 2 (ie 1K 2K 4K) with a limit on max
granualarity (32K works well since it will hold the average bitplane
which is one of the largest common come/go allocations) in conjunction
with best-fit allocations seems to almost completely eliminate fragging.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  mgooderum	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~