The part of this that's the most interesting to me is the fact that it is worthwhile for the compiler to expend the effort looking for this optimization opportunity. I would expect (x << 2) & -4 to be a fairly rare pattern, and even then removing the & -4 only saves one or two assembly instructions.
Every optimisation like this increases the chance of other optimisations/vectorisations being able to usefully fire, and sometimes these very specific cases are themselves from optimisations or type/range restrictions.
Because you might want to put a breakpoint on that line of code and debug the variables going in and coming out.
But further, optimizing in the compiler can preclude future optimizations by the JIT. Giving the JIT more information can make it make better decisions.
Also, the JIT needs to do that optimization anyways. If a class was compiled with Java 1.0, it might miss some optimizations introduced in the Java 27 compiler. To cover for that, the JVM 27 will need in it's jit the optimizations which were missing from the 1.0 javac if it wants to keep making the code go faster.
That's why the JVM developers have ultimately pushed to make javac pretty dumb and the JIT pretty smart. They can make much better optimizations in the JIT which are retroactive.
This is a good list. Other reasons are that the JIT has more information about the program. The Java-to-bytecode compiler never sees the whole application, and it knows nothing about which program paths are actually executed in practice. The JIT compiler, in contrast, knows about the loaded class hierarchy, and it has access to type and branch profile information. This enables the JIT to do aggressive inlining of method calls and pruning of branches that are never executed. These are probably the most important transformations that lead to the discovery of opportunities for these mask optimizations. The source code that javac sees will contain very few relevant cases.
But further, optimizing in the compiler can preclude future optimizations by the JIT. Giving the JIT more information can make it make better decisions.
Also, the JIT needs to do that optimization anyways. If a class was compiled with Java 1.0, it might miss some optimizations introduced in the Java 27 compiler. To cover for that, the JVM 27 will need in it's jit the optimizations which were missing from the 1.0 javac if it wants to keep making the code go faster.
That's why the JVM developers have ultimately pushed to make javac pretty dumb and the JIT pretty smart. They can make much better optimizations in the JIT which are retroactive.