Please explain Hotspot optimization refactor from Preconditions.java in guava code base?

Question

I was going through Guava code base and in Preconditions source there is some explanation as quoted below:

All recent hotspots (as of 2009) really like to have the natural code

 if (guardExpression) { throw new BadException(messageExpression); } 

refactored so that messageExpression is moved to a separate String-returning method.

 if (guardExpression) { throw new BadException(badMsg(...)); } 

The alternative natural refactorings into void or Exception-returning methods are much slower. This is a big deal - we're talking factors of 2-8 in microbenchmarks, not just 10-20%. (This is a hotspot optimizer bug, which should be fixed, but that's a separate, big project).

The coding pattern above is heavily used in java.util, eg in ArrayList. There is a RangeCheckMicroBenchmark in the JDK that was used to test this.

But the methods in this class want to throw different exceptions, depending on the args, so it appears that this pattern is not directly applicable. But we can use the ridiculous, devious trick of throwing an exception in the middle of the construction of another exception. Hotspot is fine with that.

For which jvm(s) it is applicable? Why it is slow, I cant understand? What it implies for me as developer? Is it still applicable for java8 jvms by oracle and openjdk? How to take advantage of this piece of information while writing code?

Answer 1

For which jvm(s) it is applicable?

HotSpot - Oracle's JVM implementation

Why it is slow, I cant understand?

It's an idiosyncrasy of the JVM's implementation. There's no particular reason (as far as the JLS/JVMS is concerned) why it should be slower, but as of the last time someone profiled it, it was. The RangeCheckMicroBenchmark class you found has more details and examples.

What it implies for me as developer?

Nothing. Unless you're implementing a class like Preconditions - which has millions of usages that all need to be as close to zero-overhead as possible - you have no reason to worry about this detail. That's why it's a code comment, not a Javadoc comment.

Is it still applicable for java8 jvms by oracle and openjdk?

Probably, yes. The comment doesn't link to a particular HotSpot bug, but you might be able to search for mentions of the benchmark code in the JDK mailing lists and find relevant bugs.

It's highly likely Preconditions would be updated if the JVM's behavior changed.

How to take advantage of this piece of information while writing code?

There's really no need to do so. If you end up writing Guava 2.0 you'll (hopefully) be running your own benchmarks and will find bottlenecks worth fixing that way. Attempting to take advantage of micro-optimizations without rigorously benchmarking your own code is likely to do more harm than good.