I've experienced problems with java's concurrent mark and sweep collector. It will stop the world, two times, but two much shorter times than a non-concurrent mark and sweep. So it is definitely an improvement in the duration of the stop-the-world.

The problem tends to be that you need to tune it, and even as you have tuned it, you can not promise that under special condition it will fall back to a more primitive collector since the optimality it was tuned for doesn't hold anymore.

I would never argue giving up garbage collection entirely because of these failure scenarios. I would much rather look at moving some critical part of the code out to a language with manual allocation, and let it perform the latency-sensitive bits.

Another mid-ground is to have separate isolate processes (heaps really) that can be stop-the-world collected without blocking each other. Erlang makes great use of this to accomplish "soft realtime", among other things.

Javascript... Yes, even V8.

Side rant: it's part of the reason that my Palm Pre will sometimes just hang for a second at the worst times, such as when I go to answer the phone. :(

A simple mark & sweep or stop & copy GC. Collectors which are incremental (work in small steps, not one full pass at a time) and/or generational (using several smaller generations, which are collected individually) break up GC pauses into something less disruptive.

For a good overview, read "Uniprocessor Garbage Collection Techniques" by Paul Wilson (check google scholar). Richard Jones's _Garbage Collection: Algorithms for Automatic Dynamic Memory Management_ is more in depth.

If you meant actually existing stop the world GC, the server GC in Microsoft's CLR stops all threads on a processor to do GC.