Allocation Policies

[jonnerloller]

Few kinds of allocation policies.

1. Stack Allocator [Mainly only going to be used by the Main Memory Manager] Concept - Basically the same as the C-Stack. Pros - Easy to write Cons - Have to allocate/Deallocate in order.

2. Heap Allocator, Sized FreeList Concept - Allocations in Random Order. When Freeing, store in Lists co-related to size. Use the memory itself as a list. Pros - Having lists based on size increases speed of 2nd-3rd time allocations after memory has been freed, easy access to memory of any size. Cons - Hard to deal with array, since essentially creating an array is defining a new "size", may have a lot of bloat if all you have are items of very different sizes.

3. Block Allocator, [Similar to CS180 Allocator] Concept - 1 list to all blocks. Basically a Heap Allocator only for arrays, but should be able to break up freed memory into smaller blocks. Pros - Not bloating the Heap allocator, less bloaty since memory blocks can be reused by other sized blocks. Cons- Performance because of list iteration.

General Policy: Memory Manager Stack -Singleton Allocations [We allocate singletons in a fixed order] -NonPersistantString Memory -Heap & Block Allocators

General Usage Heap for single objects Block for arrays [regardless... preallocating is always good]

Strong assert [No Resizing supported by the manager. you can resize yourself. i.e allocate a new block, copy, and deallocate]

Question: Should we make the Block Allocator store the list of all memory blocks and do some basic block merging?

[wagk]

I think we should look at stack allocation, since I think we'll statically allocate a lot of things initially and then not really grow the pool

[jonnerloller]

As of now both Stack and heap allocation is in. [need to test]

Like i previously mentioned, the main issue with the stack is that if it's not deallocated in order, gbaboomz.

Alternatively, we can make each class use a stack allocator, but that also means lots of unecessary reserved stacks when it may not be needed. Stack also means to potential manual realloc function.

For Block/Heap a realloc would be done kinda like a vector copy constructor.

Also for vectors, I propose "fake vectors" i.e Just fixed arrays size determined at construction.;

tldr; Stack and Heap allocators are already in, should we have a block allocator for arrays? or just reuse the heap allocator. risk = performance, we can profile and change it when we need to.

[jonnerloller]

Have decided to just throw Block Allocation under a separate function within the heap manager. until proven inefficient, will stick to doing things this way.

Potential issues, Because of the way I do indexing, The size of any generated object has to be known on compile time, i.e you can allocate arrays on the heap, but you have to do so with a known size.

i.e HeapNewArray<Type,Size>(...) HeapAllocateArray<Type,Size>(...) no constructor If we make an assumption that containers like vectors have to be reserved with a specific size, it should be ok.

Alternatively, or rather, I should provide a allocator that works with it.

[wagk]

An allocator would be nice. If necessary just throw a static assert somewhere to explode past the limit

[jonnerloller]

Gonna continue doing the Block Allocation. probably going to do a Buddy List. Fragmentation everywhere wheeeee. Can allocate the Nodes used by the buddy list from the heap. Who manages the memory manager's memory ? Other memory managers =D