It does, actually. The fact that good GC implementations are rare means that GC in general is necessarily subject to poor GC implementations and all the problems that go with them. That may change over the coming years but the fact that it's taken nearly three decades to get the state-of-the-industry in GCs to an acceptable level shows what a struggle it's been.
It's a bit like the folks who say that dynamic languages can be just as fast as compiled languages. Perhaps eventually, but in the here and now in the typical case that claim misses the mark by orders of magnitude.
Not using the state of the art will give a bad impression, yes.
There are plenty of very fast dynamic language runtimes: LuaJIT, PyPy, Spidermonkey, V8, SBCL, etc. They're all competitive with JVMs and some are consistently faster.
Dalvik avoided the state of the art on purpose, for some reason. It didn't even have a JIT by default until Android 2!
There are quite a few decent GCs out there, Dalvik's merely had almost no work put into it.
I think you misunderstood the point I was trying to make.
Sure, there are good GCs out there, but good GCs are harder than many GC proponents make out.
Take the top 100 most heavily used applications or platforms that rely on garbage collection. What fraction of them actually use decent GC implementations?
Also, you seemingly misread my other point about dynamic language runtimes, I wasn't comparing them to JVMs, I was comparing them to compiled code written in lower level systems languages (like C/C++). V8 may be fast, but it's not as fast as compiled code, yet. There's still a huge gap between theory and practice there.
