Design and implementation of a Java execution environment for digital TV settop

Transcription

1 Design and implementation of a Java execution environment for digital TV settop boxes. Wolfgang Betz Senior System Engineer STMicroelectronics Srl - Advanced System Technology Via C. Olivetti, Agrate Brianza (MI) - Italy wolfgang.betz@st.com Ivan Cibrario Bertolotti Researcher IEEE Computer Society member # IRITI - National Research Council c/o IEN "Galileo Ferraris" Strada delle Cacce, Torino - Italy cibrario@cstv.to.cnr.it Abstract This paper discusses the design and implementation of a Java execution environment (Java Virtual Machine and a selected subset of its associated core packages) targeted to embedded systems and, in particular, to set-top boxes for MPEG-2 digital TV reception. Java bytecode offers a viable way of conveying executable contents to the end-user of the digital TV broadcasting service. In addition, it features a set of highly desirable properties, such as guaranteed interoperability, full independency from the executing hardware platform, a robust security model to block potential intruders, and wide availability of sophisticated code development and test suites. 1 Introduction The main goals of our project were the development of a prototype software platform for a new generation of set-top boxes based on the Java technology (Java STB); the supporting hardware platform features the well-known Sti5500 ASIC by STMicroelectronics. We then used the prototype to perform profiling and benchmarking, and a realistic simulation of foreseen services and applications based on Java. In order to do this, the core Java Virtual Machine (JVM) was derived, under non-commercial license, from the Java Development Kit provided by Sun, and then complemented with a custom micro kernel. The graphics subsystem was rooted on a port of the MIT X Window System (XWS), with special adaptations to enhance its performance for local client-server connections; the networking subsystem leverages an existing implementation of TCP/IP. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. 1

2 2 Internal Structure of the Java execution environment Figure 1 shows the internal structure of the Java [1], [2] execution environment. The Sun's Java Development Kit (JDK) runtime system version we used as a starting point for our port is written in ANSI C, with a platform abstraction boundary dividing the platformindependent portion of the code (upper layers) from the platform-dependent one. Java Applications and Applets SW Java Runtime System (Kernel, Interpreter, Class Loader, Bytecode Verifier) Java Packages (java.lang, java.io, java.util,...) Native Methods (Static Lib's) OS20 / ChorusOS / WinCE (plus subsystems for graphics and networking) Digital Video Decoder OMEGA / ORION Digital TV, and Interactive Services Network Figure 1, Internal Structure of the Java Environment Porting this kind of execution environment on a new platform is always feasible, but its difficulty depends on how well the target platform meets the basic requirements imposed by the platform abstraction boundary: mainly, the platform-dependent code must provide POSIX c support for multithreading and thread synchronization, with respect to both ANSI C library functions and Java language concepts such as monitors. For our port we used the existing OS20 multitasking micro kernel with custom modifications to extend its thread model and achieve POSIX compliance. Thread-safeness for C library functions was realized using a mutual exclusion adaptation layer. This solution achieves a very good context switch performance, because the target CPU implements most basic activities associated with context switches in microcode, thus keeping the micro kernel overheads very small. Both the bulk of the Java Runtime System, and the portion of Java Packages written in Java are inherently platform-independent and did not require porting. 3 Graphics subsystem The graphics subsystem has its roots on a port of a subset of the MIT XWS [3]; the Tiny AWT Java package provided with the JDK is able to directly leverage it to implement java.awt without any modification. Like the JDK mentioned before, the XWS has a layered internal structure; the main platformdependent components requiring adaptations are [4], [5], [6]: Operating system interface layer: it implements system initialization, memory management, error handling, client scheduling and X requests delivery, and yield control. In addition, it manages client connection and all data transfers between the X server and its clients. 2

3 Input devices interface layer: it initializes and controls all input devices connected to the X server; in addition, it gathers and processes all events generated by these devices. Output device interface layer: it performs region, cursor, and color map handling; moreover, it performs font realization and implements all basic drawing primitives. In the output device interface layer the dividing point between platform-independent code (already available) and platform-dependent code (to be developed) can be moved almost freely. This allows the developer to choose the best compromise between development effort and efficiency. We chose to reuse the platform-independent code as much as possible to lower development efforts: efficiency was not impacted in this case, because Java only uses a small subset of the XWS capabilities and we did not optimize functions that are either rarely or never invoked anyway. The XWS heavily relies on Inter-Process Communication (IPC) to perform its duties; the TCP/IP protocol provided by the networking subsystem could be used for this but, for performance reasons, we implemented and added support for an additional, highly simplified, transport protocol for local connections, to avoid TCP/IP overheads, such as those related to message fragmentation, reassembly and check summing when they are not strictly needed. This rather simple, focused optimization gave us an average performance gain of 2.6 on the x11perf XWS benchmark, of about 1.7 on the Graphics test of the CaffeineMark benchmark, and of about 1.1 on the Images test, same benchmark. In the latter case the gain is smaller because the test process mostly requires CPU power and only a small amout of IPC. Additional information about the X Window System porting process can be found in [7]. 4 Networking subsystem The networking subsystem leverages an already available implementation of TCP/IP and required little work to be ported. Mainly, we developed a custom device driver for one of the asynchronous serial interfaces of the Sti5500 and used the existing software to implement a PPP link on it; a workstation is used on the other side of the link to route the set-top box traffic into Internet. The prototype set-top box makes use of the serial link to carry both incoming and outgoing TCP traffic; a real one would use the digital TV channel to carry incoming traffic, instead, because its bandwidth is higher. 5 Footprint and Performance Table 1 shows the static memory footprint of the main components of the prototype JVM, that is, the amount of memory needed to load them. Dynamic footprint, that is, the amount of memory needed to actually run a given Java application, is of course application-dependent: for example, the demo described in section 6 needs about 4 Mbytes of memory. We think that most Java applications conceived to run on set-top boxes will show similar figures. Component Size [Kbyte] Basic JVM interpreter 310 Networking 200 Graphics subsystem

4 Java classes 1500 Table 1, JVM Static Footprint Table 2 shows the results of the Embedded CaffeineMark 3.0 benchmark run on the following hardware platforms: STi5500, 4 Kbyte cache, 50 MHz CPU clock, ~12 MIPS, our platform UltraSparc-1, 512 Kbyte cache, 167 MHz CPU clock, ~198 MIPS, for reference We can see that, while the CPU MIPS ratio of the Sti5500 versus the UltraSparc-1 is 12/ , the JVM performance ratio is consistently higher for all test classes except Float. The rather poor performance of our platform when performing the Float test is easy to explain because the Sti5500 does not have a floating-point coprocessor. Platform Sieve Loop Logic String Float Method Overall Sti5500, C-interpreter UltraSparc, C-interpreter UltraSparc, Asm-interpreter UltraSparc, JIT-compiler Performance ratio: STi5500 versus UltraSparc, C-interpreter Normalized performance ratio Table 2, JVM Performance 6 Demo Environment To test out our Java implementation we set up a simple demo environment, depicted in Figure 2; it implements a set-top box web browser suitable to be a graphical user interface for remote services. A dedicated proxy server performs web contents pre-processing and filtering; both the browser (client side) and the proxy (server side) application are written in Java. The browser supports dynamic downloading and execution of Java applets. The Host machine is used to initialize the set-top box, to boot it, and to trace and profile the code execution as it takes place. 4

5 Figure 2, Demo Environment Structure 7 Conclusions We were able to demonstrate that a small team with limited time and resources can successfully implement an embedded Java execution environment as described above; we leveraged publicly available software as much as possible, to lower implementation efforts, and put in effect focused platform-dependent optimizations to avoid sacrificing performance. This turned out to be a major issue, because the Java environment was originally designed to be implemented on either personal computers or workstations, and both of them have at least an order of magnitude advantage in terms of both raw CPU speed and memory size with respect to an average set-top box. Both measured performance and footprint shown in section 5 compare favorably with respect to other existing implementations on either personal computers or workstations and, in particular, the resource needs of the Java execution environment have been found to be compatible with the design constraints imposed by a low-cost set-top box. However, mainly due to the limited resources available, our prototype still has some restrictions and missing features with respect to a real-world product; in particular, the networking subsystem lacks support for multicast and dynamic host name/address resolution protocols, such as DNS, the graphics subsystem has limited font support, and the traditional digital TV software infrastructure is not fully integrated with the Java environment. Foreseen future work includes the implementation of either an ahead-of-time or a just-in-time compiler to enhance the speed of Java bytecode execution, further improvements to the performance of the graphics subsystem, and full integration of the Java execution environment with the existing digital TV software infrastructure. 8 Acknowledgments This work was partly funded by the EEC MEDEA research project A101; MEDEA (Micro- Electronics Development for European Applications) is part of the pan-european EUREKA network for industrial R&D (EUREKA Project E! 1535). 5

6 References [1] Lindholm, T. and Yellin, F. (1997) The Java Virtual Machine Specification. Addison- Wesley [2] Gosling, J., Joy, B. and Steele, G. (1996) The Java Language Specification. Addison- Wesley [3] Scheifler, R. W. and Gettys, J. (1992) X Window System, 3 rd edition. Digital Press [4] MIT X Consortium staff (1991) X Window System, Version 11, Release 5 Release notes. X11R5 documentation package [5] Rosenthal, D. S. H. et al. (1988) Godzilla s Guide to Porting the X v11 Sample Server. X11R5 documentation package [6] Angebranndt, S. et al. (1988) Strategies for Porting the X v11 Sample Server. X11R5 documentation package [7] Cibrario Bertolotti, I. (1999) Internal Structure of a Generic X Server. CSTV-CNR Technical report