Editing Garbage collection (computer science) (section)

=== Disadvantages ===
GC uses computing resources to decide which memory to free. Therefore, the penalty for the convenience of not annotating object lifetime manually in the source code is [[overhead (computing)|overhead]], which can impair program performance.<ref name="Zorn_1993"/> A peer-reviewed paper from 2005 concluded that GC needs five times the memory to compensate for this overhead and to perform as fast as the same program using idealized explicit memory management. The comparison however is made to a program generated by inserting deallocation calls using an [[oracle machine|oracle]], implemented by collecting traces from programs run under a [[Profiling (computer programming)|profiler]], and the program is only correct for one particular execution of the program.<ref name="Hertz-Berger_2005"/> Interaction with [[memory hierarchy]] effects can make this overhead intolerable in circumstances that are hard to predict or to detect in routine testing. The impact on performance was given by Apple as a reason for not adopting garbage collection in [[iOS]], despite it being the most desired feature.<ref name="wwdc_2011"/>

The moment when the garbage is actually collected can be unpredictable, resulting in stalls (pauses to shift/free memory) scattered throughout a [[Session (computer science)|session]]. Unpredictable stalls can be unacceptable in [[real-time computing|real-time environment]]s, in [[transaction processing]], or in interactive programs. Incremental, concurrent, and real-time garbage collectors address these problems, with varying trade-offs.