Version 27 (modified by allison, 4 years ago)

--

See also Fixing GC Bugs

Tasks

  • Consider deleting src/gc/res_lea.c (doesn't work anyway) (See #655 and #490)
  • Apply patch to remove _synchronize (See #978)
  • 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)
  • Implement a sweep-free GC (See #1522)
  • 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.
  • 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)
  • 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