\n
![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEg6eHy3tppfLFscmsn8p8iHMTYhH__yu1IKO_kr4ce-QNWvtOlfhcY7a8f1NfiuTbHd3ibqfdQ7jhcTY9gHsRHyJp2XibKEGbDOquTUeUg_zJr41AsDZWhUc9WbEXW2Fk2gdH7Yu9dbGHZ9fjTtI2Ffx7E2-p-YrsOn-NjMuma2gOF166Qa8LH8N_VWDZI\/s1600\/0008-AFD-%20Tools%20Banner%20Asset%20_%20Banner%20Design%20_%20Metadata%20Card_meta%20card.png\")
<\/p>\nPosted by Shai Barack \u2013 Android Platform Performance lead<\/em><\/p>\n In a previous blog post<\/a> you learned how Android engineers continuously improve the Android Runtime (ART) in ways that boost app performance on user devices. These changes to the compiler make system and app code faster or smaller. Developers don\u2019t need to change their code and rebuild their apps to benefit from new optimizations, and users get a better experience. In this blog post I\u2019ll take you inside the compiler with a tool called Compiler Explorer<\/a> and witness some of these optimizations in action.<\/p>\n Compiler Explorer is an interactive website for studying how compilers work. It is an open source project<\/a> that anyone can contribute to. This year, our engineers added support to Compiler Explorer for the Java and Kotlin programming languages on Android.<\/p>\n You can use Compiler Explorer to understand how your source code is translated to assembly language, and how high-level programming language constructs in a language like Kotlin become low-level instructions that run on the processor.<\/p>\n At Google our engineers use this tool to study different coding patterns for efficiency, to see how existing compiler optimizations work, to share new optimization opportunities, and to teach and learn. Start by going to godbolt.org<\/a>. By default we see C++ sample code, so click the dropdown that says C++ and select Android Java. You should see this sample code<\/a>:<\/p>\n On the left you\u2019ll see a very simple program. You might say that this is a one line program. But this is not a meaningful statement in terms of performance – how many lines of code there are doesn\u2019t tell us how long this program will take to run, or how much memory will be occupied by the code when the program is loaded.<\/p>\n On the right you\u2019ll see a disassembly of the compiler output. This is expressed in terms of assembly language for the target architecture, where every line is a CPU instruction. Looking at the instructions, we can say that the implementation of the square(int num)<\/span> method consists of 2 instructions in the target architecture. The number and type of instructions give us a better idea for how fast the program is than the number of lines of source code. Since the target architecture is AArch64 aka ARM64, every instruction is 4 bytes, which means that our program\u2019s code occupies 8 bytes in RAM when the program is compiled and loaded.<\/p>\n Let\u2019s take a brief detour and introduce some Android toolchain concepts.<\/p>\n <\/p>\n <\/image><\/p>\n When you write your Android app, you\u2019re typically writing source code in the Java or Kotlin programming languages. When you build your app in Android Studio, it\u2019s initially compiled by a language-specific compiler into language-agnostic JVM bytecode in a .jar<\/span>. Then the Android build tools transform the .jar<\/span> into Dalvik bytecode<\/a> in .dex<\/span> files, which is what the Android Runtime<\/a> executes on Android devices. Typically developers use d8<\/span> in their Debug builds, and r8<\/span> for optimized Release builds<\/i><\/a>. The .dex<\/span> files go in the .apk<\/span> that you push to test devices or upload to an app store. Once the .apk<\/span> is installed on the user\u2019s device, an on-device compiler which knows the specific target device architecture can convert the bytecode to instructions for the device\u2019s CPU.<\/p>\n We can use Compiler Explorer to learn how all these tools come together, and to experiment with different inputs and see how they affect the outputs.<\/p>\n Going back to our default view for Android Java, on the left is Java source code and on the right is the disassembly for the on-device compiler dex2oat<\/span>, the very last step in our toolchain diagram. The target architecture is ARM64 as this is the most common CPU architecture in use today by Android devices.<\/p>\n The ARM64 Instruction Set Architecture<\/a> offers many instructions and extensions, but as you read disassemblies you will find that you only need to memorize a few key instructions. You can look for ARM64 Quick Reference cards online to help you read disassemblies.<\/p>\n At Google we study the output of dex2oat<\/span> in Compiler Explorer for different reasons, such as:<\/p>\n <\/p>\n Let\u2019s look at a real example of compiler optimizations in practice. In the previous blog post<\/a> you can read about compiler optimizations that the ART team recently added, such as coalescing returns<\/i>. Now you can see the optimization, with Compiler Explorer!<\/p>\n Let\u2019s load this example<\/a>:<\/p>\n How would a compiler implement this code in CPU instructions? Every case would be a branch target, with a case body that has some unique instructions (such as referencing the specific string) and some common instructions (such as assigning the string reference to a register and returning to the caller). Coalescing returns<\/i> means that some instructions at the tail of each case body can be shared across all cases. The benefits grow for larger switches, proportional to the number of the cases.<\/p>\n You can see the optimization in action! Simply create two compiler windows, one for dex2oat<\/span> from the October 2022 release (the last release before the optimization was added), and another for dex2oat<\/span> from the November 2023 release (the first release after the optimization was added). You should see that before the optimization, the size of the method body for intToString<\/span> was 124 bytes. After the optimization, it\u2019s down to just 76 bytes.<\/p>\n This is of course a contrived example for simplicity\u2019s sake. But this pattern is very common in Android code. For instance consider an implementation of Handler.handleMessage(Message)<\/a><\/span>, where you might implement a switch statement over the value of Message#what<\/a><\/span>.<\/p>\n How does the compiler implement optimizations such as this? Compiler Explorer lets us look inside the compiler\u2019s pipeline of optimization passes. In a compiler window, click Add New > Opt Pipeline<\/i>. A new window will open, showing the High-level Internal Representation (HIR) that the compiler uses for the program, and how it\u2019s transformed at every step.<\/p>\n If you look at the code_sinking<\/span> pass you will see that the November 2023 compiler replaces Return<\/span> HIR instructions with Goto<\/span> instructions.<\/p>\n Most of the passes are hidden when Filters > Hide Inconsequential Passes<\/i> is checked. You can uncheck this option and see all optimization passes, including ones that did not change the HIR (i.e. have no \u201cdiff\u201d over the HIR).<\/p>\n Let\u2019s study another simple optimization, and look inside the optimization pipeline to see it in action. Consider this code:<\/p>\n The above is functionally equivalent to the below:<\/p>\n Can the compiler make this optimization for us? Let\u2019s load it in Compiler Explorer<\/a> and turn to the Opt Pipeline Viewer for answers.<\/p>\n The disassembly shows us that the compiler never bothers with \u201ctwo plus two\u201d, it knows that if num<\/span> is 2 then result<\/span> needs to be 4. This optimization is called constant folding<\/a>. Inside the conditional block where we know that num == 2<\/span> we propagate<\/i> the constant 2<\/span> into the symbolic name num<\/span>, then fold<\/i> num + 2<\/span> into the constant 4<\/span>.<\/p>\n You can see this optimization happening over the compiler\u2019s IR by selecting the constant_folding<\/span> pass in the Opt Pipeline Viewer.<\/p>\n Now that we\u2019ve seen the instructions for Java code, try changing the language to Android Kotlin. You should see this sample code, the Kotlin equivalent of the basic Java sample we\u2019ve seen before:<\/p>\n You will notice that the source code is different but the sample program is functionally identical, and so is the output from dex2oat<\/span>. Finding the square of a number results in the same instructions, whether you write your source code in Java or in Kotlin.<\/p>\n You can take this opportunity to study interesting language features and discover how they work. For instance, let\u2019s compare Java String concatenation with Kotlin String interpolation.<\/p>\n In Java, you might write your code as follows:<\/p>\n Let\u2019s find out how Java String concatenation actually works by trying this example in Compiler Explorer<\/a>.<\/p>\n![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEg9roV-Qta9lnME3ailZgsr8eVC_lq-BX8RTPQcfW51Y-vMcbvEBFf44_qgVngBX2LLnzr0Fu2Z3hWJJc1ovgsmdFF905VGCst3uopJmHHDw5esD29UMkhLgYn2yl2yE86Hoq-nR3PUxyWHu30kMTBjjfaGIDJet0wIQrB7NPF-H-kZChULzoZhd6Wavos\/s1600\/0008-AFD-%20Tools%20Banner%20Asset%20_%20Banner%20Design%20_banner.png\")
<\/a><\/p>\nIntroducing Android support in Compiler Explorer<\/span><\/h2>\n
\nLearning is best when it\u2019s done through tools, not rules<\/i><\/b>. Instead of teaching developers to memorize different rules for how to write efficient code or what the compiler might or might not optimize, give the engineers the tools to find out for themselves what happens when they write their code in different ways, and let them experiment and learn. Let\u2019s learn together!<\/p>\nclass<\/span> Square<\/span> {\n static int<\/span> square<\/span>(int<\/span> num) {\n return<\/span> num * num;\n }\n}\n<\/pre>\n<\/div>\n<\/a><\/div>\nThe Android build toolchain (in brief)<\/h3>\n
<\/a><\/div>\n\n
\n
\n
\n
\n
Compiler optimizations demystified<\/h3>\n
class<\/span> CoalescingReturnsDemo<\/span> {\n String intToString<\/span>(int<\/span> num) {\n switch (num) {\n case 1<\/span>:\n return<\/span> \"1\"<\/span>;\n case 2<\/span>:\n return<\/span> \"2\"<\/span>;\n case 3<\/span>:\n return<\/span> \"3\"<\/span>; \n default<\/span>:\n return<\/span> \"other\"<\/span>;\n }\n }\n}\n<\/pre>\n<\/div>\n<\/a><\/div>\n<\/a><\/div>\nclass<\/span> ConstantFoldingDemo<\/span> {\n static int<\/span> demo<\/span>(int<\/span> num) {\n int<\/span> result = num;\n if<\/span> (num == 2<\/span>) {\n result = num + 2<\/span>;\n }\n return<\/span> result;\n }\n}\n<\/pre>\n<\/div>\nclass<\/span> ConstantFoldingDemo<\/span> {\n static int<\/span> demo<\/span>(int<\/span> num) {\n int<\/span> result = num;\n if<\/span> (num == 2<\/span>) {\n result = 4<\/span>;\n }\n return<\/span> result;\n }\n}\n<\/pre>\n<\/div>\n<\/a><\/div>\nKotlin and Java, side by side<\/h3>\n
fun<\/span> square<\/span>(num: Int): Int = num * num\n<\/pre>\n<\/div>\n<\/a><\/div>\nclass<\/span> StringConcatenationDemo<\/span> {<\/span>\n void<\/span> stringConcatenationDemo<\/span>(<\/span>String myVal)<\/span> {<\/span>\n System.<\/span>out<\/span>.<\/span>println<\/span>(<\/span>\"The value of myVal is \"<\/span> +<\/span> myVal);<\/span>\n }<\/span>\n}<\/span>\n<\/pre>\n<\/div>\n