CSE 237A Final Project

Jeremy Luchau – A50035078

A Java Implementation on the Xscale Platform Java has become one of the most widely used object-oriented programming languages. The write once, run anywhere portability of Java makes it an attractive alternative to C for applications designed to run on a variety of platforms. Despite initial shortcomings, Java is gaining popularity on embedded devices due to its reusability and network security features. My final project involved finding and configuring a suitable Java Virtual Machine (JVM) for use on an Xscale platform running Linux. After configuring the open-source JVM on the mobile platform I created a simple commandline user interface to demonstrate one possible implementation of Java on an embedded device. I also examined the possibility of extending the user interface with graphical components but time constraints prevented the successful implementation of a GUI. The performance overhead associated with running a virtual machine on the ARM processor was analyzed and shown to be a minimal drain on system resources for peripheral functions. Application calls with a heavy instruction loads performed worse, indicating that Java may be better suited for multimedia and web applications than scientific or resource-intensive operations. Java was first developed in 1995 by Sun Microsystems. Though Java was designed to mimic the familiar C/C++ syntax, there are many differences between the two object-oriented languages. Java employs stricter type-checking and abstracts many low-level system functions that must be explicitly stated in C. For example, rather than specifically de-allocating memory, Java performs memory management automatically through garbage collection that frees blocks no longer in use by the program. Another important aspect of Java is that it makes use of a virtual machine that provides a level of abstraction between the compiled code and native assembly required to execute programs on a given architecture. These abstractions enable the portability that has helped make Java popular but also come with performance trade-offs. The interpreted nature of Java code causes it to execute slower in most cases than comparable native binaries. In the past, slower performance made Java a poor choice for embedded devices where applications had hard real-time execution requirements and limited resources to achieve them with. Additionally, it was undesirable to surrender key operation tasks to a virtual machine that could potentially schedule them at any point in the execution. For example, an ill-timed garbage collection routine could easily cause a critical real-time deadline to be missed. The potential benefit of Java, application portability, was typically not a concern in embedded devices since software was usually tailored for a single task and tuned for the minimal hardware of the device. Recent years have seen improvements in the execution speed of Java Virtual Machines that have nearly eliminated the performance gap. Embedded devices have also experienced an improvement in computing power and moved from the realm of hardware-specific applications to general computing. Modern cell phones and PDAs provide many of the same services that desktop machines do: web browsing, e-mail, games, etc... Developers wishing to create general applications for a variety of mobile platforms have turned to Java as an implementation option. This project is designed as a case study to examine one such possible implementation.

The key aspect of any Java implementation is the virtual machine that interprets the class code for execution. The compiled code is converted to assembly instructions on-the-fly, making it possible to execute the same binaries on different platforms running hardware-specific JVMs. Sun Microsystems has a variety of free JVM’s available, covering the majority of PC environments currently in use. Sun also offers a Java Micro Edition implementation for embedded devices, but this JVM is only made freely available on a trial basis. For this reason I turned to open-source JVMs for use in this project. Though they are not licensed by Sun and cannot be referred to as official Java products, most of the open-source JVMs available support the same API offered by the Sun Java development kits. The first virtual machine that I attempted to configure for the ARM-Linux environment was Kaffe [2]. Kaffe is one of the most widely used open-source JVMs with no dependencies on Sun software. Kaffe requires a number of shared libraries to work properly, each of which had to be downloaded and cross-compiled for use on the Xscale. The most important of these libraries is GNU Classpath, a free implementation of the core Java class libraries necessary for JVM execution [6]. I was able to successfully download and cross-compile Classpath for ARM-Linux. Another shared library required by Kaffe is zzliplib, a utility for unzipping jar and zip files used to store Java class files [7]. Unfortunately, the configure utility provided with zziplib did not offer an option for cross-compilation. I was able to configure it for use on the host machine, but unless the binaries were cross-compiled they would be useless for any programs running on the Xscale. Because of this limitation I decided to turn to a second virtual machine called JAM. JAM is also a free open-source JVM with an extremely small footprint (about 200K) designed specifically for embedded systems [3]. Unlike other small JVMs, JAM supports the full Java specification. JAM also makes use of the GNU Classpath core libraries which I had already downloaded and configured. After experimenting with several possible JAM configurations I was able to find one that ran a simple “Hello World” Java application on the Xscale. JAM had a similar issue with a shared archiving library, but I was able to disable the zip features within it. The only limitation of this is that all class files for my application must be unpacked. Since I was running my program from a mounted directory on the host machine this did not prove to be an issue. In order to compile my programs I also had to download and install Sun’s standard development kit for Java. Now that I had a compiler and successful JVM implementation it was time to turn to developing a sample Java application. As mentioned previously, Java in now being used in a variety of embedded devices and related projects. I gathered background information on a number of these projects to determine an appropriate sample application. Android is one such project that aims to create the first complete, open and free mobile platform [5]. Android provides a standard software environment including an operating system, middleware and key mobile applications (e-mail, browser, etc…). The platform allows developers to write applications in Java and run them on multiple mobile devices. Programs are interpreted by the platform’s Dalvik Virtual Machine, a VM optimized for embedded systems. Similar to my implementation, Andriod makes use of a Linux kernel for core system services like memory and process management. The first Android device, the T-Mobile G1, was released earlier this year. The standardized Android framework is useful for

creating a variety of complex interface applications for use on multiple embedded systems. The key characteristic of each of the Android applications is that they are not hardware-specific and are designed to run on any device supporting the Android architecture. I decided to create a simple user interface using my implementation of Java on Xscale to demonstrate a similar extension of code portability. The Java-based user interface that I created allows for basic command-line input to activate a number of functions on the Xscale. The commands implemented on the UI and their underlying implementation details are as follows: UI Command Help List Sync

Play Picture Sleep

Calc

Purpose Provide the list of acceptable commands (similar to this table) List all media files available

Implementation Print command details to standard output

Run directory listing to print contents of predefined media folder Synchronize media files Simulate synchronization with a host machine by copying files from a folder on the host to the media folder in the mount location Play the specified media file Run mplayer software for media file playback Capture an image on the Run ci-capture Xscale display Place the device in a lowRun “dvfm 8 2 1 2 1” to power state until interrupted place device in low-power by a keystroke mode followed by “dvfm 16 6 1 2 1” after keystroke to return to standard voltage and frequency Simulate calculator Perform a series of 10M functions (used for addition operations on performance testing) floating-point or integer numbers

The above set of options was chosen specifically because they are common commands that one may wish to execute on any mobile device. Ideally each of these functions would be coded purely in Java using a standard API (like the one provided by Android) to make the code portable across multiple systems. Since there was no such standard platform available for the Xscale my implementation made use of both Java code and Linux shell scripting. The command-line prompts and execution logic are written in Java, while function calls specific to the Xscale (like ci-capture) are implemented in shell scripts activated from the code. The same code binary was also tested successfully on the host machine, but as expected, any calls to the native scripts did not function since the PC does not support them. To use the same code on another embedded platform with

different implementation requirements we would replace the low-level shell script commands with those used by the given device. The primary difference between my interface and one that you would commonly find on a consumer mobile device is the lack of graphical components. I did create a simple GUI using the javax.swing components to test with JAM on the Xscale. In order to use these components, however, the GTK+ shared library first needed to be crosscompiled and installed. GTK+ is a standard library for displaying graphical user interface components like buttons, labels and text boxes [8]. GTK+ itself also requires two shared libraries: Glib and Pango. Glib provides some of the core library functions needed by GTK+, while Pango provides for the layout and rendering of text on the GUI components. Glib proved particularly challenging to cross-compile, as suggested by the documentation on their web site [9]: “GLib is slightly more difficult to cross-compile than many packages because much of GLib is about hiding differences between different systems.” Glib requires a cache file to be created prior to cross-compilation that provides many of the specific hardware details of the device. I was unable to find a suitable configuration of cache file variables to run the GUI on the Xscale. Though time constraints prevented me from implementing them it is important to note that GUI components have indeed been used by a variety of Java applications on mobile consumer devices. The performance overhead associated with running the Java virtual machine on the Xscale proved to be negligible for function calls that make use of the peripheral devices, like image capture and media playback. Whenever an instance of the user interface is activated six concurrent threads are shown running in the Linux TOP report. While the interface is active and awaiting user input each of these threads show no CPU utilization or overhead. Executing a picture or playback of a media file also shows minimal CPU usage by the virtual machine, less than 1% in each case. However, executing commands with higher instruction counts results in much higher CPU usage. The calc command that I created executes a series of ten million floating point or integer additions, depending on the parameter passed to the UI. In the case of integer addition, the JAM virtual machine reached 50% CPU utilization. Floating point operations, which are simulated on the Xscale integer hardware, took longer for the same number of iterations and reached nearly 100% CPU utilization. These results are in line with what we would expect, since higher instruction counts mean more lines of compiled code that need to be interpreted by the VM for execution and therefore higher CPU utilization and overhead. The results of this project showed that Java could in fact be implemented on an embedded device, but more importantly provided some insight as to which types of applications it is best suited for. Scientific applications with resource-intensive operations or code with hard real-time requirements are not ideal candidates for Java. However, general-purpose mobile web applications, gaming and multimedia each have potential uses for the programming language. The portable nature of Java makes it an ideal implementation option for developers wishing to reach a multitude of embedded devices with their software. To make these applications truly portable, however, a standardized framework that abstracts low-level function calls will still be necessary. Competition between manufacturers may make this unlikely but open handset projects like Android provide for an interesting framework and future potential.

References 1. Java.net. “The Source for Java Technology Collaboration” 2008. http://www.java.net/ 2. Pick, J. “Kaffe.org” 2008. http://kaffe.org/ 3. Lougher, R. “JamVM” 2008. http://jamvm.sourceforge.net/ 4. Sun Developer Network (SDN). “The Source for Java Developers” 2008 http://java.sun.com/ 5. Open Handset Alliance. “Android” 2008. http://code.google.com/android/ 6. Free Software Foundation (FSF). “GNU Classpath – GNU Project.” 2008. http://www.gnu.org/software/classpath/ 7. zZIPlib. “The Library” 2003 http://zziplib.sourceforge.net/ 8. The GTK+ Team. “GTK+ Library” 2008. http://www.gtk.org/ 9. Gnome Documentation Library. “Glib” 2008. http://library.gnome.org/devel/glib/unstable/glib-cross-compiling.html 10. Shrestha, S. 2007. Mobile web browsing: usability study. In Proceedings of the 4th international Conference on Mobile Technology, Applications, and Systems and the 1st international Symposium on Computer Human interaction in Mobile Technology (Singapore, September 10 - 12, 2007). Mobility '07. ACM, New York, NY, 187-194. 11. Ringland, S. P. and Scahill, F. J. 2003. Multimodality — The Future of the Wireless User Interface. BT Technology Journal 21, 3 (Aug. 2003), 181-191. 12. Nichols, J., Hua, Z., and Barton, J. 2008. Highlight: a system for creating and deploying mobile web applications. In Proceedings of the 21st Annual ACM Symposium on User interface Software and Technology (Monterey, CA, USA, October 19 - 22, 2008). UIST '08. ACM, New York, NY, 249-258. 13. Google. “Gears API” 2008. http://code.google.com/apis/gears/ 14. Zhang, D. 2007. Web content adaptation for mobile handheld devices. Commun. ACM 50, 2 (Feb. 2007), 75-79. 15. Mozilla Labs. “Introducing Geode.” 7 October 2008 http://labs.mozilla.com/2008/10/introducing-geode/ 16. Hayes, B. 2008. Cloud computing. Commun. ACM 51, 7 (Jul. 2008), 9-11.