Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.lang.c Subject: Re: memory allocation Message-ID: <824@proxftl.UUCP> Date: 28 Sep 88 03:09:49 GMT References: <1262@micomvax.UUCP> <733@proxftl.UUCP> <33184@cca.CCA.COM> <33422@cca.CCA.COM> <7105@cdis-1.uucp> Reply-To: bill@proxftl.UUCP (T. William Wells) Distribution: comp.lang.c,comp.os.misc Organization: Proximity Technology, Ft. Lauderdale Lines: 27 Summary: Expires: Sender: Followup-To: Keywords: In article <7105@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: : On free() calls, I trace the list until I find the block to be freed. : If it isn't a valid block, it isn't free()d. As the block is being : freed, I coalesce the adjacent free block(s). At most 3 blocks may : be collected (the freed block and the ones immediately above and : below). Do I wish I could afford this kind of strategy! :-) However, what you are describing is *expensive*. One might want to do this kind of thing in a system where catching bugs is of the essence, but any other use is likely to cost an unacceptable amount of machine time, if one does much allocating. : It seems much better to do this work wen the block is freed : (if ever) rather than to perform trash-mashing at malloc() time. Given what you are doing, you should do the coalesce at free time. However, in systems where coalescing involves extra work, it is usually better done at malloc time: this is generally more efficient because some of the work may already be being done at malloc time, and because the coalescing doesn't have to be done until needed (if ever). However, this is a general comment; specific allocators may have different characteristics. --- Bill novavax!proxftl!bill