JIT is a feature to get around lack of performance in stack-oriented, archaic, bytecode VM. I'm not going to argue about it's practical performance merit, but it's not really an advantage over a native code compiler found in bunch of other languages (since it is a native code compiler itself).
GC has arguably been the best thing Java brought along into mainstream, but it has been a solved problem for a while. The strategy that Java GC adopts, while a natural fit for Java and a host of other procedural languages, is suboptimal for many others.
Could you perhaps expand a bit on what could be done on GC on non-procedural languages? I am suspecting that you mean that there are some tricks that could be employed by functional programming language runtimes.
Hotspot GC is not the best there is for all uses (as Azul Zing JVM manages to forego stop-the-world collections altogether), but I am not aware that any popular runtimes have GCs that perform even close to JVM (perhaps .NET?)
And for long running processes (where compilation time does not dominate), JIT is of course theoretically superior to AOT compilation.
GC has arguably been the best thing Java brought along into mainstream, but it has been a solved problem for a while. The strategy that Java GC adopts, while a natural fit for Java and a host of other procedural languages, is suboptimal for many others.