The atomic nature of garbage collection may sound worrisome with regard to performance, but in fact there are tangible benefits and no significant negative impacts for most applications. Total throughput is improved, since minimal locking is necessary. Concurrent garbage collection would impose a significant locking overhead.
On the down side, atomic garbage collection cannot make strong real-time guarantees. However, the garbage collector is very efficient, and for typical applications, garbage collection delays are measured in microseconds up to tens of milliseconds on current hardware as of the year 2000. For interactive applications, anything under about 100 milliseconds is undetectable by the user, so under normal circumstances the user will not notice that garbage collection is happening.
There are three parameters that can be used to control garbage collection:
There is one situation in which it is possible for garbage to never be collected, despite the garbage collector being properly configured. Suppose that a program creates some objects, the garbage collector runs, then the program enters a code path that clobbers object references, such that the objects could be collected, but no new objects are allocated. In such a situation, neither the allocation inactivity timer (period), nor the object allocation threshold will trigger a collection, and garbage will remain uncollected. In practice this situation is unlikely, and is not a significant problem since the program size is not growing.
Garbage collection is controlled via the gcdict dictionary, which is described in Section 2.11.4.