Page History

...

Getting solid performance measurements is surprisingly tricky. Take extra care with micro-benchmarks.

See below for a list of relevant presentations and papers.

Here is another slice on the same information, from another angle: PerformanceTacticIndex.

Constants

• Use constants when you can.
• It's OK to store them in local variables; the SSA representation tends to keep them visible.
• It's OK to store them in static final fields, too.
• Static final fields can hold non-primitive, non-string constants.
• The class of a static final field value is also constant, as is the array length (if it's an array).

...

• Use a disassembler if available to inspect the generated code.
• Switches are profiled but the profile information is poorly used. For now, consider building an initial decision tree if you know one or two cases are really common.
• Exception throwing compiles to a goto, if the thrower and catcher inline together. For such uses, rely on preallocated or cloned exceptions, or override the fillInStackTrace part of exception creation, which is an expensive, reflective native call.
• Do not use jsr/ret. Just clone your finally code if you have to.
• If you are compiling a non-Java language, consider using standard mangling conventions.
• If you are generating almost the same class many times in a row, with small variations, factor out the repeating parts into a superclass or static helper class.
• For small variations in the remaining part, consider using a single named class as a template and loading it multiple times as an anonymous class with constant pool edits. Anonymous classes load and unload faster than named ones.

Presentations and Papers

• Buckley & Rose, Towards a Universal VM, Oracle Open World 2009. Includes summary of HotSpot optimizations.
• Schwaighofer, Tail Call Optimization in the Java HotSpot VM, Master's thesis, Johannes Kepler University Linz, 2009. Pages 23-35 are a good introduction to HotSpot architecture.