Open
Description
The current incremental garbage collector/memory allocator is great and all but leaves a lot to be desired. I'm thinking of rewriting a new one.
GC
- Make it work
- Don't scan
the stack/data segments in order to get the root objects- Time to hack the compiler again
- LLVM provides some intrinsic functions for getting GC stack variables, might wanna use that!
- Scale well with big number of nodes
- The newly rewritten GC does 1 cycle per allocation which doesn't scale
- Use something other than linked lists
- The current GC stores nodes in 3 singly-linked lists for each color. This isn't great when we want to realloc or change a node's color individually.
- Might wanna have an allocation bitmap and mark bitmap for each memory pool
- Needs integration with the scheduler so that it can be run when processor is halted
Ideas
- Store marked items in a bitmap, each bitmap associated with a pool, and each bit associated with a slot in that pool
- Also store mark bits within another bitmap instead of a Gc header
- Store grayed objects in something else
a linked-list-based stack? (the current gc does this)- a flat fixed-size stack? (maybe we could limit the amount of gray objects being processed per cycle)
Memory allocator
- Make it work
- Allow page size allocations (>1024 bytes and < 4096 bytes - header)
- Use the allocator for userspace malloc