Memory Manager:
Allocation Logic:
1 Page = 4096b
Each Page has a header = 4 Bytes - Last Page // 4 Byes - Next Page // 2 Bytes - Allocation Counter // 2 Bytes - Free Offset**
Last Page = A Pointer to the Previous Page in a Non-contiguous string of pages (0000 if the first)
Next Page = A Point to the Next Page in a Non-contiguous string of pages (0000 if the last)
Allocation Counter = A Counter that knows how many separate allocations are in the block. This way, when we free ram in this block we decrease the counter and know when a page is empty Counter = 0
Free Offset (< 4096) = Where the remaining run of free memory is in this block.
Free Offset (> 4096) = The number of pages (value - 4096) in a contiguous run.
Each App has 1 Page malloc buffer assigned at run time.
If the app asks for 256b it increments the Allocation Counter and the Free offset and returns the buffer ptr.
Then the app asks for 3000b it increments the allocation counter and the Free offset and returns the buffer ptr.
The app then requests 850 bytes, this amount of ram would exceed the bounds of its page, so a new page would be added to the linked list, and it would increment the new pages values.
The app then asks for 100b, it would find a place for it in the first page.
The app frees, 256b, 3000b, and 100b the manager would know that the starting page is now free, and would de-allocation the whole page, Page 2 would now become page 1 (the head)
Then the App requests 10k, the MM would find 3 consecutive pages and allocate them. The first of the three pages would be given a header, Pointing to the first pages, then 0000 for the next page, the allocation count = 1, and the offset = 4096 + 3.
Lastly the app requests XYZb that couldn't fit in the first pages, but COULD fit in the end of the consecutive run. IT will NOT go at the end of the run, as there would be no way for the MM to trace it. I new page would be allocated, the NEXT Pointer of the Run pages will point to it, and this guy will point back at the start of the run.
I know its not the most optimized MM, and it is a little wasteful on memory, but I am not all that concerned with waste for two reasons. 1.) The MM is taking a proactive stance on page de-allocation, and 2.) My target hw is going to have over 32mb ram.
Sorry if the above doesn't seem to flow all that well, I kinda wrote it as I was thinking it and then went back and revised it a couple of times. Also please be constructive, thanks.
-Rich
Mem Man Theory Logic, Opinions please.
- mathematician
- Member
- Posts: 437
- Joined: Fri Dec 15, 2006 5:26 pm
- Location: Church Stretton Uk
If I were you I would go and have a look at the two memory management tutorials at:
http://www.osdever.net/tutorials.php?cat=6&sort=1
http://www.osdever.net/tutorials.php?cat=6&sort=1