why does this code snippet actually take longer when run with the hotspot server JVM?

Here's the code snippet:

https://gist.github.com/987751

For me, it gets times like:

java -client:
  for loop took:     23
  method call took:  19

java -server:
  for loop took:     0   # faster, as expected
  method call took:  48  # slower--expected?

So the first question would be "why is it slower than the client VM"

Also I guess the next question would be "is it possible to get that super 0ms speedup for the method call way (it's almost the same code)?"

Also I presume that despite this weirdness, hotspot in general runs much faster, even with, say, anonymous classes et al?

Thanks!

-roger-

Solution

Its all about how the two flavors of Hotspot are tuned:

Client is tuned for fast(er) startup. It JIT compiles methods "almost" straight away.
Server is tuned for high(er) throughput over the lifetime of a what is assumed to be a long tuning server instance. It lets the interpreter run methods much longer (gathering usage stats) before JIT compiling them. Then (I believe) it performs more aggressive optimization ... which takes longer.

By the way, it is the same Hotspot JVM that is running both client and server modes. AFAIK, the differences are due to the two modes selecting different default JVM tuning / configuration parameters.

So the first question would be "why is it slower than the client VM"

I don't know.

Perhaps the client mode enables a specific optimization that really helps this (highly artificial) benchmark. Or perhaps one of the server mode optimizations is actually an anti-optimization for this (highly artificial) benchmark. If you really want to know, get the JIT compiler to dump the native code and analyse it in detail. (But I think that's a waste of time.)

Also I guess the next question would be "is it possible to get that super 0ms speedup for the method call way (it's almost the same code)?"

That's easy. The optimizer has figured out that the method call does not affect anything else and has optimized away the call. The loop can then be optimized away as well.

Also I presume that despite this weirdness, hotspot in general runs much faster, even with, say, anonymous classes et al?

I don't think you should presume anything.

However, I also don't think your micro-benchmark says anything meaningful about real programs. Micro-benchmarks tend to be misleading in general, and yours is flawed (e.g. the loop that gets optimized away) and doesn't seem to be testing something that a typical (well written) Java program would do.

If you are really concerned about the relative performance of the two modes of HotSpot, you should run and measure the performance of your application on realistic data.

... and why would the server JVM choose something seemingly worse?

The optimizers are designed to optimize real programs ... not micro-benchmarks that spend their time doing strange things that don't bear any resemblance to a useful computation. Not all optimizations are beneficial in all situations, and you've probably hit some kind of edge case.

But this is only relevant if you see the same thing happening in a real application.

Finally, you don't give any details of your JVM version, platform and hardware. These things could make a huge difference to relative performance measures.