grow to be a greater Android developer with Compiler Explorer

Posted by Shai Barack – Android Platform Efficiency lead

Introducing Android assist in Compiler Explorer

In a earlier weblog publish you realized how Android engineers constantly enhance the Android Runtime (ART) in ways in which enhance app efficiency on consumer units. These adjustments to the compiler make system and app code quicker or smaller. Builders don’t want to vary their code and rebuild their apps to profit from new optimizations, and customers get a greater expertise. On this weblog publish I’ll take you contained in the compiler with a device referred to as Compiler Explorer and witness a few of these optimizations in motion.

Compiler Explorer is an interactive web site for finding out how compilers work. It’s an open supply mission that anybody can contribute to. This 12 months, our engineers added assist to Compiler Explorer for the Java and Kotlin programming languages on Android.

You should utilize Compiler Explorer to grasp how your supply code is translated to meeting language, and the way high-level programming language constructs in a language like Kotlin grow to be low-level directions that run on the processor.

At Google our engineers use this device to check completely different coding patterns for effectivity, to see how current compiler optimizations work, to share new optimization alternatives, and to show and be taught.
Studying is greatest when it’s achieved by instruments, not guidelines. As a substitute of instructing builders to memorize completely different guidelines for methods to write environment friendly code or what the compiler would possibly or may not optimize, give the engineers the instruments to seek out out for themselves what occurs after they write their code in numerous methods, and allow them to experiment and be taught. Let’s be taught collectively!

Begin by going to godbolt.org. By default we see C++ pattern code, so click on the dropdown that claims C++ and choose Android Java. You need to see this pattern code:

class Sq. {
   static int sq.(int num) {
       return num * num;
   }
}

On the left you’ll see a quite simple program. You would possibly say that this can be a one line program. However this isn’t a significant assertion when it comes to efficiency – what number of strains of code there are doesn’t inform us how lengthy this program will take to run, or how a lot reminiscence might be occupied by the code when this system is loaded.

On the suitable you’ll see a disassembly of the compiler output. That is expressed when it comes to meeting language for the goal structure, the place each line is a CPU instruction. Wanting on the directions, we will say that the implementation of the sq.(int num) methodology consists of two directions within the goal structure. The quantity and sort of directions give us a greater thought for how briskly this system is than the variety of strains of supply code. For the reason that goal structure is AArch64 aka ARM64, each instruction is 4 bytes, which signifies that our program’s code occupies 8 bytes in RAM when this system is compiled and loaded.

Let’s take a short detour and introduce some Android toolchain ideas.

The Android construct toolchain (in short)

While you write your Android app, you’re usually writing supply code within the Java or Kotlin programming languages. While you construct your app in Android Studio, it’s initially compiled by a language-specific compiler into language-agnostic JVM bytecode in a .jar. Then the Android construct instruments remodel the .jar into Dalvik bytecode in .dex information, which is what the Android Runtime executes on Android units. Sometimes builders use d8 of their Debug builds, and r8 for optimized Launch builds. The .dex information go within the .apk that you simply push to check units or add to an app retailer. As soon as the .apk is put in on the consumer’s machine, an on-device compiler which is aware of the particular goal machine structure can convert the bytecode to directions for the machine’s CPU.

We are able to use Compiler Explorer to find out how all these instruments come collectively, and to experiment with completely different inputs and see how they have an effect on the outputs.

Going again to our default view for Android Java, on the left is Java supply code and on the suitable is the disassembly for the on-device compiler dex2oat, the final step in our toolchain diagram. The goal structure is ARM64 as that is the most typical CPU structure in use as we speak by Android units.

The ARM64 Instruction Set Structure provides many directions and extensions, however as you learn disassemblies you can find that you simply solely must memorize a couple of key directions. You’ll be able to search for ARM64 Fast Reference playing cards on-line that can assist you learn disassemblies.

At Google we research the output of dex2oat in Compiler Explorer for various causes, resembling:

• Gaining instinct for what optimizations the compiler performs so as to consider methods to write extra environment friendly code.
• Estimating how a lot reminiscence might be required when a program with this snippet of code is loaded into reminiscence.
• Figuring out optimization alternatives within the compiler – methods to generate directions for a similar code which might be extra environment friendly, leading to quicker execution or in decrease reminiscence utilization with out requiring app builders to vary and rebuild their code.
• Troubleshooting compiler bugs! 🐞

Compiler optimizations demystified

Let’s take a look at an actual instance of compiler optimizations in follow. Within the earlier weblog publish you’ll be able to examine compiler optimizations that the ART group not too long ago added, resembling coalescing returns. Now you’ll be able to see the optimization, with Compiler Explorer!

Let’s load this instance:

class CoalescingReturnsDemo {
   String intToString(int num) {
       change (num) {
           case 1:
               return "1";
           case 2:
               return "2";
           case 3:
               return "3";           
           default:
               return "different";
       }
   }
}

How would a compiler implement this code in CPU directions? Each case can be a department goal, with a case physique that has some distinctive directions (resembling referencing the particular string) and a few widespread directions (resembling assigning the string reference to a register and returning to the caller). Coalescing returns signifies that some directions on the tail of every case physique might be shared throughout all circumstances. The advantages develop for bigger switches, proportional to the variety of the circumstances.

You’ll be able to see the optimization in motion! Merely create two compiler home windows, one for dex2oat from the October 2022 launch (the final launch earlier than the optimization was added), and one other for dex2oat from the November 2023 launch (the primary launch after the optimization was added). You need to see that earlier than the optimization, the scale of the tactic physique for intToString was 124 bytes. After the optimization, it’s down to simply 76 bytes.

That is in fact a contrived instance for simplicity’s sake. However this sample is quite common in Android code. As an example take into account an implementation of Handler.handleMessage(Message), the place you would possibly implement a change assertion over the worth of Message#what.

How does the compiler implement optimizations resembling this? Compiler Explorer lets us look contained in the compiler’s pipeline of optimization passes. In a compiler window, click on Add New > Choose Pipeline. A brand new window will open, displaying the Excessive-level Inner Illustration (HIR) that the compiler makes use of for this system, and the way it’s reworked at each step.

In the event you take a look at the code_sinking move you will notice that the November 2023 compiler replaces Return HIR directions with Goto directions.

A lot of the passes are hidden when Filters > Cover Inconsequential Passes is checked. You’ll be able to uncheck this feature and see all optimization passes, together with ones that didn’t change the HIR (i.e. haven’t any “diff” over the HIR).

Let’s research one other easy optimization, and look contained in the optimization pipeline to see it in motion. Take into account this code:

class ConstantFoldingDemo {
   static int demo(int num) {
       int end result = num;
       if (num == 2) {
           end result = num + 2;
       }
       return end result;
   }
}

The above is functionally equal to the under:

class ConstantFoldingDemo {
   static int demo(int num) {
       int end result = num;
       if (num == 2) {
           end result = 4;
       }
       return end result;
   }
}

Can the compiler make this optimization for us? Let’s load it in Compiler Explorer and switch to the Choose Pipeline Viewer for solutions.

The disassembly reveals us that the compiler by no means bothers with “two plus two”, it is aware of that if num is 2 then end result must be 4. This optimization known as fixed folding. Contained in the conditional block the place we all know that num == 2 we propagate the fixed 2 into the symbolic identify num, then fold num + 2 into the fixed 4.

You’ll be able to see this optimization occurring over the compiler’s IR by choosing the constant_folding move within the Choose Pipeline Viewer.

Kotlin and Java, facet by facet

Now that we’ve seen the directions for Java code, attempt altering the language to Android Kotlin. You need to see this pattern code, the Kotlin equal of the essential Java pattern we’ve seen earlier than:

enjoyable sq.(num: Int): Int = num * num

You’ll discover that the supply code is completely different however the pattern program is functionally similar, and so is the output from dex2oat. Discovering the sq. of a quantity ends in the identical directions, whether or not you write your supply code in Java or in Kotlin.

You’ll be able to take this chance to check fascinating language options and uncover how they work. As an example, let’s evaluate Java String concatenation with Kotlin String interpolation.

In Java, you would possibly write your code as follows:

class StringConcatenationDemo {
   void stringConcatenationDemo(String myVal) {
       System.out.println("The worth of myVal is " + myVal);
   }
}

Let’s learn how Java String concatenation truly works by attempting this instance in Compiler Explorer.

First you’ll discover that we modified the output compiler from dex2oat to d8. Studying Dalvik bytecode, which is the output from d8, is often simpler than studying the ARM64 directions that dex2oat outputs. It’s because Dalvik bytecode makes use of increased stage ideas. Certainly you’ll be able to see the names of varieties and strategies from the supply code on the left facet mirrored within the bytecode on the suitable facet. Attempt altering the compiler to dex2oat and again to see the distinction.

As you learn the d8 output it’s possible you’ll understand that Java String concatenation is definitely carried out by rewriting your supply code to make use of a StringBuilder. The supply code above is rewritten internally by the Java compiler as follows:

class StringConcatenationDemo {
   void stringConcatenationDemo(String myVal) {
       StringBuilder sb = new StringBuilder();
       sb.append("The worth of myVal is ");
       sb.append(myVal);
       System.out.println(sb.toString());
  }
}

In Kotlin, we will use String interpolation:

enjoyable stringInterpolationDemo(myVal: String) {
   System.out.println("The worth of myVal is $myVal");
}

The Kotlin syntax is less complicated to learn and write, however does this comfort come at a value? In the event you do this instance in Compiler Explorer, it’s possible you’ll discover that the Dalvik bytecode output is roughly the identical! On this case we see that Kotlin provides an improved syntax, whereas the compiler emits related bytecode.

At Google we research examples of language options in Compiler Explorer to study how high-level language options are carried out in lower-level phrases, and to raised inform ourselves on the completely different tradeoffs that we would make in selecting whether or not and methods to undertake these language options. Recall our studying precept: instruments, not guidelines. Slightly than memorizing guidelines for the way it’s best to write your code, use the instruments that may show you how to perceive the upsides and drawbacks of various alternate options, after which make an knowledgeable resolution.

What occurs whenever you minify your app?

Talking of constructing knowledgeable choices as an app developer, you have to be minifying your apps with R8 when constructing your Launch APK. Minifying typically does three issues to optimize your app to make it smaller and quicker:

1. Lifeless code elimination: discover all of the dwell code (code that’s reachable from well-known program entry factors), which tells us that the remaining code will not be used, and due to this fact might be eliminated.

2. Bytecode optimization: numerous specialised optimizations that rewrite your app’s bytecode to make it functionally similar however quicker and/or smaller.

3. Obfuscation: renaming every kind, strategies, and fields in your program that aren’t accessed by reflection (and due to this fact might be safely renamed) from their names in supply code (com.instance.MyVeryLongFooFactorySingleton) to shorter names that slot in much less reminiscence (a.b.c).

Let’s see an instance of all three advantages! Begin by loading this view in Compiler Explorer.

First you’ll discover that we’re referencing varieties from the Android SDK. You are able to do this in Compiler Explorer by clicking Libraries and including Android API stubs.

Second, you’ll discover that this view has a number of supply information open. The Kotlin supply code is in instance.kt, however there’s one other file referred to as proguard.cfg.

-keep class MinifyDemo {
   public void goToSite(...);
}

Wanting inside this file, you’ll see directives within the format of Proguard configuration flags, which is the legacy format for configuring what to maintain when minifying your app. You’ll be able to see that we’re asking to maintain a sure methodology of MinifyDemo. “Maintaining” on this context means don’t shrink (we inform the minifier that this code is dwell). Let’s say we’re growing a library and we’d like to supply our buyer a prebuilt .jar the place they will name this methodology, so we’re conserving this as a part of our API contract.

We arrange a view that may allow us to see the advantages of minifying. On one facet you’ll see d8, displaying the dex code with out minification, and on the opposite facet r8, displaying the dex code with minification. By evaluating the 2 outputs, we will see minification in motion:

1. Lifeless code elimination: R8 eliminated all of the logging code, because it by no means executes (as DEBUG is at all times false). We eliminated not simply the calls to android.util.Log, but additionally the related strings.

2. Bytecode optimization: because the specialised strategies goToGodbolt, goToAndroidDevelopers, and goToGoogleIo simply name goToUrl with a hardcoded parameter, R8 inlined the calls to goToUrl into the decision websites in goToSite. This inlining saves us the overhead of defining a way, invoking the tactic, and coming back from the tactic.

3. Obfuscation: we advised R8 to maintain the general public methodology goToSite, and it did. R8 additionally determined to maintain the tactic goToUrl because it’s utilized by goToSite, however you’ll discover that R8 renamed that methodology to a. This methodology’s identify is an inner implementation element, so obfuscating its identify saved us a couple of valuable bytes.

You should utilize R8 in Compiler Explorer to grasp how minification impacts your app, and to experiment with other ways to configure R8.

At Google our engineers use R8 in Compiler Explorer to check how minification works on small samples. The authoritative device for finding out how an actual app compiles is the APK Analyzer in Android Studio, as optimization is a whole-program downside and a snippet may not seize each nuance. However iterating on launch builds of an actual app is sluggish, so finding out pattern code in Compiler Explorer helps our engineers shortly be taught and iterate.

Google engineers construct very massive apps which might be utilized by billions of individuals on completely different units, in order that they care deeply about these sorts of optimizations, and attempt to take advantage of use out of optimizing instruments. However a lot of our apps are additionally very massive, and so altering the configuration and rebuilding takes a really very long time. Our engineers can now use Compiler Explorer to experiment with minification underneath completely different configurations and see ends in seconds, not minutes.

You could marvel what would occur if we modified our code to rename goToSite? Sadly our construct would break, except we additionally renamed the reference to that methodology within the Proguard flags. Fortuitously, R8 now natively helps Preserve Annotations as a substitute for Proguard flags. We are able to modify our program to make use of Preserve Annotations:

@UsedByReflection(sort = KeepItemKind.CLASS_AND_METHODS)
public static void goToSite(Context context, String website) {
    ...
}

Right here is the full instance. You’ll discover that we eliminated the proguard.cfg file, and underneath Libraries we added “R8 keep-annotations”, which is how we’re importing @UsedByReflection.

At Google our engineers favor annotations over flags. Right here we’ve seen one good thing about annotations – conserving the details about the code in a single place fairly than two makes refactors simpler. One other is that the annotations have a self-documenting facet to them. As an example if this methodology was saved often because it’s referred to as from native code, we’d annotate it as @UsedByNative as a substitute.

Baseline profiles and also you

Lastly, let’s contact on baseline profiles. To this point you noticed some demos the place we checked out dex code, and others the place we checked out ARM64 directions. In the event you toggle between the completely different codecs you’ll discover that the high-level dex bytecode is rather more compact than low-level CPU directions. There may be an fascinating tradeoff to discover right here – whether or not, and when, to compile bytecode to CPU directions?

For any program methodology, the Android Runtime has three compilation choices:

1. Compile the tactic Simply in Time (JIT).

2. Compile the tactic Forward of Time (AOT).

3. Don’t compile the tactic in any respect, as a substitute use a bytecode interpreter.

Operating code in an interpreter is an order of magnitude slower, however doesn’t incur the price of loading the illustration of the tactic as CPU directions which as we’ve seen is extra verbose. That is greatest used for “chilly” code – code that runs solely as soon as, and isn’t important to consumer interactions.

When ART detects {that a} methodology is “sizzling”, it will likely be JIT-compiled if it’s not already been AOT compiled. JIT compilation accelerates execution occasions, however pays the one-time price of compilation throughout app runtime. That is the place baseline profiles are available. Utilizing baseline profiles, you because the app developer can provide ART a touch as to which strategies are going to be sizzling or in any other case value compiling. ART will use that trace earlier than runtime, compiling the code AOT (often at set up time, or when the machine is idle) fairly than at runtime. This is the reason apps that use Baseline Profiles see quicker startup occasions.

With Compiler Explorer we will see Baseline Profiles in motion.

Let’s open this instance.

The Java supply code has two methodology definitions, factorial and fibonacci. This instance is ready up with a guide baseline profile, listed within the file profile.prof.txt. You’ll discover that the profile solely references the factorial methodology. Consequently, the dex2oat output will solely present compiled code for factorial, whereas fibonacci reveals within the output with no directions and a measurement of 0 bytes.

Within the context of compilation modes, which means that factorial is compiled AOT, and fibonacci might be compiled JIT or interpreted. It’s because we utilized a unique compiler filter within the profile pattern. That is mirrored within the dex2oat output, which reads: “Compiler filter: speed-profile” (AOT compile solely profile code), the place earlier examples learn “Compiler filter: velocity” (AOT compile all the things).

Conclusion

Compiler Explorer is a good device for understanding what occurs after you write your supply code however earlier than it could actually run on a goal machine. The device is straightforward to make use of, interactive, and shareable. Compiler Explorer is greatest used with pattern code, but it surely goes by the identical procedures as constructing an actual app, so you’ll be able to see the affect of all steps within the toolchain.

By studying methods to use instruments like this to find how the compiler works underneath the hood, fairly than memorizing a bunch of guidelines of optimization greatest practices, you can also make extra knowledgeable choices.

Now that you have seen methods to use the Java and Kotlin programming languages and the Android toolchain in Compiler Explorer, you’ll be able to stage up your Android improvement abilities.

Lastly, do not forget that Compiler Explorer is an open supply mission on GitHub. If there’s a function you’d prefer to see then it is only a Pull Request away.

Java and OpenJDK are logos or registered logos of Oracle and/or its associates.