There are certainly GCs that don't pause for 50ms at a time -- Go's GC is not very good, and they even admit it.

Felix Klock's PhD is an interesting exploration of this: http://www.ccs.neu.edu/home/pnkfelix/thesis/ although his collector does have some long pauses on particularly evil programs (those programs cause much longer pauses on conventional collectors).

There are research prototypes for such GCs and usually the performance decreases if you want time guarantees. As far as I know there is no GC, which could be used in a AAA FPS game. Convincing would be CryEngine, UnrealEngine, idTech, SourceEngine, etc starting to use a GC in their rendering, physics, sound parts.

John Carmack suggest that someone should write a engine in more functional way (with GC).

So you would reconstruct all the objects given access to the last frame's memory, (which would immutable). Then run the GC between frames. This may cause problems if a slower computer never has time between frames to run GC. (Running at 27fps trying to reach 30fps, my old Laptop would do this most of the time)

The Witcher 2 for the XBox 360 has a GC on their engine, although they did face some issues.

http://www.makinggames.de/index.php/magazin/2155_porting_the...

> There are certainly GCs that don't pause for 50ms at a time -- Go's GC is not very good, and they even admit it.

Of course. I'm just refuting the specific claim of "ballpark C" performance with an immature GC.

So? The fact that there are good garbage collectors doesn't save us from popular languages and runtimes with bad GCs. As long as there are people who expect to be taken seriously when they release a GC'd language with a bad GC, manual memory management should not be treated as an obsolete, obscure, or archaic skill.

You act like most of those phones aren't Java based. Android's GC is actually pretty nice these days.

But all Android phones are still strictly laggier than the iPhone, and part of that is choice of runtime implementation.