Should I use javac -O option to optimize?

Question

javac has an interesting -O option:

Optimizes compiled code by inlining static, final and private methods. Note that your classes may get larger in size.

This option seems to not be popular (hidden?), I've just discovered it today, on CodeCup 2014 page.

-O is not mentioned in the official documentation nor in man javac... Strange.

In accepted answer to similar question, we can read that:

Optimization in Java is mostly done by the JIT compiler at runtime. Hence there is no point trying to instruct it to optimize a certain way at compile time (when it is creating only bytecode anyway). The JIT will almost surely make better decisions on the spot, knowing the exact environment and observing the actual patterns of execution of specific parts of your code.

My question is:

Should I always use the -O option or not? In other words, the code always run faster with -O or does it make no difference at all?

Maybe classes size can increase so much that the overall performance will drop? Or JVM will do the inlining anyway so it's better to leave it to that?

Similar story was with gcc -O3 flag.

Answer 1

It is a no-op according to a comment in the source code around line 553.

It was probably useful when the JIT compiler was not efficient yet or when there was no JIT compiler at all.

Answer 2

I have been working with Java almost since its inception. I have built many systems, some of them high-performance, some of them extreme performance, and I have never, ever, found this flag useful. I think that it may have once had a use, but I have never needed to care.

Answer 3

I don't think It does any optimization as you think:

-O Optimizes compiled code by inlining static, final and private methods. Note that your classes may get larger inj size.

Please have a look into these questions:

• Optimization by Java Compiler
• Java code compiler optimization

Update

You won't find this in any Oracle documentation because it effectively does nothing at all (no-op). Moreover your link is a very very old documentation:

Go up two directories in your link - It's the documentation for jdk 1.1.3. It's 13 - 14 years old! We are now on Jdk 7 and eagerly waiting for Jdk 8.