Version 32 (modified by whiteknight, 6 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)

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)