Those benchmarks are of limited use since the JVM has startup costs which get armortized over time. Full performance is only achieved after JIT warmup. AOT would improve that, but on openjdk that's experimental and few people use other JVMs that support AOT out of the box.
About the memory footprint: The runtime is larger, so there's a baseline cost you have to pay for the JITs. But baseline != linear cost.
If you have a long-running applications that run more than a few seconds and crunch more than a few MB of data those numbers would change.
So unless you're using the JVM for one-shot script execution those benchmarks are not representative. And if you do then there would be certain optimizations that one could apply.
> There must be some end user (positive) impact of memory compaction in Java.
Fewer CPU cycles overhead per unit of work, i.e. better throughput, which does seem to be an issue for gogc[0]. No risk of quasi-leaks in the allocator due to fragmentation. Reduced cache misses[1]
That is true - although typed arrays will solve that in the future - but the benchmarks you cite (e.g. fannkuch-redux) still run into a memory floor created by the larger runtime.
Also, `regex-dna` will probably benefit from compact strings in java 9.
And some of the longer-running benchmarks are in fact faster on java, so I think that supports my point about warmup.
About the memory footprint: The runtime is larger, so there's a baseline cost you have to pay for the JITs. But baseline != linear cost.
If you have a long-running applications that run more than a few seconds and crunch more than a few MB of data those numbers would change.
So unless you're using the JVM for one-shot script execution those benchmarks are not representative. And if you do then there would be certain optimizations that one could apply.
> There must be some end user (positive) impact of memory compaction in Java.
Fewer CPU cycles overhead per unit of work, i.e. better throughput, which does seem to be an issue for gogc[0]. No risk of quasi-leaks in the allocator due to fragmentation. Reduced cache misses[1]
[0] https://github.com/golang/go/issues/14161 [1] http://stackoverflow.com/q/31225252/1362755