The reason the default mode for garbage collection isn't changed to handle threads is because, while it would work for programs that are already multithreaded, single-threaded programs see finalization calls within the main thread. Changing this behavior may result in bugs in the program, related to finalizers existing outside of the main thread.

It also causes problems if the program is written to use forking for concurrency. Forking from a single-threaded program is fine, as that is its intended use, but when forking from a multithreaded program, errors can creep into the system.

Due to compatibility issues, garbage collection currently waits for the collection process to end before the main thread is recalled. Thus, while it may make sense to have explicit collection on a separate thread as well as implicit collection, it wouldn't really alleviate any synchronization issues when the thread restarts.

Inherent in the nature of multithreading, using a threaded garbage collector results in a slight delay for implicit collections when compared to serial collection. This delay may affect the system's memory allocation profile for some applications, but is expected to be minimal.

Since the pseudocode shows thread locking in several places, there could be implications for CPU usage. However, it is far more expensive, in terms of processing power, to crawl the chain of object pointers during the garbage collection process itself. Such crawling is almost a brute-force process, and doesn't lend itself easily to CPU speculation, superscalar execution, and other marvels of modern CPU design.