CODEWITHSUNDEEP
javaoptimizationjvmbytecode
user1898811
user1898811

Reputation:

JVM Bytecode instruction Tload_<n> vs Tload

I've been nerding out on JVM byte code lately, and I'm wondering if restructuring performance critical code to take advantage of the Tload_<n> instructions (aload_0, aload_1, aload_2, etc) rather than the two operand Tload instructions would net any appreciable performance benefit?

This falls squarely into the category of "micro-optimizations you will never need", but consider it an academic curiosity. If a method can keep its local variable table under 7 entries, what performance benefits (if any) could manifest themselves? I'm thinking this might just result in ever-so-slightly smaller byte-code.

Bonus points for quality links to reading material on bytecode level optimizations!

Upvotes: 2

Views: 78

Answers (1)

Hot Licks
Hot Licks

Reputation: 47729

The short loads are there primarily because of the original purpose of Java bytecodes. Originally the language was designed for set-top boxes and was made as compact as possible, so having special short versions of frequently-used instructions was deemed worthwhile, to save RAM/ROM.

There is also, in the interpreter, a minuscule performance advantage in that the interpreter routines can be individually coded with the necessary offsets built in.

However, in JITCed code there is no difference -- all the ops would fold into the same logic, which might take advantage of a short machine instruction for short offsets, but not at the same boundaries as the short bytecodes.

Upvotes: 4

Related Questions