One not very well known fact is that just-in-time compilers have more optimisation-specific info than pure ahead-of-time compilers, i.e. most used code paths, real types used for polymorphic values, etc. That is, until your AOT compiler uses something like a profile-guided optimisation.
In practice though writing to performance in Java takes a very dedicated effort. Real Java programs are horrible with memory, okay (for an AOT languguage) in long-running compute-intensive tasks, and painfully slow at short-living tasks such as CLI utils.
Almost any real program written in C would run circles around most off-the-shelf Java programs.
Turns out, though, all of that doesn't really matter :-)
But nothing beats Vtune for squeezing the lemon of a tight loop of C code beyond any reason :-) Java just doesn't lean itself well to that kind low-level code wrangling. One misstep - and the performance house of cards falls apart.
So if we actually compare similar problems at hand, for a certain kind the difference is negligible, and is well offset by safety, productivity, maintainability. Hell, due to having safer primitives, one might be able to take advantage of better parallelism, that easily makes up for the slower single-core performance.
But boy it's cumbersome in anything other than those long running jit-friendly server-side processes..!
PS for IO-heavy purposes almost any mem-managed language would do. The real code running there is OS figuring out hardware and physical reality.
All languages would be equally fast, given they don't do something stupid like reading and writing individual bytes.
