Path: utzoo!attcan!uunet!husc6!mailrus!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: memory allocation
Message-ID: <734@proxftl.UUCP>
Date: 10 Sep 88 14:06:31 GMT
References: <1262@micomvax.UUCP>
Reply-To: bill@proxftl.UUCP (T. William Wells)
Distribution: comp.lang.c,comp.os.misc
Organization: Proximity Technology, Ft. Lauderdale
Lines: 18
Summary:
Expires:
Sender:
Followup-To:
Keywords:

In article <1262@micomvax.UUCP> belanger@micomvax.UUCP (Robert Belanger) writes:
:       1)      we could allocate a long block of memory and manage it
:       ourselves (by maintaining headers to our data blocks) but two problems
:       arises 1) when we free a block then we have to scan the whole area in
:       order to see if we could merge two blocks together. 2) scanning the
:       list (on other system with swap space) induce a lot of disk swapping.

Neither of these needs to be true.  The trick is to do the block
merging while allocating.  In other words, freeing a block is
just marking it as freed; when allocating a block, you look at
the current free block's successor, and if it is free, merge it
then.  The second problem can go away *if* your method of
maintaining the current allocation point is consistent with the
allocation patterns of your program.

---
Bill
novavax!proxftl!bill