INVESTIGATING ANDROID BYTECODE EXECUTION ON JAVA VIRTUAL MACHINES

Transcription

1 INVESTIGATING ANDROID BYTECODE EXECUTION ON JAVA VIRTUAL MACHINES A DISSERTATION SUBMITTED TO THE UNIVERSITY OF MANCHESTER FOR THE DEGREE OF MASTER OF SCIENCE IN THE FACULTY OF ENGINEERING AND PHYSICAL SCIENCES 2016 By Salim Shaaban Salim School of Computer Science

2 Table of Contents List of Figures... 5 List of Tables... 6 Abstract... 7 Declaration... 8 Intellectual Property Statement... 9 Acknowledgements Chapter 1. Introduction Project Context Project Motivation Aims and Objectives Project Deliverables Thesis Structure Chapter 2. Background Introduction The Android Runtime and Dalvik VM Android Bytecode Dalvik Executable (DEX) File Format Dalvik Bytecode Instruction Set Android Bytecode vs Java Bytecode Stack-Based Virtual Machines Register-Based Virtual Machines The Truffle Framework Self-Optimising Interpreter Partial Evaluation Type System and Domain-Specific Language Languages Interoperability (Polyglot) The Graal Compiler Speculative Optimisation Graal API and Dynamic Class Loader

3 Graph-Based Intermediate Representation Scanning, Parsing and AST Interpretation with the Truffle Framework Related Work Redex Bytecode Optimiser LLVM IR Interpreter (Sulong) Summary Chapter 3. Methodology and System Design Introduction Methodology Research and Familiarisation with the Truffle Framework Understanding the Dalvik Executable Format (DEX) Building DEX AST Interpreter with the Truffle Framework Benchmarking, Optimisation and Evaluation Development Environment System Design System Architecture Program Execution Design Design Assumptions Summary Chapter 4. Project Implementation Introduction Bytecode Reader DEX Parser AST Interpreter Nodes Implementation Data Types Implementation Statements and Expressions Implementation Variables and Data Access Implementation Control Flow Implementation Arrays and Object Structures Implementation Methods and Classes Implementation Java API Calls Unimplemented Features of the Android Platform

4 4.6.1 Incomplete Instruction Set Implementation Android Native Code Applications with User Interface Hardware Interaction Summary Chapter 5. Testing and Evaluation Introduction Achievements Existing Android Java Benchmarks Test Suites and Benchmarks Experimental Setup Java SciMark Embedded CaffeineMark Test Suite Summary Chapter 6. Conclusion and Future Work Summary Project Findings Limitations Future Work References Appendix A. Android Instructions (Opcodes) Implemented Appendix B. TruffleDEX Test Cases Appendix C. Generating DEX Files from Java Classes Word Count:

5 List of Figures Figure 1-1: Work flow of the steps involved in this project Figure 2-1: Dalvik and ART architecture (Image Source: [14]) Figure 2-2: Bytecode representation of a simple example in hexadecimal form Figure 2-3: A simple addition example in Java Figure 2-4: Simple addition representation for stack-based machine Figure 2-5: Simple addition representation for register-based machine Figure 2-6: Implementation of addition operator for different data types Figure 2-7: Node rewriting and partial evaluation to produce machine code (Image Source: [4]) Figure 2-8: The type system for the AST interpreter Figure 2-9: Detailed system structure of the Truffle implementation (Image source: [4] ) Figure 2-10: LLVM IR representation of simple addition Figure 3-1: The architecture of the project Figure 4-1: Execution context of the program Figure 4-2: Part of the root node class Figure 4-3: Example of inner class implementation for related opcodes Figure 4-4: Lexical scope implementation Figure 4-5: Parsing and setting initial call target Figure 4-6: Node classes definitions for top classes of node hierarchy Figure 4-7: Implementation of integer literal node class Figure 4-8: Multiplication operation implementation Figure 4-9: Implementation of byte literal local write Figure 4-10: Implementation of byte local variable read Figure 4-11: Implementation of argument values read Figure 4-12: Implementation of cached property read Figure 4-13: A loop with jumps that goes outside its block (in mnemonic code) Figure 4-14: Implementation of the jump exception Figure 4-15: Implementation of the if node which throws a control flow exception Figure 4-16: Implementation of the handling of the control flow exception for jumps Figure 4-17: Implementation of the method Figure 4-18: Method dispatcher implementation with cache Figure 4-19: Java API call implementation using reflection Figure 5-1: SciMark 2.0 Benchmark results Figure 5-2: Embedded CaffeineMark 3.0 Benchmark results Figure 5-3: TruffleDEX suite benchmark results

6 List of Tables Table 2-1: Some android bytecode opcodes and their description Table 4-1: Unimplemented opcodes Table 5-1: List of custom test suites and their exercising features Table 5-2: SciMark 2.0 benchmarks description Table 5-3: SciMark 2.0 statistical summary of results Table 5-4: Embedded CaffeineMark 3.0 benchmarks description Table 5-5: Embedded CaffeineMark 3.0 statistical summary of results Table 5-6: TruffleDEX suite test cases description Table 5-7: TruffleDEX suite statistical summary of results

7 Abstract Handheld devices such as smartphones and tablets have emerged to be common among users interacting with different applications. Android is one of the operating systems used on those devices. One of the key component for running Android applications is the Android runtime, which hosts applications and executes bytecodes. The speed of execution provided by the runtime influences the experiences users get when using these applications. This thesis presents the TruffleDEX project which aims to explore how Android bytecodes can be parsed, interpreted and executed on Java Virtual Machines (JVMs). The TruffleDEX project is implemented using the Truffle framework which provides novel methods and techniques for implementing languages targeting JVMs. The thesis describes the design and implementation of TruffleDEX. It explains how the TruffleDEX implements data types, data structures and other instructions of the Android bytecode instruction set. The thesis also elaborates on the techniques developed to support the unstructured flow of execution and jumping behaviour of bytecodes. Additionally, the thesis presents an evaluation of the implementation and performance benchmarks. The evaluation concludes on the possibility of hosting Android applications on JVMs. Furthermore, the results of the evaluation and benchmarks presented in the thesis provide insights on the possibility of providing a better performing Android execution environment. The thesis also identifies challenges facing Truffle implementations of bytecodes and unstructured execution. 7

8 Declaration No portion of the work referred to in the dissertation has been submitted in support of an application for another degree or qualification of this or any other university or other institute of learning. 8

9 Intellectual Property Statement i. The author of this dissertation (including any appendices and/or schedules to this dissertation) owns certain copyright or related rights in it (the Copyright ) and s/he has given The University of Manchester certain rights to use such Copyright, including for administrative purposes. ii. iii. iv. Copies of this dissertation, either in full or in extracts and whether in hard or electronic copy, may be made only in accordance with the Copyright, Designs and Patents Act 1988 (as amended) and regulations issued under it or, where appropriate, in accordance with licensing agreements which the University has entered into. This page must form part of any such copies made. The ownership of certain Copyright, patents, designs, trademarks and other intellectual property (the Intellectual Property ) and any reproductions of copyright works in the dissertation, for example graphs and tables ( Reproductions ), which may be described in this dissertation, may not be owned by the author and may be owned by third parties. Such Intellectual Property and Reproductions cannot and must not be made available for use without the prior written permission of the owner(s) of the relevant Intellectual Property and/or Reproductions. Further information on the conditions under which disclosure, publication and commercialisation of this dissertation, the Copyright and any Intellectual Property and/or Reproductions described in it may take place is available in the University IP Policy (see in any relevant Dissertation restriction declarations deposited in the University Library, and The University Library s regulations (see 9

10 Acknowledgements I would like to express my sincere gratitude to my supervisor Dr. Mikel Luján for his invaluable guidance, support, inspiration, understanding and most importantly, his engagement throughout the learning process of this master s project. His advices helped me gain an in-depth understanding of the subject and be able to produce the project discussed in this thesis. I would also like to express my gratitude to the Commonwealth Scholarship Commission in the UK and the Association of Commonwealth Universities for their financial support which provided me with this opportunity to pursue master studies in the UK. Furthermore, I would like to thank Dr. Bijan Parsia for his advice and guidance during the project selection process and generally throughout the year. Many thanks also to the Advance Processor Group members who have supported me throughout the project time. Last but not least, I would like to thank my family and friends for their love and support. Special thanks to my parents, sister and brothers for keeping me harmonious. Without their love this work would not have been possible. 10

11 Chapter 1. Introduction 1.1 Project Context Android is one of the most popular platforms for handheld devices such as smartphones and tablets [1]. Most developers use the Java programming language to write Android applications. In the Android Standard Development Kit (SDK), libraries and frameworks provide Application Programming Interfaces (APIs) that can be accessed by Java applications when writing source code. Although Android applications are developed in Java, they are not run on standard Java Virtual Machines (JVMs) during execution. Rather, the Android operating system contains the Android Runtime (ART) that executes these applications [2]. Prior to ART and Android 4.4 (KitKat), the Dalvik Virtual Machine was the process execution virtual machine for Android applications [2]. The increased usage of Android applications in wearable devices and embedded systems have motivated the need for high performing applications under limited resources available on such environments [3]. This has led to some companies, such as Google and Facebook, to develop tools that produce optimized and better performing applications for mobile platforms. Although, apart from generating optimized code, the performance of an application also depends on the runtime environment or Virtual Machine (VM) that host that application. Developing high performing runtime environments and VMs is a complex process [4]. Many languages developed to run on these managed runtime environments, such as Python and Ruby has shown poor performance compared to unmanaged languages [5]. A JVM, among others, is one of the best performing virtual machine and the most popular target for new languages implementation [6]. Due to this reason and the availability of the Open Java Development Kit (OpenJDK) project, which provides a free and open source implementation of the Java Platform, JVMs have been growing to support many languages other than Java [7]. As a result, language developers and designers can (re)implement their languages to specifically benefit from the performance, runtime environment and other features available in the Java platform. To benefit from these improvements in the Java platform, this MSc thesis has investigated methods to execute and host Android applications on JVMs. The project has also investigated the performance benefits provided by JVMs compared to the default environments available in the Android system. 11

12 1.2 Project Motivation To support and simplify the implementation of languages that are targeting JVMs, Oracle Inc. has developed a framework, called Truffle, to help developers design and implement languages using the Java programming language [8]. The company also provides the Graal VM, which is a special version of JVMs that contains a dynamic optimizing compiler, called Graal compiler, and provides APIs for interacting with this compiler. Together, the Truffle and Graal frameworks are used by languages developers that are targeting the JVM and would prefer to benefit from a high performing compiler provided by the Graal VM [9]. Many languages that have been re-implemented using the Truffle and Graal frameworks have shown improved performances compared to their original implementation. The evidence of this improvement in performance can be clearly seen in the case of the JavaScript implementation on Truffle. The results obtained from different benchmarks [10] have shown the Truffle implementation of JavaScript performing better or closely to the high performing JavaScript engines such as the V8 [11], which is used in Google Chrome, and the SpiderMonkey [12] which is used in Mozilla Firefox. Despite the current good performance provided by the Android system, there are still room for improvements. The performance benefit provided by the Truffle framework and the Graal VM motivated this investigation of benefits in performance for Android applications when run on the JVM. 1.3 Aims and Objectives The main aim of this thesis is to investigate the execution of Android applications on the JVM by parsing and running Android bytecodes in the Dalivik Executable (DEX) and Executable and Linkable Format (ELF) files using the Truffle and Graal frameworks. Several specific objectives are associated with this project to produce a fully Abstract Syntax Tree (AST) interpreter for the DEX format. The AST interpreter developed, called TruffleDEX [13], is then run on the Graal VM (or any other JVM) to produce execution environment for Android applications. These objectives are as follows: Studying and understanding the Truffle framework for programming languages implementation. This helped to familiarize with the framework specific implementation features and constructs that are used when developing an AST interpreter. 12

13 Studying and understanding the DEX format instructions and their implementation details. The DEX format contains bytecode instructions that need to be parsed in order to produce an AST. Understanding these instructions enabled the development of the parser and the AST interpreter. Using the Truffle framework to develop and link together parser and AST interpreter for the android bytecode. As a result, Android DEX files can be hosted by the JVM. Generating test suite for sample Android applications. The test suite will be used to produce benchmark results. This stage involved the conversion of Java-based benchmark test suites into Android DEX files and also organising other Android specific test suites. Analysing and evaluating benchmark results by identifying ways to improve android code execution on the JVM. The Benchmark evaluation helped identifying possible improvements that can be applied to the AST interpreter in order to produce optimized code for scenarios where the JVM hosted code run slower that the Android runtime hosted one. 13

14 To accomplish these objectives, this project was carried out by following steps as shown in a work flow diagram in Figure 1-1. Figure 1-1: Work flow of the steps involved in this project. 1.4 Project Deliverables The deliverables of this thesis are the following: A DEX AST interpreter, called TruffleDEX, developed with the Truffle framework for the Dalvik Executable Format (DEX) of the Android 6 API level 23. A test suite with sample Android applications that can be executed with the DEX AST interpreter. 14

15 A report document on design and implementation describing suggested methods for improving execution time as identified by the project to produce better AST interpreters for Android bytecode. 1.5 Thesis Structure In addition to the introduction chapter, this thesis includes five more chapters. Chapter 2 provides background information on bytecodes and how Android bytecode instructions are organised and executed by their environment. Furthermore, a discussion on the different kinds of VMs and the difference between Android and Java bytecode is provided. At the end of Chapter 2, a literature review on the Graal and Truffle frameworks is discussed in detail and closely related work is presented. Chapter 3 discusses the methodology used for development and the environment used during the process. The chapter also outlines the design and architecture of the system developed while focusing on elaborating the design choices for parser and interpreter. In Chapter 4, an implementation of the TruffleDEX is discussed. The chapter elaborates development choices made when working on different parts of the system. The chapter also discusses implementation constraints that were solved and how they were solved as well as those that remained unsolved. For unsolved issues, this chapter discusses possible ways that could be used but were never achieved in this project. Testing and evaluation are discussed in Chapter 5 of the thesis. The chapter discusses benchmarks that were used to test and evaluate the project and their results are presented. At the end, benchmark results and analysed are also discussed. Finally, the Chapter 6 concluded the thesis by discussing conclusion remarks and limitations of the project. Furthermore, suggested future work is also presented. 15

16 Chapter 2. Background 2.1 Introduction This chapter provides a background research about the Android Runtime, Dalvik VM, bytecode and how Android bytecode instructions are organized and executed by the runtime system. Section 2.3 to 2.5 discuss bytecodes and Android DEX format in details while Section 2.6 compares the differences between Android and Java bytecode formats. Furthermore, Section 2.7 and 2.8 discuss different kinds of VMs and how bytecode is presented in such VMs. From Section 2.9 to 2.11, a literature review on the Graal and Truffle frameworks are discussed in detail and a discussion on how a Truffle AST interpreter is developed is presented. Finally, Section 2.12 discusses closely related work. 2.2 The Android Runtime and Dalvik VM The Android Runtime (ART) is a managed application runtime environment used by the android operating system [2]. Both ART and its predecessor, Dalvik VM, execute the Dalvik Executable (DEX) files. In ART, DEX files are compiled into native machine code during installation using Ahead-Of-Time (AOT) compilation [2]. The result of the AOT compilation is the Executable and Linkable Files (ELF) which contain both DEX and native code. The Dalvik virtual machine, which is the predecessor of ART, optimizes DEX file during installation to produce optimized DEX files (ODEX), but no AOT compilation is done at this stage. Latter during execution, ODEX files are compiled using Just-In-Time (JIT) compilation [2]. Figure 2-1 illustrates the ART and Dalvik architecture as part of the Android system. 16

17 Figure 2-1: Dalvik and ART architecture (Image Source: [14]). 2.3 Android Bytecode Bytecodes are intermediate representations that act as machine language for a specific VM. Each instruction in bytecode is formed by an opcode, which indicates the action of the instruction, followed by zero or more operands. Operands normally hold information about registers or literal values to compute. Bytecodes are represented in hexadecimal format but each opcode normally has a mnemonic code in the form of assembly for easy understanding. Table 2-1 lists some of the most common opcodes of Android and their description [15]. Opcode Mnemonic Description (Hexadecimal ) Code 0E return-void Return the control from a method without a return value. 0F return vx Return with a return value in register vx. 17

18 10 return-wide vx Return with a value that requires more than one register and store the result at registers starting at vx. This opcode is used to return long and double values. 11 return-object vx Return an object reference at vx. 13 const/16 vx, lit16 Store a 16-bit constant literal (lit16) in a register vx. 90 add-int vx, vy, vz Compute vy + vz register values and store the result in vx. 32 if-eq vx, vy, If value at vx is equals to the vy, then move to a target. A target target is an instruction for the execution to move to. Table 2-1: Some android bytecode opcodes and their description. 2.4 Dalvik Executable (DEX) File Format The Android DEX file uses bytecode to store its instructions, which is different from bytecode executed by the Java VMs. Each DEX file contains a header which, among other things, contains a special list of bytes that must appear at the beginning of each DEX file [16]. This list of bytes (also known as "file magic") is used to identify the Android version used by the file and detect corrupted files. Figure 2-2 shows a simple "Hello World" example and its respective Android bytecode in hexadecimal format as display by the Bytecode Viewer (Version 2.9.8) program. The right hand side panel displays bytecode instructions from the DEX file while the left hand side panel shows the respective Java source. Figure 2-2: Bytecode representation of a simple example in hexadecimal form. The header is then followed by a list of string identifiers containing all strings referred by the code. Then a list of type identifiers such as classes, arrays and primitive types is listed followed by a list of method prototypes used in the source code. The file also contains a list of fields, method identifiers and class definitions referred or defined by the file source code. 18

19 The bytecode in DEX file also contains all supporting data associated with classes, methods and other identifiers specified in other lists mentioned in the file. When a method is called, the bytecode instructions associated with it are loaded for execution. 2.5 Dalvik Bytecode Instruction Set The instruction set of the Android bytecode consists of 218 instructions that are encountered in the normal flow of execution [15]. These instructions build the execution body of methods and classes in the DEX file. When executing, most of the instructions read and/or write data from and to registers which are identified using numbers. Each method contains a frame with a specific predefined number of registers which it requires to run. These registers are 32-bits in size, and a pair of adjacent registers is used if an instruction requires to store a 64-bits value. Such instructions that operates on 64-bits values are identified by a -wide suffix. Some other instructions operate on specific types; such instructions are also identified with a suffix telling which type they operate on. For example, an addition operator has different instructions identified by the type they operate on such as add-int, add-double, add-float and addlong. The use of type specific operators reduces the need to include type checking and type conversion instructions each time a value is read. This means fewer instructions are needed for such operations. Some other instructions operate on the same types and register size but provide different options when executing. Such instructions are differentiated using a forward slash ( / ) followed by suffix indicating the difference. For instance, method calling is done using invoke operator. The operator specifies the kind of invocation such as invoke-virtual, which is used to invoke a normal, non-static method. The invocation also lists registers that their values should be used for arguments to a called method. But some methods can be called with flexible number of registers that can only be known at runtime (array arguments for example). These methods are then called using invoke-virtual/range instruction, which instead of listing which exact registers to be used as parameters, tells a starting register and how many registers to pass as parameters. Here the operation performed by invoke-virtual and invokevirtual/range is the same, the only difference is the options for which registers to use as parameters [15]. Most of these regular instructions are independent of each other. This means they can appear in any order depending on how the program is developed. Nevertheless, some opcodes are 19

20 strictly required to appear immediately after other specific opcodes and their appearance anywhere else is invalid [15]. Example of such instructions are move-result opcodes, which can only appear after method invocation opcodes or a filled-new-array opcode. This is because the move-result opcodes main duty is to move the result returned by the previous instruction to a specific register. Other than the regular execution instructions, there are other pseudo-instructions that are part of the Dalvik instruction set. These instructions are not part of the method execution block but are referred by the executing instructions. The pseudo-instructions are used as data payload for arrays and lookup tables for switches. A switch instruction in the method body will contain a reference (offset) to the switch-payload operator that contains a lookup table with information about where to go for different values. The instruction and pseudo-instructions build the Dalvik instruction set that each Android bytecode file contains. Some of these instructions are listed in Table 2-1, while a full list of instructions that were implemented in this project is provided in Appendix A. 2.6 Android Bytecode vs Java Bytecode Bytecode used in the DEX files is set to be executed by register-based machines [15]. The instructions refer to registers when dealing with variables and objects reading and writing. This is different from Java bytecode where variables are listed in a variable list and pushed to the variable space (in the form of stack) when needed to be used. Since JVMs are stack-based machines [7], Java bytecode normally requires extra opcodes to transfer data to and from the stack. These opcode instructions are not available in the Android bytecode and thus, among other reasons, resulted into Android bytecode not being able to be hosted directly by standard JVMs. Other than the difference in bytecode instructions, many improvements have been done to improve performance and efficiency of DEX for the Android system. Firstly, all classes in the same application are compiled into the same DEX file, which is different from individual.class files in Java. Secondly, in DEX files, 32-bit signed and unsigned quantities are encoded using LEB128 (Little Endian Base 128) to reduce byte consumption [16]. Furthermore, DEX files benefit from fewer instructions and as a result a smaller number of bytes is required to store a similar piece of code compared to Java. These improvements reduce the size of an actual program and in return less memory is used by an application. 20

21 2.7 Stack-Based Virtual Machines A stack-based virtual machine implements (emulates) a real machine by storing computational results and other data in a form of stack (Last-In First-Out data structure) instead of individual registers available in a real machine. Stack-based machines contain a stack where frames are pushed into each time a method is called. When a method finishes executing, and it returns the control to its caller method, the frame is popped from the stack [17]. Each frame contains information about its method, local variables space and instructions stack (operand stack). Computation is done by pushing and popping instructions to and from the instruction stack and the result of those computations is stored in the variable space as needed. int num1 = 15; int num2 = 30; int sum = num1 + num2; Figure 2-3: A simple addition example in Java. When targeting a stack-based machine, a simple addition example in Java as shown in Figure 2-3 can be represented in JVM bytecode (using mnemonic) as shown in Figure 2-4. As elaborated by the comments provided, to store data into a variable, it has to be pushed and then popped from the stack. Most of the opcodes are also prefixed by a data type indicator like i for int and l for long. This reduces the need for extra type checking and conversion instructions bipush 15 // Push int constant into stack. istore_1 // pop int from stack to local variable position 1 bipush 30 // Push int constant into stack. istore_2 //pop int from stack to local variable position 2 iload_1 //push int from local variable at position 1 into the stack iload_2 //push int from local variable at position 2 into the stack iadd //add two integers istore_3 //pop the result iadd into a local variable Figure 2-4: Simple addition representation for stack-based machine. in each load or store operation as each opcode expects its own data type [7]. For this reason, JVM has different opcodes of the same operation only differ in data types they are operating on. As an example, popping data from a stack to a local variable can be performed by istore, lstore, dstore or others depending on the type [7]. 2.8 Register-Based Virtual Machines Register-based virtual machines emulates a real machine using registers to store data. In register-based machines, method frames contain registers as needed by the method. These 21

22 registers include special purposes registers such as Program Counter (PC) and general purposes registers which are used for storing method data and local variables [17]. The example from Figure 2-3 could be represented in Android bytecode as shown in Figure 2-5 if the target machine is register-based machine. const/16 v0, 0x0f const/16 v1, 0x1e add-int v3, v0, v1 Figure 2-5: Simple addition representation for register-based machine. As shown in Figure 2-5, all instructions related to pushing to and popping from the stack are not available in register-based instructions. Instead these instructions use register numbers (v0, v1 and so on) to tell where the result of the instruction should be stored. 2.9 The Truffle Framework The Truffle framework was developed by Oracle to support and simplify the development of languages that target JVMs [9]. The Truffle framework provides an API for implementing AST interpreters for guest languages. This project uses Truffle to implement AST interpreter for the Android bytecode. The Truffle framework provides many features to a language developer, some of them are described in the following sub-sections Self-Optimising Interpreter Together with other features such as frames and variable handling, the Truffle framework provides optimization process where nodes have the ability to replace themselves [4]. Some guest languages are dynamic typed, which means the type of the variable is only known at runtime after being assigned a value. The Truffle framework allows the syntax tree to be modified and change node types to a more specialized type during interpretation. This allows a node to modify itself to a more specialized execution implementation related to its state at runtime. To understand type specialization, take an example the addition operator (+ sign). Addition can be applied to numeric types such as integer, byte and double as well as string concatenation. If the left and right operands of an addition expression are simple integers, a simple addition can be carried out and return back an integer. On the other hand, if this value happens to cause an overflow and does not fit any more on an integer, the addition node can be rewritten to be done by long or BigInteger addition. The node rewrite would also occur if a long variable carries 22

23 a very small value that can be done by integer or byte and save memory needed to store long variable. The implementation of such addition node in Truffle will look as shown in Figure 2-6. The annotations inform the Truffle framework whether the implementation is specialized to a specific type or is a generic and should be used only for types that did not match other specialization provided in this = "+") public abstract class DexAddNode extends DexBinaryNode = ArithmeticException.class) protected long add(long left, long right) { long result = ExactMath.addExact(left, right); return = ArithmeticException.class) protected int add(int left, int right) { int result = ExactMath.addExact(left, right); return result; = "isstring(left, protected String add(object left, Object right) { return left.tostring() + right.tostring(); Figure 2-6: Implementation of addition operator for different data types. Figure 2-7 shows how node rewriting during interpretation can rewrite a node to a specialized type (Integer in this case). Node rewriting uses frequency information and profiling feedback to decide for the best specialization of the node. The rewriting is very helpful when implementing dynamic languages where variables are allowed to hold values of different types and will change their types dynamically depending on which value they are currently holding. Figure 2-7: Node rewriting and partial evaluation to produce machine code (Image Source: [4]). 23

24 2.9.2 Partial Evaluation Partial evaluation is used to specialize programs based on the current know input for the purpose of producing compiled code for only stable and hot code [4]. During this evaluation, generated code is attached with specialization information and information on the state of the input. Input can be known during evaluation time based on profiling information or other means, on which case the state of the input is marked as static. On the other hand, if the input is not yet known, it will be decided dynamically at runtime [4]. With partial evaluation, branches and blocks of code which are unlikely to execute are eliminated in the compiled code. As a result, unnecessary memory access operations and condition checking are eliminated and thus produces optimized code [10]. In a case where the omitted code is needed, the execution is transferred back to the interpreter and continue running the part of the code that was not compiled earlier Type System and Domain-Specific Language To eliminate the need for developers to manually write type checking and verification code for each type available in the guest language, Truffle provides a Domain-Specific Language (DSL) that can be used to generated specified code for each guest type [18]. Developers are responsible to write their type system and identify all types by mapping them to Java primitive types or the Object class. Then developers implement an expression node for each type so Truffle will understand how to execute each short.class, long.class, int.class, long.class, BigInteger.class, boolean.class, String.class, DLFunction.class, DLClass.class, SLNull.class) public abstract class DexTypes { DSL type system uses annotation processor to generate source code needed for type checking and conversion. Figure 2-8 illustrates how type mapping is done using Figure 2-8: The type system for the AST interpreter Languages Interoperability (Polyglot) The truffle framework provides a Polyglot engine that allows languages developers to register their languages so they can be accessed by other Truffle guest languages [19]. This allows users of such languages to be able to combine different languages when writing source code. As a result, developers (end users of the language) can choose a suitable language for a given problem without the need to change the programming language for the whole project [19]. 24

25 On the other hand, languages developers can also benefit from polyglot services of the framework. Languages can share implementations of features and break the boundary of limitations those languages have [4] The Graal Compiler The implementation of the AST interpreter on Truffle can be hosted on any JVM since it is in pure Java. Nevertheless, such JVMs do not provide the API to their dynamic compilers to support features such as custom compilation, static analysis or partial evaluation. To support these features, Truffle projects are normally hosted on a Graal VM. This is a modified version of standard JVM that uses the Graal compiler as its dynamic compiler and provides API to access such compiler [20]. The Graal compiler is a high performing Just-in-Time (JIT) optimizing compiler developed in Java for the Java hotspot VM. The following sub-sections provides an overview of some of the features available when working with the Graal compiler Speculative Optimisation Speculative optimisation is done by aggressively optimise a piece of code depending only on assumptions and profiling information collected by the VM [20]. One such assumption is if a class is loaded and there is a call to a method from another class. At that time the compiler assumes that the method is only implemented in there and so it generates compiled code and inline into the caller method s code. If later the method is overridden by another inheriting class, then the compiled code is discarded and the methods (both original and overriding) are recompiled without in-lining [20]. Another technique supported by the Graal compiler is partial evaluation of ASTs to produce efficient machine code [21]. During interpretation, the AST interpreter uses partial evaluation to produce interpreted code of the AST branch it is interpreting. The evaluation starts by compiling the execute method of the root node, and inline all the children execute methods. When the Graal compiler compiles a branch, it performed automatic partial evaluation and, if the rewriting is not required, produces optimised machine code. To produce optimised code, the compiler modifies the code to perform method in-lining, escape analysis, loops optimisation and also removing nodes information related to specialisation, which are not needed anymore at this stage [4]. For branches that require rewriting, the Graal compiler decompile them back to the AST for further rewriting. The node information related to profiling data, frequency details and the current state of the node are used for rewriting the node into a new more specialized node. 25

26 Graal API and Dynamic Class Loader The Graal API provides interface for accessing classes, methods and their signatures, instance variables, constant pools and all other necessary data available in a class file. The API also provides interface to access compiled code information such as machine code bytes, cached data, garbage collection pointers and de-optimisation details [20]. The availability of the API allows Truffle applications to do custom compilation and support features such as adding specific optimisation phase, partial evaluation and custom in-lining [20]. As in any other JVM, classes are loaded and initialised as late as possible [7]. This allows the VM to only load classes that are needed in the current execution and avoid loading unused classes. When Graal is used as a JIT, class loading and linking is done by an interpreter. This allows possibilities for de-optimisation and returning execution to the interpreter [20]. On the other hand, when Graal is used for static analysis, class loading can be done by the compiler Graph-Based Intermediate Representation The Graal compiler uses directed graph to represent its Intermediate Representation (IR) [22]. The graph includes nodes representing opcodes, Java fields, start and end of blocks, guards and de-optimisation safe points. Edges of the graph represents data and control flow between nodes. Languages developers can use graph visualizer to visualise optimisation phases taken by the Graal compiler. Other features provided by the Graal VM includes memory optimisation, register allocation and code generation [10] Scanning, Parsing and AST Interpretation with the Truffle Framework To host a guest language on the JVM using the Truffle framework, a developer has to provide a scanner for reading the source file. The main duty of the scanner is to perform lexical analysis part of the compilation process. This is the process of reading sequence of characters from a source file and organize them into meaningful tokens [23]. These tokens are then feed to the parser for further processing. Then a parser has to be developed that checks the syntax of the parsed tokens and if the syntax is correct, generates an AST for the interpreter [23]. An AST provides the structure of the source code in a tree format. The Truffle framework provides a freedom for developers to 26

27 provide any implementation of their choice for the parser and scanner. Although, the parser has to produce an AST that is understood by the Truffle implementation of the AST interpreter. Furthermore, the developer provides the AST interpreter, which is a way to describe the semantic of the guest language [9]. For the interpreter, developer implements semantic features such as types definition, type checking and node implementation for each operation available in a guest language. Each node implementation provides a mechanism to execute its operation, and for block related nodes, a frame to store and access local variables of that block. Figure 2-9 shows a detailed system structure of the project implemented with the Truffle framework. The DEX files This project implementation Figure 2-9: Detailed system structure of the Truffle implementation (Image source: [4] ) Related Work There have been many projects focusing on optimising Android applications. Most of those projects focus on optimising bytecodes to reduce unnecessary instructions. On the other hand, Truffle is a research framework. Although there have been many languages already implemented on top such as Ruby, Python, R and JavaScript, there is currently only one implementation of static typed language or bytecode level parsing. This section discusses two projects that closely related to the focus of this thesis Redex Bytecode Optimiser Facebook Inc. developed in 2015 a software framework, Redex, for reading, writing, analysing and optimising Android bytecodes [24]. The framework is written in C++ and was released as open source in April 2016 [25]. The framework helps developers to transform Android DEX 27

28 files and produce better performing Android applications. The following are some of the transformation techniques applied by Redex to reduce the size of DEX files [26]. Minification and Compression This technique involves reducing and minimizing strings size used by identifiers (for method and field names), class paths and file paths without changing the overall functionality. Since long string takes up many bytes in DEX bytecode, this technique saves up bytes that were dedicated for string in the original DEX file. Code Inlining Another technique used in Redex to optimise bytecode is moving functionality of a called method to the body of its caller. This reduces overhead introduced by method calls and possibly could reduce bytecode size. Dead Code Elimination Another technique applied by the Redex framework is elimination of all unreachable code. Although this is a common technique in optimisation process, it is still possible for original DEX files to contain dead code. Optimised DEX files generated by the Redex framework are aimed to be packaged in Android Packages (APK) and run by the Dalvik VM or ART. In contrast, this project aims to execute DEX files on JVMs. To accomplish this, this project focuses on the development of an AST interpreter built on top of the Truffle framework and the Graal VM. The project transforms Android applications to produce applications that can be hosted by JVMs LLVM IR Interpreter (Sulong) Among the projects that were developed with the Truffle and Graal frameworks, Sulong [27] is the one that is closely related to the implementation details of this project. Sulong is a Low Level Virtual Machine Intermediate Representation (LLVM IR) interpreter developed with the Truffle and Graal frameworks. Languages that can be compiled with LLVM compiler infrastructures [28] such as C, C++ and Fortran [29] can use Sulong as their dynamic runtime for their IR when running on the JVM. 28

29 LLVM-based languages could be compiled to LLVM IR bitcode, using an LLVM front-end such as Clang [30], and then be hosted on the JVM using Sulong. The bitcode instructions in LLVM IR are register-based [31] as the one in Android bytecode. The example code from Figure 2-3 can be represented as LLVM IR as shown in Figure %1 = alloca i32, align 4 %num1 = alloca i32, align 4 %num2 = alloca i32, align 4 %sum = alloca i32, align 4 store i32 0, i32* %1 store i32 15, i32* %num1, align 4 store i32 30, i32* %num2, align 4 %2 = load i32* %num1, align 4 %3 = load i32* %num2, align 4 %4 = add nsw i32 %2, %3 store i32 %4, i32* %sum, align 4 Figure 2-10: LLVM IR representation of simple addition. Although LLVM IR is more low level and closer to the machine code, the technique to parse it is closely related to the Android bytecode. Nevertheless, while Sulong focuses on the generalized LLVM instructions, this project focuses on specialized set of instructions used by the Android platform Summary This chapter presented the literature information needed for undertaking this project in the wide context of Android system and virtual machines in general. The chapter discussed bytecodes and how they are put together in an application. The chapter also discussed different types of virtual machines and how register-based machines bytecodes are organised. At the end of the chapter closely related projects were discussed and relation their relations to this project were presented. 29

30 Chapter 3. Methodology and System Design 3.1 Introduction This chapter presents a detailed explanation of the design of the proposed system and the methodology used during the development process. In details, the chapter discusses design decisions taken while putting together different components of the system. Section 3.2 discusses the methodology that was used during different phases of the project. Furthermore, Section 3.3 discusses the development environment tools and libraries necessary for the development and evaluation phases of the project. Section 3.4 presents the detailed architecture of the system and the design of different components is discussed. A discussion about design assumptions is also presented in Section Methodology To accomplish the aims and objectives presented in Section 1.3, an incremental approach was used in which phases of the project were executed iteratively. The following sub-sections discuss the methodology during different phases involved in this project Research and Familiarisation with the Truffle Framework The first iterations focused on researching and understanding tools and different technologies involved in the development of this project. Together with the literature survey, this phase was used to study and understand simple language construction with the Truffle framework. The objective was to understand how a simple language can be developed on Truffle and identify issues and difficulties that could rise when working with the Truffle framework Understanding the Dalvik Executable Format (DEX) Next phase of the project involved a study to understand DEX opcode and their usage. This includes identifying different opcodes, their hexadecimal presentation, mnemonic representation and their relationship to the original Java constructs. The objective of this phase was to understand the DEX hexadecimal format and be able to build a simple scanner and parser for the format. 30

31 3.2.3 Building DEX AST Interpreter with the Truffle Framework This phase involved design and implementation of the project. A general design of the project was developed followed by building a simple interpreter for simple DEX files. Iteratively, more DEX functionality and features were developed and added. Together with the AST interpreter, test cases were built to complement the development process of the interpreter. Section 3.4 discusses the design decision taken while Chapter 4 presents the details of the implementation of the project Benchmarking, Optimisation and Evaluation The aim of this phase is to validate the correctness of the implementation and compare benchmark results with other Android runtimes. To evaluate the correctness of the implementation, the project uses standard benchmark test suites for validation and benchmark. The detail on benchmarks used together with the results is discussed in Chapter Development Environment This section discusses tools and resources that made the development environment of this project. Operating System: GNU/Linux is the chosen platform for this project, as it provides most of the necessary tools and also support most of the custom tools developed by the Truffle team. Ubuntu is used as the development operating system. Programming Language: Java is the main programming language of the project. Version 7 and 8 of the JDK are used as required by the Truffle and Graal frameworks. Framework: The Truffle framework is used to implement the AST interpreter [8]. Execution VM: The Graal VM is used to run the implemented project, as the Truffle project performs better when hosted on the Graal VM instead of other JVMs [8]. IDE: Eclipse IDE is used as an Integrated Development Environment to simplify writing, debugging and testing of the source code. Android Applications: Android SDK is used to generate input files as it contains tools necessary to produce DEX files from Java source code. All sample DEX files, together with the benchmark test suites used in this project were constructed using API level 23 of the Android 6.0 (Marshmallow) [32]. 31