OSDev.org

I finally started working on the heap! This, of course, brings many confusions:

1) I'm using liballoc as my memory manager. It requires some glue logic to allocate and deallocate "pages" of memory (4K in size). Now, this is probably due to my limited understanding of memory management, but it seems to be allocating 16 pages of memory for an integer. It also seems to not be properly freeing the pointers, seeing as in the screenshot the third integer's address is another 16 pages above the last two. Is this normal?

Screenshot for reference: 2) Where is a good place to start giving liballoc memory? Right now, I've hard-coded the start address of liballoc's heap to 0xC800000, but to be honest I have no idea what's there or how close it is to anything else.

Thanks in advance,
John

Mercury1964 wrote:1) I'm using liballoc as my memory manager. It requires some glue logic to allocate and deallocate "pages" of memory (4K in size). Now, this is probably due to my limited understanding of memory management, but it seems to be allocating 16 pages of memory for an integer. It also seems to not be properly freeing the pointers, seeing as in the screenshot the third integer's address is another 16 pages above the last two. Is this normal?

Its perfectly normal for a malloc implementation to request large chunks of memory at start-up for its own internal tables etc. I don't know how the internals of liballoc work, but many memory allocators will allocate multiple bitmaps for small pieces of memory of varying sizes and then use a linked list for large allocations. All of these will have significant overhead. Note that you don't have to page them in straight away, just mark the area as used in your virtual memory map and actually allocate and map physical pages for them when they're first accessed.

Mercury1964 wrote:2) Where is a good place to start giving liballoc memory? Right now, I've hard-coded the start address of liballoc's heap to 0xC800000, but to be honest I have no idea what's there or how close it is to anything else.

It's entirely up to you how you lay out your virtual address space. Note a few things however:

1) you probably don't want the first page mapped at all, this way you can efficiently catch null pointer dereferences
2) your kernel needs to go somewhere - some people map it in the higher half, some don't. This is essentially your choice.
3) some people use recursive mapping for the page tables which often occupies the last entry in the page directory (or PML4T if in x86_64)
4) your processes need to go somewhere. If you use the stock elf cross-compiler, it will by default link your processes to start at 0x400000 (in 32-bit mode)
5) you will also need space for the stack for each thread in each process
6) you may add in shared library loading later - these will also need to be loaded somewhere in your address space

Beyond that its up to you. I'd advise having some subsystem which is responsible for managing virtual memory regions, which you can then preallocate some for each address space and then ask it for a free bit of a particular size as you allocate more regions (e.g. create more threads/load shared libraries).

Regards,
John.

One thing I found while investigating memory leaks in my OS was that liballoc version "1.0" (it doesn't have an actual version number, but a "1.1" version also exists) has a bug where it never uses "slack" memory from previous allocations, i.e. every allocation requires at least one page. Use version 1.1 (or fix the bug).

The reason it allocates 16 pages is because that's the default value of "l_pageCount", which is a configuration value that sets the number of pages to allocate/deallocate at once. This is a configuration value that you can change if you wish. (Also, the fact that you don't know this indicates that you haven't even looked at liballoc's code. I would recommend that you at least have a general idea of how third-party code that you incorporate into your OS woks, even if you don't understand the details.)