See also Fixing GC Bugs and GCMassacre
- Create an incremental tri-color mark GC module
- Integrate the new incremental GC into the existing system (See #670)
- Stress-test GC with concurrency
- Separate out GC String Core (See #828)
- Add a command-line argument to limit memory allocation (See #67, #827)
- Realtime garbage collector for RTEMS (See #1352)
- Deprecate mem_internal_*alloc functions (See #1402)
- Fix system-dependent code in src/gc/system.c (See #273)
- Implement write barriers. They're needed to maintain the remembered set for generational GC and to update the mark stack for incremental GC. There is a proposal in PDD09 but using macros doesn't work well with pluggable GC cores and using function calls is expensive. Two approaches for efficient write barriers are card marking and sequential store buffers. Card marking is preferred for procedural languages that might make a lot of assignments. (bacek: We don't need write barriers if we use technique from http://research.microsoft.com/en-us/um/people/simonpj/papers/non-stop/index.htm)
Problems to Solve
- Speed. The current gc is slow, and the performance in GC is affecting performance of other systems. Large numbers of objects (e.g. NQP/PGE) are particularly problematic.
- Concurrency. The current gc does not play well with threads. Running GC in a separate thread could help with speed.
- need to be able to free allocated pools (a precise compacting collector)
- need to be able to identify and collect short-lived garbage much more cheaply (we avoid that to some extent by reducing the amount of garbage we create, but would be a significant win for making sub/method calls less expensive. Needs escape analysis and/or generational GC.
- The large number of memory pools that are currently used make it very hard to implement a copying or compacting collector or generational GC. Allocating from a single pool would make it much easier. This would more or less mean a complete rewrite but also a lot of simplification.
- compact_pool is bad for cache thrashing, it copies all pools even if they're complete full or almost full. bacek has a branch for it (compact_pool_revamp, slower than trunk)
- Apply patch to remove _synchronize (See #978)
- Consider deleting src/gc/res_lea.c (doesn't work anyway) (See #655 and #490)
- Kill non-working GC cores (See #655)
- Rearrange the GC interface (See #670)