Calling C is unfair, though. JVM can do the same and it should be implemented the same way.
If you want to benchmark C code you can just benchmark a C application. You run stuff in a VM like the JVM or CLR because you want things like memory safety. If you allow native code in something like a regex benchmark then all your benchmarks are basically about: How fast can the JVM/CLR call native code. And say absolutely nothing about how fast the VM itself is.
So using native code in these benchmarks is just silly and basically makes the whole thing meaningless.
Same with intrinsics. Have a benchmark that tests how good are the intrinsics, are there any significant overhead etc.
When I look at generic names like "n-body sim" I'm thinking ok, let's see how generic mixed floating-point code compares between the languages.
A JVM is not Hotspot, and Hotspot is not a part of “the” JVM.
Note the `C# .NET Core #4` and `Java #2` programs.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
The specific benchmarks in the OP are not objective and fair. I personally want nothing to do with Java, its glacial progress and Oracle's lawyers. But fair is fair.
Using facts to prove a point (as you have) means that quality facts are needed. The OP is not quality facts.