Version 34 (modified by bacek, 4 years ago)


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)
  • Write test for #945
  • 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

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

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)