Heap memory manager

[SamTebbs33]

A heap memory manager will need to be implemented so that dynamic sizes of memory can be allocated and freed. One that I have implemented before uses a list of 'holes', each one having a header stating if it is occupied and what its size is. The allocator then goes through this list of holes and finds one with a size closest to the desired size. If it's too big then it splits the surplus off into a separate hole.

Of course there are many ways this can be done.

[SamTebbs33]

The memory manager should be an allocator so that it can be used with the Zig standard library.

[SamTebbs33]

Instead of writing a new allocator, it would be worth using an existing allocator if a suitable one exists in the std lib.

[SamTebbs33]

I've looked through the std lib's allocators and none are suitable so I will write our own. I'll base it on my implementation at https://github.com/SamTebbs33/jaq/blob/dev/src/kernel/mem/heap.c

[DrDeano]

I was thinking should we break this up into a physical and virtual memory manager and then create a Allocator on top of the virtual memory manager to handle more fine grain allocations. I'm not sure if grub supplies the total memory install in the system, (I know my bootloader does ;) ) So could "interface" the heap so can take any source of memory so the heap doesn't have to worry about the real memory, will just ask for more.

https://github.com/DrDeano/DeanOS/blob/master/src/kernel/kernel/paging.c (Near the bottom, functions prefix vmm_)
https://github.com/DrDeano/DeanOS/blob/master/src/kernel/kernel/pmm.c

[SamTebbs33]

Ah so the physical one will track physical page usage, the virtual one would map those pages to virtual addresses and the heap just allocate smaller blocks within that virtual space? I can see the virtual layer being useful if some areas of memory are taken for DMA and the like.

[DrDeano]

Yes, you nailed it :) So can have the heap manage a page of memory. So with the physical layer, it will hide all the I/O mapped regions, and virtual will look continuous.
So for now I guess if we want a heap now, can just use your idea from your OS but have heap layer abstracted so later swap out for the physical/virtual layering.

[SamTebbs33]

Sounds good, if we keep this ticket for the heap layer, could you make issues for the other two parts (we may not need one for each, up to you :) )?

[SamTebbs33]

So for now I guess if we want a heap now, can just use your idea from your OS but have heap layer abstracted so later swap out for the physical/virtual layering.

Agreed. The current extremely minimal and unfinished heap just takes a start and end address and allocates within that, so it should still work above the virtual layer without any modifications.

[DrDeano]

Could have one ticket, and have sub tickets for physical and virtual memory, else multiple tickets