I'm about to implement a memory manager, but I have a few questions.
1. First of all, should the amount of memory that can be allocated quantized? So it has to be a power of two, even if I waste some of it? I though about having a list of all free blocks of sizes that are powers of two. Or I guess that a block could be of any size and I still store it in list (so in one list I store all blocks that have a size between 2^x and 2^x+1 and so on).
2. Secondly, should I have both a list of freed blocks (this is only blocks that has been allocated once and then freed), and also a pointer to a memory-chunk (which could be of any size) on the end of the heap where I can make new allocations in case I don't find anything in the free-list? Or should I treat the part of memory that hasn't been touched yet as a free chunk itself (stored in the lst)? So the difference is that in the latter I dont distinguish between the highest part of the memory that has never been used, and a block that has been used before and then freed.
Would be nice to see how people does it, the details...
Basic memory managment questions
-
JohnnyTheDon
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: Basic memory managment questions
1. Sounds sort of like buddy allocation.
2. You probably shouldn't differentiate between memory previously used and memory not used, unless its because you want to test or zero the memory before you use it.
2. You probably shouldn't differentiate between memory previously used and memory not used, unless its because you want to test or zero the memory before you use it.
Re: Basic memory managment questions
Thanks!
I thought something like this,when I want to allocate some memory.
I try to find the best block to use (i.e. the smallest block which is larger or equal to the one I want). If the block is twice as a large as what I need, I split it into two blocks, and repeat everything for one of them. As soon as I split a block, or free some memory, I look at the adjacent blocks and try to merge them (so the memory isnt more fragmented than it has to be).
The only real drawback I could think of is, suppose I have just one block that's X bytes large, and I need to allocate X+1 (so I need to get more pages). With this approach, I would need to ask for enough pages to create a block that's 2X large, even though I probably only would need one extra page (4096 bytes). For instance, Suppose I'm given 1 MB of memory at the beginning. If I need to allocate slightly more than one MB, i would need to get enough pages to have 2 MB, which could be overkill. Am I right?
I thought something like this,when I want to allocate some memory.
I try to find the best block to use (i.e. the smallest block which is larger or equal to the one I want). If the block is twice as a large as what I need, I split it into two blocks, and repeat everything for one of them. As soon as I split a block, or free some memory, I look at the adjacent blocks and try to merge them (so the memory isnt more fragmented than it has to be).
The only real drawback I could think of is, suppose I have just one block that's X bytes large, and I need to allocate X+1 (so I need to get more pages). With this approach, I would need to ask for enough pages to create a block that's 2X large, even though I probably only would need one extra page (4096 bytes). For instance, Suppose I'm given 1 MB of memory at the beginning. If I need to allocate slightly more than one MB, i would need to get enough pages to have 2 MB, which could be overkill. Am I right?