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.
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.