The original docs are here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.ht... They raised more questions than answers for me, so I took a stab at rewriting them, and sprinkled in some questions where I need better understanding. Anyone care to fill in my blanks? ----------------- Set the amount of idle time which must pass before an idle GC is performed. Setting -I0 disables the idle GC. The idle GC only affects the threaded and SMP versions of the RTS (see -threaded, Options affecting linking). When the idle GC is enabled, a major GC is automatically performed if the runtime has been idle (i.e., no Haskell computation has been running) for the specified period of time. For an interactive application, it is probably a good idea to use the idle GC, because this will allow finalizers to run and deadlocked threads to be detected in the idle time when no Haskell computation is happening. [Why is this a good thing? What happens when the idle GC is disabled?] Also, it will mean that a GC is less likely to happen when the application is busy, so application responsiveness may be improved. However, if the amount of live data in the heap is particularly large, then the idle GC can cause a significant penalty to responsiveness. [Why? Is it because the idle GC was delayed by waiting for some idle time, and thus has more work to do?]. Conversely, too small of an interval could adversely affect interactive responsiveness [How? And how is this worse than having idle GC disabled? What is the actual behavior when it's disabled, anyway?] The idle period timer only resets after some activity by a Haskell thread. Therefore, once an idle GC is triggered, another one won't be scheduled until more work is performed. This is an experimental feature. Please let us know if it causes problems and/or could benefit from further tuning.