See also Fixing GC Bugs and GCMassacre
- 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)
- 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 RTMS (See #1352)
- Deprecate mem_internal_*alloc functions (See #1402)
- Fix system-dependent code in src/gc/system.c (See #273)
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.
- 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)