I suspect that the parent is talking about the JVM's JIT, where it compiles java bytecode into machine instructions after loading the application. This is why the first few requests on a JVM are usually considerably slower than the rest.
Parent is obviously exaggerating with the 5000x, and he could have made his point in a different way, but there's some truth to it.
5000 refers to number of times a method needs to be called before the JIT decides the method is "warm" and needs to be compiled by the expensive to run C2 compiler which produces good quality machine code.
If you're benchmarking java code and the method was not called enough times before you measure, you're measuring code compiled by C1 (or even interpreted).
The performance gap between Java and C is on the order of x2 to x5.
Why not just pass -Xcomp? From the docs[1]: "You can completely disable interpretation of Java methods before compilation by specifying the -Xcomp option."
At the same time, JIT can outperform native code in some specific circumstances, since there are certain optimizations which can be proven safe at runtime which can not be guaranteed to be safe at compile time
this is a thing people say a lot but it is not something that seems to often result in an actual java program or benchmark being faster than program compiled AOT by an equivalently smart compiler (llvm etc)
Actually one of the less known features of the JIT is the ability to deoptimize/recompile based on CHA (class hierarchy analysis) or pushed compilation request via invokeDynamic&friends.
