Add a heap allocator

[SamTebbs33]

This patch adds a heap allocator that in contrast to the fixed buffer allocator, allows freeing of memory. One is created by default to keep track of kernel memory and more heaps could be created to keep track of memory occupied by user programs etc.

The heap uses a buddy allocation system as it provides efficient allocation, freeing and little external fragmentation.

The current implementation doesn't support complex shrinking or re-allocation so I will create an issue for these that can be addressed if they actually end up being used.

Closes #8

[DrDeano]

Needs some more tests, and maybe a runtime tests, but can't wait to start using

[DrDeano]

Almost there :P

[DrDeano]

Probs don't need to add this now, but maybe add a issue, but to make this more efficient, could just free the memory that is to be shrinked and not all the memory then allocate again. Like heap.free(@ptrToInt(&old_mem[new_size]), old_mem.len - new_size) catch unreachable; If this easy to do, then could do this.

[SamTebbs33]

That is a nice idea, but I don't think it would work all the time because of how the buddy system is structured. If the start of the memory that is no longer needed is in the same block as the memory that is still needed all of it will be freed. For example if old_mem starts at address 0, has length 32 and the min block size is 16 then a shrink to length 10 would try to free 11..32, but because of how the structure works this would end up freeing the whole allocation from 0 to 32, which we wouldn't want. If we find a way to do it more efficiently than freeing and re-allocating that would work in all cases I'm up for it :)

[DrDeano]

Ah yes, so could have new_size be aligned up to the nearest block size; std.mem.alignForward(new_size, block_size).

[SamTebbs33]

I think that would still have the same issue

[DrDeano]

Ok, can create an issue maybe to say that there could be some optimisation here.

[SamTebbs33]

Good idea :) There definitely should be something we can do.