Meh. GC isn't terribly interesting. It's just a tool to manage internal heap for a process. The issue with JVM is simple: it's a memory hog and it hates to reboot because JVM thinks of itself (and behaves) as a "computer" instead of a "process": it slowly boots instead of starting, it doesn't fork nicely, it doesn't share any code with its own clone running side-by-side, it allocates more RAM that it needs on startup, basically behaves like a drunk asshole in a bar, hence no Java on the desktop. Dalvik, on the other hand, is "JVM done right".
CLR processes are just processes. They're integrated into a native VM, they are capable of code sharing and they use more compact in-memory representations of built-in types. CLR was designed to run on machines we're running it on, not with a goal of selling more of "big iron". CRL is great for general purpose software development, without cowardly "long-running" or "on dedicated box" prefixes attached.
I agree that the JVM is a bigger memory douche than a vodka-and-Red Bull addict with a new haircut, but I disagree that GC is a "meh" problem. In fact it seems that the CLR is still evolving in this area and can have serious issues with multi-GB heaps -- as does Java unless you incant the right incantations:
Of course, one might say "don't use such big heaps dummy!" But that's a workaround. Due to fragmentation, sub-second GC latency is still a tough problem even for 1-2 GB heaps.
If C# would lead the way in a GC-friendly memory management scheme (maybe regions or something similar) they might win a lot of Java converts.
CLR processes are just processes. They're integrated into a native VM, they are capable of code sharing and they use more compact in-memory representations of built-in types. CLR was designed to run on machines we're running it on, not with a goal of selling more of "big iron". CRL is great for general purpose software development, without cowardly "long-running" or "on dedicated box" prefixes attached.