> Given appropriate dynamic optimizations, there's no reason Java code can't compete with or surpass statically-typed and statically-compiled C/++,
Garbage collection.
I'm not sure I understand completely what he's trying to say though I find it hard to believe an article about "languages, VMs and optimization" doesn't once mention GC. You can heavily optimize any language to JIT, vectorize instructions, use SSE, whatever... but then that pesky garbage collector stops the world and takes 100 milliseconds...
The primary cost of GC is in memory, not time. GC doesn't need to stop the world; but to be efficient, it needs to be free to generate a lot of garbage to amortize the cost of tracing the live set. This is why GC is asymptotically faster than malloc/free (though not necessarily other approaches, like arenas). GC is also easier, in principle, to parallelize.
As far as I know almost all GCs eventually have a full on stop the world case. The only expetion I know of is the azul C4 collecter but I think there the only ones.
Garbage collection.
I'm not sure I understand completely what he's trying to say though I find it hard to believe an article about "languages, VMs and optimization" doesn't once mention GC. You can heavily optimize any language to JIT, vectorize instructions, use SSE, whatever... but then that pesky garbage collector stops the world and takes 100 milliseconds...