Received: by 10.180.82.193 with SMTP id k1mr785301wiy.0.1350664666789;
        Fri, 19 Oct 2012 09:37:46 -0700 (PDT)
Path: q11ni134369810wiw.1!nntp.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Pascal J. Bourguignon <p...@informatimago.com>
Newsgroups: comp.programming
Subject: Re: Buddy System Memory Allocator
Date: 19 Oct 2012 16:37:45 GMT
Lines: 27
Message-ID: <1238940171372357278.049239pjb-informatimago.com@news.individual.net>
References: <1731845837372288843.910496pjb-informatimago.com@news.individual.net> <k5ro9b$cg2$1@dont-email.me>
Mime-Version: 1.0
X-Trace: individual.net Ej+/vxrfJkuTZWQYyJ+HYQkhc9mJTR90iVBhUKQgneAxuy5HjFtj+cInPp2G+8fyCE
Cancel-Lock: sha1:4AQJURY6ZyYKKwhop7ZZROAiPMc=
User-Agent: NewsTap/3.5.5 (iPad)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

"BartC" <b...@freeuk.com> wrote:
> "Pascal J. Bourguignon" <p...@informatimago.com> wrote in message
> news:1731845837372288843.910496pjb-informatimago.com@news.individual.net...
>> "Mark" <m...@dibsco.co.uk> wrote:
> 
>>> of memory and want a relatively small minimum block size. A bitmap of 32
>>> bits will only give me coverage for 8k of memory if I use a minimum block
>>> size of 256 bytes. I am trying to figure out how to avoid having a bitmap
>>> that is hundreds or thousands of bits long. I'm sure that there must be a >> better way.
> 
>> The simpliest is to keep the size with the allocated blocks: allocate a
>> word more than requested, to store the size, and return the addess of the
>> first byte after the size.  You may want to still return aligned pointers
>> so you may want to store the size on a smaller alignment.
> 
> He's complaining about having to use a 4 byte bitmap for every 8KB (1 bit per 256 bytes).
> 
> Your way might need 4 bytes for every 256 bytes! And could introduce
> alignment issues (260 bytes per block also sound as a bit awkward).

You cut it too soon.  My proposition has two limbs: use a size prefix for
big blocks, and use blocks of fixed small size allocated from common fixed
size block pools (superblocks).


-- 
__Pascal J. Bourguignon__