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.
It's because the underlying optimizer follows patterns in LLVM, which is used for a lot of languages, most applicable here is C/C++, and bit things like this are used a lot for performance.
The particular patterns were added to C2 just recently, being copied from the implementations in LLVM and GCC.
Also it's unlikely the compiler looks for this in particular, but this falls out of a set of optimizations that do matter and it collapses into the output assembly on relevant architectures.
gcc and LLVM have also copied ideas from C2, and there's been cross-pollination between Java and C++ compilers going back decades. All three are among the most sophisticated optimising compilers right now.
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.
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.
It's because the underlying optimizer follows patterns in LLVM, which is used for a lot of languages, most applicable here is C/C++, and bit things like this are used a lot for performance.
The particular patterns were added to C2 just recently, being copied from the implementations in LLVM and GCC.
Also it's unlikely the compiler looks for this in particular, but this falls out of a set of optimizations that do matter and it collapses into the output assembly on relevant architectures.
gcc and LLVM have also copied ideas from C2, and there's been cross-pollination between Java and C++ compilers going back decades. All three are among the most sophisticated optimising compilers right now.
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.
Why is this known bits optimization being done by the JIT rather than the Java compiler?
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.
The Java compiler almost does ZERO optimizations.
So you really want to you should ask why the JIT rather than compiler does optimizations in Java?