See also Fixing GC Bugs and GCMassacre

Tasks

• Fix memory leaks (See #1465, #791, #748, #721, #706)

• 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)

• Compacting/copying GC (See #616, CopyingGarbageCollector)

• 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)

• Implement a sweep-free GC (See #1522, GC SweepFree Implementation)

• Realtime garbage collector for RTMS (See #1352)

• Deprecate mem_internal_*alloc functions (See #1402)

• Write test for #945

• 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.

• copying collection

Completed Tasks

• 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)