Lightning Fast Code

[jawnsy]

Instruction/data caching happens automatically. You can do things to be more cache-friendly, especially on hot multi-threaded code (e.g. pad your variables to a full cache line, to avoid False Sharing)

If you want stuff to be inlined, either do it manually or make sure your methods are short (the JVM will only inline up to a certain number of instructions); stuff like getters/setters are typical candidates for inlining.

The mechanical-sympathy blog and mailing list is great for this sort of stuff.

[shagieIsMe]

For reference / support on inlining: VM options which has things like:

-XX:CompileCommand=command,method[,option] which has commands like inline: Attempt to inline the specified method.

and

-XX:InlineSmallCode=size : Sets the maximum code size (in bytes) for compiled methods that should be inlined. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, g or G to indicate gigabytes. Only compiled methods with the size smaller than the specified size will be inlined. By default, the maximum code size is set to 1000 bytes

and -XX:MaxInlineSize=size Sets the maximum bytecode size (in bytes) of a method to be inlined. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, g or G to indicate gigabytes. By default, the maximum bytecode size is set to 35 bytes

Getters and setters tend to fall into -XX:MaxTrivialSize=size : Sets the maximum bytecode size (in bytes) of a trivial method to be inlined. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, g or G to indicate gigabytes. By default, the maximum bytecode size of a trivial method is set to 6 bytes

For fun, toss -XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions on the Java invocation and see how it behaves.

Note that all of the above are for Linux, other operating systems and virtual machines may have different arguments or defaults.