Should I look at the bytecode that is produce by a java compiler?

Question

No

• The JIT compiler may "transform" the bytecode into something completely different anyway.
• It will lead you to do premature optimization.

Yes

• You do not know which method will be compiled by the JIT, so it is better if you optimize them all.
• It will make you a better Java programmer.

I am asking without really knowing (obviously) so feel free to redirect to JIT hyperlinks.

Answer 1

Yes, but to a certain extent -- it's good as an educational opportunity to see what is going on under the hood, but probably should be done in moderation.

It can be a good thing, as looking at the bytecode may help in understanding how the Java source code will be compiled into Java bytecode. Also, it may give some ideas about what kind of optimizations will be performed by the compiler, and perhaps some limitations to the amount of optimization the compiler can perform.

For example, if a string concatenation is performed, javac will optimize the concatenation into using a StringBuilder and performing append methods to concatenate the Strings.

However, if the string concatenation is performed in a loop, a new StringBuilder may be instantiated on each iteration, leading to possible performance degradation compared to manually instantiating a StringBuilder outside the loop and only performing appends inside the loop.

On the issue of the JIT. The just-in-time compilation is going to be JVM implementation specific, so it's not very easy to find out what is actually happening to the bytecode when it is being converted to the native code, and furthermore, we can't tell which parts are being JITted (at least not without some JVM-specific tools to see what kind of JIT compilation is being performed -- I don't know any specifics in this area, so I am just speculating.)

That said, the JVM is going to execute the bytecode anyway, the way it is being executed is more or less opaque to the developer, and again, JVM-specific. There may be some performance tricks that one JVM performs while another doesn't.

When it comes down to the issue of looking at the bytecode generated, it comes down to learning what is actually happening to the source code when it is compiled to bytecode. Being able to see the kinds of optimizations performed by the compiler, but also understanding that there are limits to the way the compiler can perform optimizations.

All that said, I don't think it's a really good idea to become obsessive about the bytecode generation and trying to write programs that will emit the most optimized bytecode. What's more important is to write Java source code that is readable and maintainable by others.

Answer 2

That depends entirely on what you're trying to do. If you're trying to optimize a method/module, looking at the byte code is going to be a waste of your time. Always profile first to find where your bottlenecks are, then optimize the bottlenecks. If your bottleneck seems as tight as it possibly can be and you need to make it faster, you may have no choice but to rewrite that in native code and interface with JNI.

Trying to optimize the generated bytecode will be of little help, since the JIT compiler will do a lot of work, and you won't have much of an idea of exactly what it's doing.

Answer 3

I wouldn't think so. Short of having to debug the javac compiler or wanting to know as a matter of interest, I cannot think of one good reason why someone would care what bytecode gets generated.

Knowing bytecode won't make you a better Java programmer any more than knowing how an internal combustion engine works will make you a better driver.

Think in terms of abstractions. You don't need to know about the actions of quarks or atoms when trying to calculate the orbits of planets. To be a good Java programmer, you should probably learn ... um .. Java. Yes, Java, that's it :-)