Background

In order to enable vertical profiling on the Android platform, this thesis made modifications to Dalvik Virtual Machine and Oprofile‟s driver inside Android‟s Linux kernel. Sub-section 1 will go over the unique features of Android and DVM. Sub-section 2 will introduce Oprofile.

2.1.1 Android Platform

Android is primarily a mobile platform. It presently runs on several iterations of ARM and Intel architectures, including single-core and multi-core architectures with varies memory hierarchies. Android platform is built on top of a Linux kernel. In the pursuit of making the system more suitable for mobile devices, many modifications are made to the system, including changes to the basic Linux system libraries, such as libc and ptrace.

The basic Android framework is shown in Figure 1. Linux kernel and drivers are the foundation of Android framework and directly interact with the hardware. Android runtime is built as a part of the Linux system libraries which consists of the Dalvik Virtual Machine and other libraries that manages DVM thread creation and Inter-Process Communication [21, 22].

7

Although Dalvik Virtual Machine is a modified Java Virtual Machine, unlike most JVM stack machines, DVM implements a register-based design. A register-based machine uses fewer instructions, but since each instruction is longer, it also has larger code size compared to the stack machines. Aiming to reduce code size, Android redesigned the packaging format to share common code and constants between class files. The resulted dex format typically produces files less than half the size of the same code in the uncompressed JAR format [23].

Application framework is a special Dalvik application which contains android system services, such as telephony manager, activity manager and windows manager. The rest of the applications interact with the basic systems through this application framework.

Android user interfaces such as the home screen, telephone dialer and browser are all Dalvik applications.

Android

Linux Kernel

Libraries Android Runtime

Dalvik VM Core Libraries Application Framework

Application

libc opengl

drivers

Figure 1. Android architecture.

During the initiation of new Android applications, a new Dalvik virtual machine is

8

created for each instance, as shown in Figure 2 [24]. A process called Zygote monitors the application initiation and forks it into a new thread when it is ready. Thus, modifications for the virtual machine event-based instrumentation should focus on Zygote and the Dalvik virtual machine. Traditionally, the more important events would be Zygote forking a new thread, Dalvik virtual machine undergoing method creation or garbage collection, new frames being pushed or popped on the thread stack, and other memory related events.

DAEMON PROCESSES

RUNTIME ZYGOTE SYSTEM

SERVER

HOME TEST APP

libc libc libc libc libc libc

daemonsdaemonsdaemons runtime zygote

Oprofile utilizes hardware performance counters of different architectures to sample both user-space and kernel-space usage data. Using Oprofile, developers can avoid dramatically

9

affecting accuracy by adjusting sampling frequency to minimize overhead. At the same time using hardware counters further reduces overhead [25].

Android Platform

Figure 3. Profiling flow of Oprofile provided by the Android source code.

The most recent official Oprofile release includes a JIT extension which provides several tools to relay information of JIT‟s dynamic compiled code from a compatible Java virtual machine to the kernel. However, due to the design differences between Java virtual

10

machines and Dalvik virtual machine, the implementation is not functional on Android. It is also not included in the version of Oprofile that comes with Android source code.

Figure 3 illustrates the profiling flow of the Oprofile version included in Android source code. To initiate profiling, Opcontrol first setups sampling frequency and assigns hardware performance counters of interest ○1 . Opcontrol then initiates the Oprofile daemon and sampling begins. Oprofile daemon will halt the system for a short period to empty and process sampled data in the event buffer when the buffer is almost full ○2 .

After retrieving sample data, Oprofile daemon looks up symbol information using the sample VMA, if a symbol is not found at this time, there will be another symbol look-up during post-processing ○3 .

Oprofiled then saves the found symbols into the log files in ○4 . Once the profiling session is complete, logs are retrieved by the control computer. Post-processing tools such as Opreport will interpret the data and output results ○5 .

Table 1. Visible layers of performance analysis tools on Android.

Visible Layer Dalvik and application Native code and libraries Kernel and drivers Traceview [14] Application and DVM logs

DDSM [25] DVM profiling and trace

Logcat [13] Application logs through activity manager

If Java application logs native functions or libraries

calls, then there will be limited information

Gprof [5] Native code and library

profiling

LTTng [15] User space tracing tool Kernel space tracing tool

Ltrace [17] Trace for library calls Traces system calls

Strace [16] System call tracing tool

that uses ptrace

Oprofile [4] Profiling with PMU Profiling with PMU

This Work Profiling with PMU Profiling with PMU Profiling with PMU

Presently, Oprofile can not correlate native code, Linux libraries or kernel space events with Dalvik application events. Moreover, the JIT extension tools have not been integrated

11

into DVM, nor does Android source code include the JIT extension tools. There are other performance analysis tools that Android provides in its source code, as shown in Table 1.

They all specialize in providing information for one or two layers in the Android architecture, but none of them can bridge the information gap created by the virtual machine.