CLDC HotSpot™ Implementation
                                    Architecture Guide

                           CLDC HotSp...
Copyright © 2006 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved.
S...
Contents


     Preface   xiii

1.   CLDC HotSpot Implementation Virtual Machine                1–1
     1.1   Processor a...
2.0.13   Integrated Class Prelinker        2–8
                          2.0.14   Fully Object-Oriented Internal Design an...
6.1   Introduction      6–1
           6.1.1   Isolates    6–2
                   6.1.1.1         Example Program         ...
8.3.2     Executing an Application Image                8–4
                          8.3.3     In-Place Execution Example...
Index   Index–1




                  Contents   vii
viii   CLDC HotSpot™ Implementation Architecture Guide • July 2006
Figures


FIGURE 1-1    Performance of Interpreted Mode Compared With Compiled Mode in CLDC HotSpot
              Implemen...
x   CLDC HotSpot™ Implementation Architecture Guide • July 2006
Code Samples


CODE EXAMPLE 5-1    Coding With the Non-Blocking Scheduling Style    5-4

CODE EXAMPLE 5-2    Coding a Pote...
xii   CLDC HotSpot™ Implementation Architecture Guide • July 2006
Preface

This book surveys the architecture of the Connected Limited Device Configuration
HotSpot™ implementation virtual ...
How This Book Is Organized
                  This book has the following chapters:
                  Chapter 1 is a genera...
Java technology-
            based code     (Java code)

     Java programming
    language debugger      (Java debugger)
...
The Java™ Virtual Machine Specification (Java Series), Second Edition by Tim Lindholm
                  and Frank Yellin (...
CHAPTER   1




              CLDC HotSpot Implementation
              Virtual Machine

              CLDC HotSpot Implem...
fit in small devices. In addition, it incorporates several design innovations that
                  enable the virtual ma...
1.1   Processor and Memory Requirements
      The first generation of Java technology-enabled mobile phones had processor ...
would be dramatically larger because compiled code requires more heap space.
                  CLDC HotSpot Implementation...
CHAPTER   2




              Technical Overview

              CLDC HotSpot Implementation is a high-performance alternat...
■   Dynamic native method support to allow adding optional packages after
                      manufacture
              ...
Incremental and Scheduled Compilation
        The maximum duration of any single compilation and the minimum time interval...
importantly, the virtual machine has complete control over all memory allocation
                  aspects of thread stack...
FIGURE 2-1   Relationship Between Instance, Near Class, and Class



        Field Packing
        In addition to the comp...
Another benefit of unified resource management is that compiled code can be
                  removed dynamically to free ...
2.0.9    Multitasking Support
         The Java programming language provides convenient language-level multithreading
   ...
2.0.11            Faster Application Startup With In-Place
                  Execution
                  If it is desired ...
To generate the ROMized image, the GenerateROMImage option must be set when
         running a virtual machine built in de...
■   Dynamic memory profiler. This tool allows the virtual machine to be paused and
                      a profile to be t...
2.2.2   Multiple Profile Support
        This feature allows building a system ROM image containing multiple profiles. The...
2.2.6             Interpreter-Only Mode
                  The availability of this build option helps a device manufacture...
CHAPTER   3




              Heap Architecture and
              Garbage Collection

              CLDC HotSpot Implement...
3.1.1             Structure of the Heap
                  The object heap is divided into old generation, new generation, ...
CHAPTER   4




              Dynamic Compiler

              Two different compilers are appropriate in the CLDC HotSpot ...
4.2               Tuning the Dynamic Compiler
                  Because the performance characteristics of small devices c...
CHAPTER   5




              Threading System

              This chapter provides an overview of the threading system in...
5.1               Long-Running Compared With Blocking
                  Native Methods
                  It is useful to d...
CHAPTER   6




              Multitasking

              This document describes the multitasking feature of the CLDC Hot...
6.1.1             Isolates
                  At the Java level, each separate running Java application within one virtual ...
CODE EXAMPLE 6-1 is an example of programming a new isolate. To run this example,
        put HelloMVM.class in HelloMVM.j...
As part of Sun Java Wireless Client, Sun Microsystems developed a MIDP
                  implementation that supports mult...
6.1.3   Reduced Isolate API
        As mentioned earlier, the CLDC HotSpot Implementation Isolate API is a stripped-
     ...
//where static_var_offset is calculated at class load time.
                  ■   Multitasking case
                      ...
6.2.3   Isolate Creation
        FIGURE 6-2 illustrates the overall process of creating a new isolate.




        FIGURE ...
6.2.4             Synchronization
                  This section discusses two kinds of synchronization that are handled b...
6.2.5.1   Scheduling and Priorities
          To prevent one task from taking a disproportionate amount of CPU time, CLDC
...
The CLDC HotSpot Implementation extensions for multitasking are located in the
                  package com.sun.cldc.isol...
CHAPTER   7




              Ahead-of-Time Compilation
              Support

              This chapter describes the ah...
larger than the original Java bytecodes. To save footprint, you can specify only a
                  subset of methods to ...
CHAPTER   8




              In-Place Execution

              This chapter describes in-place execution support in CLDC ...
system that cannot be modified by users or by untrusted applications. The
                  manufacturing processes by whi...
8.2.2   Warning Message
        The code provided in this implementation contains a special mechanism that is
        invo...
8.3.2             Executing an Application Image
                  No new API exists for executing an application image (....
8.5   Experimenting With In-Place Execution
      This section describes how to try the in-place execution features in CLD...
8-6   CLDC HotSpot™ Implementation Architecture Guide • July 2006
CHAPTER   9




              Jazelle Option for ARM
              Implementations

              This chapter describes J...
Notice to Sun’s Licensees – This confidential and proprietary software may be
                  used for evaluation or tes...
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Upcoming SlideShare
Loading in...5
×

Cldc Hotspot Architecture

2,157

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,157
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
46
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cldc Hotspot Architecture

  1. 1. CLDC HotSpot™ Implementation Architecture Guide CLDC HotSpot Implementation, Version 1.1.3 Java™ ME Platform Sun Microsystems, Inc. www.sun.com July 2006
  2. 2. Copyright © 2006 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved. Sun Microsystems, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed at http://www.sun.com/patents and one or more additional patents or pending patent applications in the U.S. and in other countries. Unpublished - rights reserved under the Copyright Laws of the United States. THIS PRODUCT CONTAINS CONFIDENTIAL INFORMATION AND TRADE SECRETS OF SUN MICROSYSTEMS, INC. USE, DISCLOSURE OR REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF SUN MICROSYSTEMS, INC. U.S. Government Rights - Commercial software. Government users are subject to the Sun Microsystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements. This distribution may include materials developed by third parties. Sun, Sun Microsystems, the Sun logo, Java, HotSpot, JDK, and the Java Coffee Cup logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Products covered by and information contained in this service manual are controlled by U.S. Export Control laws and may be subject to the export or import laws in other countries. Nuclear, missile, chemical biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited. Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited to, the denied persons and specially designated nationals lists is strictly prohibited. Copyright © 2006 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, Etats-Unis. Tous droits réservés. Sun Microsystems, Inc. a les droits de propriété intellectuels relatants à la technologie incorporée dans le produit qui est décrit dans ce document. En particulier, et sans la limitation, ces droits de propriété intellectuels peuvent inclure un ou plus des brevets américains énumérés à http://www.sun.com/patents et un ou les brevets plus supplémentaires ou les applications de brevet en attente dans les Etats - Unis et dans les autres pays. Non publie - droits réservés selon la législation des Etats-Unis sur le droit d’auteur. CE PRODUIT CONTIENT DES INFORMATIONS CONFIDENTIELLES ET DES SECRETS COMMERCIAUX DE SUN MICROSYSTEMS, INC. SON UTILISATION, SA DIVULGATION ET SA REPRODUCTION SONT INTERDITES SANS L AUTORISATION EXPRESSE, ECRITE ET PREALABLE DE SUN MICROSYSTEMS, INC. Cette distribution peut comprendre des composants développés par des tierces parties. Sun, Sun Microsystems, le logo Sun, Java, HotSpot, JDK, et le logo Java Coffee Cup sont des marques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays. Les produits qui font l'objet de ce manuel d'entretien et les informations qu'il contient sont regis par la législation américaine en matière de contrôle des exportations et peut être soumis à la règlementation en vigueur dans d'autres pays dans le domaine des exportations et importations. Les utilisations finales, ou utilisateurs finaux, pour des armes nucléaires,des missiles, des armes biologiques et chimiques ou du nucléaire maritime, directement ou indirectement, sont strictement interdites. Les exportations ou réexportations vers les pays sous embargo américain, ou vers des entités figurant sur les listes d'exclusion d'exportation américaines, y compris, mais de manière non exhaustive, la liste de personnes qui font objet d'un ordre de ne pas participer, d'une façon directe ou indirecte, aux exportations des produits ou des services qui sont régis par la législation américaine en matière de contrôle des exportations et la liste de ressortissants spécifiquement désignés, sont rigoureusement interdites.
  3. 3. Contents Preface xiii 1. CLDC HotSpot Implementation Virtual Machine 1–1 1.1 Processor and Memory Requirements 1–3 1.2 Compilation Performance 1–3 1.2.1 Faster Execution Consumes Less Power 1–4 2. Technical Overview 2–1 2.0.1 Portable Architecture 2–2 2.0.2 Dynamic Compiler 2–2 2.0.3 Optimized Interpreter 2–3 2.0.4 Lightweight Threading System 2–3 2.0.5 Compact Object Layout 2–4 2.0.6 Unified Resource Management 2–5 2.0.7 Generational Garbage Collection 2–6 2.0.8 Dedicated Heap Area for Compiled Code 2–6 2.0.9 Multitasking Support 2–7 2.0.10 Faster Virtual Machine Startup With Ahead-of-Time Compilation 2–7 2.0.11 Faster Application Startup With In-Place Execution 2–8 2.0.12 Fast Synchronization 2–8 iii
  4. 4. 2.0.13 Integrated Class Prelinker 2–8 2.0.14 Fully Object-Oriented Internal Design and Upwards Scalability 2–9 2.1 Additional Components 2–9 2.2 New Technical Features in This Release 2–10 2.2.1 In-Place Execution in Multitasking Mode 2–10 2.2.2 Multiple Profile Support 2–11 2.2.3 Dynamic Native Method Support 2–11 2.2.4 Vector Floating Point Support 2–11 2.2.5 Incremental JAR File Reader 2–11 2.2.6 Interpreter-Only Mode 2–12 2.2.7 Improved Debugger Support With Commercial IDEs 2–12 3. Heap Architecture and Garbage Collection 3–1 3.1 Garbage Collection 3–1 3.1.1 Structure of the Heap 3–2 3.1.2 Tracking Pointers Across Generations 3–2 3.1.3 Fast Allocation 3–2 4. Dynamic Compiler 4–1 4.1 Code Set Management 4–1 4.2 Tuning the Dynamic Compiler 4–2 5. Threading System 5–1 5.1 Long-Running Compared With Blocking Native Methods 5–1 5.2 Coding Styles for Long-Running Native Methods 5–2 5.3 Non-Blocking Scheduling Coding Style 5–3 5.4 Hybrid Threading Coding Style 5–5 6. Multitasking 6–1 iv CLDC HotSpot™ Implementation Architecture Guide • July 2006
  5. 5. 6.1 Introduction 6–1 6.1.1 Isolates 6–2 6.1.1.1 Example Program 6–2 6.1.2 Multitasking in MIDP 2.0 6–3 6.1.3 Reduced Isolate API 6–5 6.2 Isolate Implementation 6–5 6.2.1 Virtualization of Static Variables 6–5 6.2.2 Static Class Initialization 6–5 6.2.3 Isolate Creation 6–7 6.2.4 Synchronization 6–8 6.2.4.1 Synchronization of Java Classes 6–8 6.2.4.2 Synchronization of Interned String Objects 6–8 6.2.5 Resource Management 6–8 6.2.5.1 Scheduling and Priorities 6–9 6.2.5.2 Object Heap Sharing 6–9 6.2.6 JSR 121 6–9 7. Ahead-of-Time Compilation Support 7–1 7.1 Methods Eligible for AOT Compilation 7–1 7.2 Choosing Methods to AOT Compile 7–1 7.3 AOT Compilation of Downloaded Classes 7–2 8. In-Place Execution 8–1 8.1 Design Overview 8–1 8.2 Security Considerations 8–1 8.2.1 Storing Application Image Files 8–2 8.2.2 Warning Message 8–3 8.3 Integrating the In-Place Execution Feature 8–3 8.3.1 Running the Converter 8–3 Contents v
  6. 6. 8.3.2 Executing an Application Image 8–4 8.3.3 In-Place Execution Example 8–4 8.4 In-Place Execution from Flash 8–4 8.5 Experimenting With In-Place Execution 8–5 9. Jazelle Option for ARM Implementations 9–1 9.1 Flags to Enable Jazelle 9–1 10. ROMizer 10–1 10.1 Running the ROMizer 10–1 10.2 Requirement for System Classes 10–2 10.3 ROMizer Options 10–2 10.3.1 ROMizer Optimization Options 10–3 10.3.2 Example 10–8 10.4 Ahead-of-Time (AOT) Compilation 10–9 10.5 ROMizer Log File 10–10 11. Java Programming Language Debugging (KDWP) 11–1 11.1 KDWP Architecture 11–1 11.2 Debug Agent 11–3 11.2.1 Connections Between a Debugger and CLDC HotSpot Implementation 11–3 11.2.2 Packet Processing 11–5 11.3 Debugger Support 11–6 11.3.1 Events 11–6 11.3.2 Breakpoints 11–7 11.3.3 Single Stepping 11–7 11.4 Using the Debug Agent and the JPDA Debugger 11–8 11.4.1 Starting a Debug Session 11–8 11.4.2 Debugging Example 11–10 vi CLDC HotSpot™ Implementation Architecture Guide • July 2006
  7. 7. Index Index–1 Contents vii
  8. 8. viii CLDC HotSpot™ Implementation Architecture Guide • July 2006
  9. 9. Figures FIGURE 1-1 Performance of Interpreted Mode Compared With Compiled Mode in CLDC HotSpot Implementation 1–4 FIGURE 2-1 Relationship Between Instance, Near Class, and Class 2–5 FIGURE 3-1 The CLDC HotSpot Implementation Two-Generational Garbage Collector 3–1 FIGURE 6-1 Multiple Java Program Event Queues 6–4 FIGURE 6-2 Isolate Creation 6–7 FIGURE 11-1 Java Programming Language Debugging Interface Architecture 11–2 FIGURE 11-2 Debugger and CLDC HotSpot Implementation Connections 11–4 ix
  10. 10. x CLDC HotSpot™ Implementation Architecture Guide • July 2006
  11. 11. Code Samples CODE EXAMPLE 5-1 Coding With the Non-Blocking Scheduling Style 5-4 CODE EXAMPLE 5-2 Coding a Potentially Blocking Native Function 5-6 CODE EXAMPLE 6-1 isolate Constructor 6-3 xi
  12. 12. xii CLDC HotSpot™ Implementation Architecture Guide • July 2006
  13. 13. Preface This book surveys the architecture of the Connected Limited Device Configuration HotSpot™ implementation virtual machine. CLDC HotSpot Implementation is a high-performance virtual machine that can be used as an execution engine for the Connected Limited Device Configuration platform. Who Should Use This Document This document is intended primarily for individuals and companies who want to port the CLDC HotSpot Implementation virtual machine to a new platform. It is also invaluable for implementation engineers who wish to implement an entire Java™ Platform, Micro Edition (Java ME) technology-based stack on top of the CLDC HotSpot Implementation virtual machine. The document is useful also to anyone who wants to learn more about the internal details of the CLDC HotSpot Implementation virtual machine. xiii
  14. 14. How This Book Is Organized This book has the following chapters: Chapter 1 is a general overview of CLDC HotSpot Implementation. Chapter 2 describes key ideas behind and components of CLDC HotSpot Implementation. Chapter 3 describes the heap architecture and garbage collection features of CLDC HotSpot Implementation. Chapter 4 describes the architecture of the dynamic, adaptive compiler of CLDC HotSpot Implementation. Chapter 5 describes the threading system architecture of CLDC HotSpot Implementation. Chapter 6 describes the multitasking feature of CLDC HotSpot Implementation. Chapter 7 describes the ahead-of-time compilation feature of CLDC HotSpot Implementation. Chapter 8 describes the in-place execution feature of CLDC HotSpot Implementation. Chapter 9 describes the Jazelle support for ARM processors in CLDC HotSpot Implementation. Chapter 10 describes the ROMizer utility of CLDC HotSpot Implementation, which enables class compiled from the Java programming language to be linked directly in the virtual machine. Chapter 11 describes the support of Java programming language debugging environments in CLDC HotSpot Implementation. Terminology These terms related to the Java platform and Java technology are used throughout this manual. Java techology-based application (Java application) class contained in a Java class file (Java class) xiv CLDC HotSpot™ Implementation Architecture Guide • July 2006
  15. 15. Java technology- based code (Java code) Java programming language debugger (Java debugger) Java programming language object heap (Java heap) Java technology level (Java level) Java technology- based object (Java object) Java technology-based packages (Java packages) Java programming language profiler (Java profiler) Java technology-based programs (Java programs) thread in a Java virtual machine representing a Java programming language thread (Java thread) stack used by a Java thread (Java thread stack) Related Documentation The CLDC HotSpot Implementation Virtual Machine, A Technical White Paper, Sun Microsystems, Inc. (2003), which can be downloaded from http://java.sun.com/j2me/docs/. Connected, Limited Device Configuration Specification, Version 1.0, Java Community Process, Sun Microsystems, Inc., which can be downloaded from http://www.jcp.org/en/jsr/detail?id=030. Connected, Limited Device Configuration Specification, Version 1.1, Java Community Process, Sun Microsystems, Inc, which can be downloaded from http://www.jcp.org/en/jsr/detail?id=139. The Java™ Language Specification (Java Series), Second Edition by James Gosling, Bill Joy, Guy Steele, and Gilad Bracha (Addison-Wesley, 2000) Preface xv
  16. 16. The Java™ Virtual Machine Specification (Java Series), Second Edition by Tim Lindholm and Frank Yellin (Addison-Wesley, 1999) Mobile Information Device Profile Specification, version 1.0, Java Community Process, Sun Microsystems, Inc., which can be downloaded from http://www.jcp.org/en/jsr/detail?id=037. Mobile Information Device Profile Specification, version 2.0, Java Community Process, Sun Microsystems, Inc., which can be downloaded from http://www.jcp.org/en/jsr/detail?id=118. The Java Hotspot™ Performance Engine Architecture, A White Paper (Sun Microsystems, Inc., 1999), which can be downloaded from http://java.sun.com/products/hotspot/whitepaper.html. K Native Interface (KNI) Specification, (Sun Microsystems, Inc., 2002) Programming Wireless Devices with the Java™ 2 Platform, Micro Edition by Roger Riggs, Antero Taivalsaari and Mark VandenBrink (Addison-Wesley 2001) Programming Wireless Devices with the Java™ 2 Platform, Micro Edition, Second Edition, by Roger Riggs, Antero Taivalsaari, Jim Van Peursem, Jyri Huopaniemi, Mark Patel, and Aleksi Uotila (Addison-Wesley 2003) Java™ 2 Platform, Micro Edition, A White Paper (Sun Microsystems, Inc., 1999) http://java.sun.com/products/cldc/wp/KVMwp.pdf KVM Debug Wire Protocol (KDWP) Specification, (Sun Microsystems, Inc., 2002) xvi CLDC HotSpot™ Implementation Architecture Guide • July 2006
  17. 17. CHAPTER 1 CLDC HotSpot Implementation Virtual Machine CLDC HotSpot Implementation is Sun’s high-performance Java virtual machine for wireless phones and communicator-type devices. The first generation of Java technology-enabled wireless devices were based on the KVM (K virtual machine). delivered as part of Sun Microsystems’ CLDC Reference Implementation. The main objectives of this reference design are to demonstrate how the CLDC Specification could be implemented, and to validate the accompanying Technology Compatibility Kit (TCK). It provides a common base that allows device manufacturers to port to different platforms, as well as a working environment against which developers can test their CLDC-based applications. Sun introduced the CLDC HotSpot Implementation in mid-2002 as an optimized implementation that focuses on performance and footprint. Not only does it comply with the CLDC specification, but it also includes a number of patented features that propel faster application execution as well as more efficient resource management. It is also supported on a number of targeted platforms, which enables manufacturers to significantly reduce time to market. CLDC HotSpot Implementation delivers nearly an order of magnitude better performance than the KVM, while running in the same small memory footprint required by mobile phones, wireless e-mail clients, and personal organizers. CLDC HotSpot Implementation is the best virtual machine technology for new product deployments. Sun developed the CLDC HotSpot Implementation Java virtual machine technology to achieve the following objectives: ■ Faster performance ■ More robust platform ■ Faster time to market CLDC HotSpot Implementation applies advanced tuning and performance techniques utilized in the Java Platform, Standard Edition (Java SE) and Java Platform, Enterprise Edition (Java EE) technologies and further reduces footprint to 1-1
  18. 18. fit in small devices. In addition, it incorporates several design innovations that enable the virtual machine to run in resource-constrained devices. These techniques add the following features to the CLDC HotSpot Implementation: ■ Cutting-edge performance ■ Fast application startup time ■ Minimal footprint ■ Reduced porting efforts ■ Longer battery life The version of CLDC HotSpot Implementation now being offered by Sun Microsystems supports either CLDC 1.0 or CLDC 1.1. It can be compiled to support either one of these. CLDC HotSpot Implementation conforms to the corresponding version of the CLDC Specification and the TCK. To complete the Java technology stack, Sun also offers Sun Java Wireless Client, which integrates CLDC HotSpot Implementation with a high-performance implementation of the MIDP 2.0 Specification and other commonly used standard extensions such as MMAPI 1.1 and WMA 1.1. The HotSpot Virtual Machine At about the same time that the first specification of Java ME platform CLDC was released, Java SE and Java EE versions of a revolutionary Java virtual machine technology called HotSpot began product deployment. The HotSpot performance engine was developed to address the perception that Java virtual machine performance was insufficient for many mainstream applications, especially on big servers. By implementing a host of performance enhancing techniques that went beyond innovations like just-in-time (JIT) compilers, the performance of the Java virtual machine increased by an order of magnitude. HotSpot technology debuted in April 1999. See the Java HotSpot Virtual Machine Technical White Paper, Sun Microsystems, 2001. In 2001, these two technology trends converged to inspire the creation of the CLDC HotSpot Implementation virtual machine. In contrast to the reference implementation of CLDC and KVM, CLDC HotSpot Implementation is an optimized implementation. Creating Java technology-enabled consumer devices with KVM and CLDC was impressive, but the perception formed in the marketplace that, as in conventional Java technology, there was a need for faster performance (while working within the restricted resources of the target devices). CLDC HotSpot Implementation applies optimization techniques similar to those used in HotSpot technology (but using considerably less memory and consuming less power) to realize nearly an order of magnitude improvement in CLDC-based devices. 1-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  19. 19. 1.1 Processor and Memory Requirements The first generation of Java technology-enabled mobile phones had processor and memory requirements that were typical of the original design parameters of the KVM and CLDC. But, increasingly models are designed with considerably more computing power available. Now, the typical processor is a 32-bit processor with a clock speed of 60 megahertz or more. The typical memory resources in a target device are 600 kilobytes of RAM and about 2 megabytes of flash and ROM. The following table summarizes minimum and typical requirements for processor and memory which Java virtual machine technology must work within for next generation mobile phones. TABLE 1-1 Next-Generation Mobile Phone Minimum Requirements Item High-Volume Devices Premium Devices CPU type Mostly ARM Mostly ARM CPU speed 50 megahertz 60 megahertz and higher RAM 600 kilobytes (including 600 kilobytes (including MIDP) MIDP) ROM and Flash 1 megabyte 2 megabytes 1.2 Compilation Performance To improve the performance of a virtual machine beyond pure interpreter performance, some kind of a static or dynamic compilation strategy is needed. To approach an order-of-magnitude improvement in performance (compared to an interpreted virtual machine), while maintaining device-independent bytecode as the standard for applications, the CLDC HotSpot Implementation virtual machine has an innovative adaptive compiler. This compiler dynamically compiles the most frequently used, time-critical pieces of the applications into native code for significantly faster execution. The dynamic compiler of CLDC HotSpot Implementation delivers performance and efficiency that surpasses an implementation that would compile everything. One could build in CLDC HotSpot Implementation an “always-compile” mode, but this would execute slower than the more common mixed mode (which uses the adaptive compiler to optimize only the frequently called methods and uses an optimized bytecode interpreter for infrequently used code). Worse, the RAM requirement Chapter 1 CLDC HotSpot Implementation Virtual Machine 1-3
  20. 20. would be dramatically larger because compiled code requires more heap space. CLDC HotSpot Implementation in dynamic compiler mode delivers execution speeds that compare favorably even with desktop compilers such as the HotSpot 1.4.1 technology client of the Java SE platform. Yet, the RAM requirement of CLDC HotSpot Implementation is only a fraction of that of the HotSpot 1.4.1 technology client, which is of course the objective in small, embedded devices. The following diagram illustrates the order-of-magnitude performance improvement offered by a dynamic compiler. On the left is the benchmark performance of the KVM, and the 2x performance improvement offered by the optimized bytecode interpreter of CLDC HotSpot Implementation. On the right is the performance multiples that are currently realized by CLDC HotSpot Implementation. FIGURE 1-1 Performance of Interpreted Mode Compared With Compiled Mode in CLDC HotSpot Implementation Additional performance enhancement compared to straightforward virtual machines is achieved with a HotSpot technology-style garbage collector and a fast synchronization mechanism. Note – The performance enhancement applies to bytecode execution, not necessarily to processing graphics at the MIDP level. 1.2.1 Faster Execution Consumes Less Power The dramatic improvement in performance of CLDC HotSpot Implementation “turbocharges” application startup time and execution time, resulting in a positive subjective experience. Just as importantly, it consumes battery power at a proportionally lower rate. 1-4 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  21. 21. CHAPTER 2 Technical Overview CLDC HotSpot Implementation is a high-performance alternative to the K Virtual Machine (KVM), which in the past was widely deployed on Java ME platform- enabled cellular telephones. KVM design places significant emphasis on ease of portability and machine independence. The KVM is intended to be suitable for as large a number and as wide a variety of small devices as possible. Thus, any machine-specific optimizations or the use of assembly code is generally avoided. To ensure maximum portability, KVM is written entirely using the ANSI C programming language. The CLDC HotSpot Implementation virtual machine is intended to take the revolution started by KVM to the next level. To deliver cutting-edge performance on memory-constrained platforms, CLDC HotSpot Implementation employs a novel high-level architecture and a number of advanced, machine-specific optimization techniques. The system also borrows some key ideas from the HotSpot performance engines for the Java SE and Java EE platforms. Following are the key features of CLDC HotSpot Implementation: ■ Architecture designed for portability ■ Dynamic, adaptive compiler, which compiles the most-used methods at runtime ■ Compiler is incremental and schedulable ■ Optimized interpreter (written in assembly language) ■ Support for lightweight threads, which greatly simplifies porting ■ Compact object layout ■ Unified resource management ■ Accurate generational garbage collection ■ Ahead-of-time (AOT) compilation (optional) ■ In-place execution (optional) ■ Multitasking support (optional) ■ Fast synchronization ■ No restriction on number of loaded classes ■ ROMizer, which stores system classes in a compact format that allows faster execution ■ Multiple profile support with API isolation 2-1
  22. 22. ■ Dynamic native method support to allow adding optional packages after manufacture ■ Support for both CLDC 1.0 or CLDC 1.1 with full TCK compliance ■ Support for hardware acceleration technology, with battery savings and fast startup ■ Support for 32-bit addressing, useful for large-memory, next-generation phones ■ Ability to be built as a main program or as a subroutine in an event loop 2.0.1 Portable Architecture The CLDC HotSpot Implementation system is written in a portable subset of the C++ programming language, enabling it to be ported fairly easily to all platforms for which a C++ compiler is available. The system provides CPU-specific assembly code for the ARM and x86 processors to implement the optimized interpreter and the compiler. Information on porting these CPU-specific parts of the system is provided in Chapter 8 of the CLDC HotSpot Implementation Porting Guide. 2.0.2 Dynamic Compiler In general, Java virtual machines with a compiler are an order of magnitude faster than those that provide only an interpreter. For that reason, CLDC HotSpot Implementation includes a dynamic compiler to provide fast bytecode execution. A well-known problem with compiling bytecodes into native instructions is that the generated code takes up four to eight times as much space as the original bytecodes. An adaptive compilation technique in CLDC HotSpot Implementation alleviates this problem by compiling only methods recognized as “hot spots” (the most frequently used parts of the application). The CLDC HotSpot Implementation dynamic compiler finds the hot spots by running a statistical profiler. To minimize the amount of compiled code, CLDC HotSpot Implementation virtual machine includes an optimized interpreter used for infrequently executed methods. For more information on CLDC HotSpot Implementation’s dynamic compiler, refer to Chapter 4. The CLDC HotSpot Implementation compiler is a simple one-pass compiler that provides a number of basic optimizations. It is an adaptive compiler, because it uses data gathered at runtime to decide which methods to compile. Only the methods that execute most frequently are compiled. 2-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  23. 23. Incremental and Scheduled Compilation The maximum duration of any single compilation and the minimum time interval between compilation attempts can be set and dynamically adjusted. If the duration of a compilation exceeds the maximum, the compilation is suspended and the execution of the user program continues, with the current method being interpreted. The suspended compilation may resume after the specified minimum time interval. Tunability Because the performance characteristics of small devices can vary considerably from one platform to another, even when using the same CPU architecture, the CLDC HotSpot Implementation system provides a large number of compilation options and parameters that allow the performance of the compiler to be tuned. Some of these options and parameters are summarized in Chapter 4 of the CLDC HotSpot Implementation Porting Guide. 2.0.3 Optimized Interpreter CLDC HotSpot Implementation has an optimized interpreter written in assembly code and customized for a particular CPU architecture. Optimized interpreter loops are currently available for two CPU architectures: x86 (using 386 as the lowest common denominator) and ARM. Rather than writing the assembly loops by hand, they are generated statically from the debug version of the CLDC HotSpot Implementation system itself. This can be accomplished by invoking the debug version of the virtual machine from the command line by using the -generate or -generateoptimized option. The former option generates an assembly interpreter for debugging the virtual machine, while the latter option generates an interpreter that can be linked in product builds. 2.0.4 Lightweight Threading System CLDC HotSpot Implementation supports a lightweight threading system in addition to supporting native threads (OS threads). In contrast to native threads, lightweight threads are implemented within the Java runtime environment. In the CLDC HotSpot Implementation, separate execution stacks are maintained for lightweight threads and native threads. For the remainder of this manual, a lightweight thread is referred to as a LWT. In CLDC HotSpot Implementation, LWTs are implemented on a single native OS thread. Using this simple model, CLDC HotSpot Implementation can be ported to environments that do not offer any multi-threading capability. Even more Chapter 2 Technical Overview 2-3
  24. 24. importantly, the virtual machine has complete control over all memory allocation aspects of thread stacks for Java objects. It can dynamically “right size” these thread stacks. The lightweight threading system is detailed in Chapter 5.” Support is also available for managing multiple native OS threads using the anilib library. This is called the hybrid threading model, as detailed in Section 5.4, “Hybrid Threading Coding Style” on page 5-5. 2.0.5 Compact Object Layout CLDC HotSpot Implementation supports a compact object layout to reduce general memory consumption. A Java object has two parts: an object header and an object body that are stored contiguously. The object header provides reflective information such as the class pointer and contains a possible hash code or locking status or both. The object body contains the instance fields of the object. Conventional Java virtual machine implementations use at least two words for the object header, even though in most cases the hash code information and locking status is needed only for a small number of the objects. Consequently, object headers take up a big fraction of the total object space. Very Compact Object Headers CLDC HotSpot Implementation introduces a new design in which only one word is needed for the object header. This object header contains a pointer to a near class in which the other information (such as hash code and locking status) is stored as necessary. New instances are created with a prototypical near class that is shared among instances. When the instance is assigned a hash code or it is about to be locked, the object header is changed to point to a newly created individual near, instead of the prototypical one. This approach greatly reduces memory consumption for object instances. Because most Java object instances contain only a small number of instance fields, the ability to cut the object header size in half or by one third results in significant space savings. The CLDC HotSpot Implementation object structure is illustrated in FIGURE 2-1. 2-4 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  25. 25. FIGURE 2-1 Relationship Between Instance, Near Class, and Class Field Packing In addition to the compact object headers, CLDC HotSpot Implementation uses a field packing technique borrowed from the HotSpot performance engine. When a Java object contains instance fields of type boolean, byte, short or char, the system stores them using a more space-efficient 8-bit or 16-bit representation, rather than allocating full 32-bits for each of these fields. This technique can also result in significant space savings when a large number of object instances are allocated. This affects the internal object layout, because instance fields of the same type are grouped together. 2.0.6 Unified Resource Management A major benefit of CLDC HotSpot Implementation is unified resource management. Unified resource management means that all allocated data in the virtual machine resides inside the object heap. Allocated data include the following: ■ Java objects ■ Reflective objects, such as methods and classes ■ LWT execution stacks ■ Compiler generated code ■ Virtual machine internal data structures An important advantage of unified resource management is that the same garbage collector takes care of cleaning up all allocated resources, even compiled code. Almost all other virtual machines have designated areas for user objects, reflective data, temporary data, and generated code. Such schemes result in memory fragmentation, multiple cleanup strategies, and other complexities. CLDC HotSpot Implementation solves these issues by using the mark-sweep-compact garbage collector for most regions of the heap. This implementation does maintain a few regions in the heap dedicated for special kinds of objects. Different algorithms are used to manage memory in different regions and to adjust region sizes adaptively. However this multi-region management is transparent to applications. Chapter 2 Technical Overview 2-5
  26. 26. Another benefit of unified resource management is that compiled code can be removed dynamically to free space for user-level objects. Coding of native methods is implemented consistently with the lightweight threading model (see Chapter 5”), which exemplifies unified resource management and makes garbage collection even more efficient. In general, uniform resource management has significant benefits in resource- constrained environments in which programmers are strongly discouraged from allocating additional memory from the operating system or the device while the system is running. 2.0.7 Generational Garbage Collection A garbage collector automatically reclaims unused object memory and makes the freed memory available for new allocations. CLDC HotSpot Implementation uses an accurate generational mark-and-compact garbage collector, which results in the following advantages: ■ Fast object allocation ■ Small garbage collection pauses ■ No memory fragmentation ■ Accuracy For more technical details on garbage collection in CLDC HotSpot Implementation, see Chapter 3.” 2.0.8 Dedicated Heap Area for Compiled Code CLDC HotSpot Implementation maintains a dedicated region within the object heap for compiled code. This facilitates incremental compilation and eliminates the need for garbage collections to dispose temporary data of the compiler and compiled code evicted from the cache. This helps minimize compiler-related pauses, and garbage collection is simplified so that the maximum time for a particular garbage collection is reduced. For more technical details about the heap architecture in CLDC HotSpot Implementation, see Chapter 3.” 2-6 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  27. 27. 2.0.9 Multitasking Support The Java programming language provides convenient language-level multithreading and monitor mechanisms. These mechanisms make it easy to write multithreaded programs that use fine-grained locking. The CLDC HotSpot Implementation system uses a variant of the block-structure locking and synchronization approach that was developed originally for the HotSpot performance engine. Refer to the The Java HotSpot Performance Engine Architecture, A White Paper listed in the Preface of this guide under “Related Documentation” on page xv”. If it is desired for the user to be able to run multiple applications concurrently, CLDC HotSpot Implementation can be compiled with a switch to support running in multitasking mode. An important feature of multitasking support in CLDC HotSpot Implementation is the isolation of the tasks so that they can execute correctly (in a way that is compliant to the Java Language Specification) as if they were executed in a single task environment. Although only one thread of execution exists at any given time, for practical purposes the MIDP application layer of the Java thread stack can avail itself of multiple virtual machines. Any of the multiple virtual machines can be paused when a switch to a different application in a different context is desired and resumed in the same state at a later point in time. For more technical details about multitasking support in CLDC HotSpot Implementation, see Chapter 6.” 2.0.10 Faster Virtual Machine Startup With Ahead-of-Time Compilation Ahead-of-time compilation or AOT improves startup time by immediately executing frequently used methods in compiled mode without spending time to compile them during runtime. Consider the tradeoff that must be made between faster startup times and increased ROM footprint from methods selected for AOT. To gain the optimal benefit from this feature, an implementation must be analyzed for candidates for ahead-of-time compilation. To begin with, only Java methods in ROMized system classes can be AOT compiled. Of those methods, careful select frequently executed methods or hot spots. For more technical details about AOT support in CLDC HotSpot Implementation, see Chapter 7.” Chapter 2 Technical Overview 2-7
  28. 28. 2.0.11 Faster Application Startup With In-Place Execution If it is desired for the handset maker to preverify certain trusted applications to allow faster application startup, CLDC HotSpot Implementation can be compiled with a build-time option to support in-place execution. Becvause it bypasses the Java class loader for selected applications, this option significantly reduces application startup time. For more technical details about in-place execution support in CLDC HotSpot Implementation, see Chapter 8. 2.0.12 Fast Synchronization The Java programming language provides convenient language-level multithreading and monitor mechanisms. These mechanisms make it easy to write multithreaded programs that use fine-grained locking. The CLDC HotSpot Implementation system uses a variant of the block-structure locking/synchronization approach that was developed originally for the HotSpot performance engine. Refer to the The Java HotSpot Performance Engine Architecture, A White Paper listed in the Preface of this guide under “Related Documentation” on page xv”. Rather than creating explicit monitor objects on the heap, the system places the monitor information on the execution stack. This approach avoids the memory allocation and garbage collection costs typically associated with synchronization in Java virtual machines. As a result, synchronization performance becomes so fast that it is no longer a performance bottleneck for Java applications. For more information on the threading system of CLDC HotSpot Implementation, refer to Chapter 5.” 2.0.13 Integrated Class Prelinker The CLDC HotSpot Implementation system features an integrated prelinker called a ROMizer for Java class libraries. This component pre-loads all class libraries that might be required at runtime, storing them in a compact format known as a ROMized image. This image is embedded in the CLDC HotSpot Implementation virtual machine when it is built. The image becomes part of the executable, which is burned into the ROM of a device at the time of manufacture. 2-8 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  29. 29. To generate the ROMized image, the GenerateROMImage option must be set when running a virtual machine built in debug mode. (efer to Chapter 4 of the CLDC HotSpot Implementation Porting Guide. The ROMizer outputs the image in the file ROMImage.cpp, which is portable between platforms. In the development environment, the integrated class prelinker runs during the CLDC HotSpot Implementation system startup phase. It pre-loads all system classes, including those required by the configuration (CLDC) and the profile (MIDP). Thus, all these classes are available pre-linked as a ROMized image. When the ROMized image embedded in the CLDC HotSpot Implementation virtual machine, and a Java application is run in the development environment or in a device, any system class required by the application is already pre-loaded and pre- linked. For more information on using the ROMizer in CLDC HotSpot Implementation, refer to Chapter 10.” 2.0.14 Fully Object-Oriented Internal Design and Upwards Scalability The CLDC HotSpot Implementation system is written in a portable subset of C++ and the internal design of the system is fully object oriented. The internal object layout inside the system follows the same conventions as the system uses for Java objects. This makes the system scalable and lends itself to future enhancement. In principle, the CLDC HotSpot Implementation system could be easily extended to support the semantics of the full JavaSE platform, including features such as reflection, serialization, remote method invocation, and so on. 2.1 Additional Components The system includes a number of additional components that are specific to Java ME releases: ■ CLDC libraries. The CLDC HotSpot Implementation release comes with an implementation of the CLDC libraries. At this point, since the CLDC 1.1 Specification is not yet finalized, only CLDC 1.0 libraries are supported. ■ Runtime verifier. The CLDC HotSpot Implementation system includes a KVM- style runtime verifier. This means that application class files given to the system must be preverified (as explained in the CLDC 1.0 Specification) before they can be executed. Chapter 2 Technical Overview 2-9
  30. 30. ■ Dynamic memory profiler. This tool allows the virtual machine to be paused and a profile to be taken of the amount of heap memory in use at that time. ■ Incremental Java Archive (JAR) file reader. Beginning with version 1.1.3 of CLDC HotSpot Implementation, the JAR file reader does not cache the whole decoded JAR file entry in the Java heap. Instead, a new method is provided to decode small portions of the entry. This is especially beneficial for the decoding of audio and video streams, which typically have sizes up to several hundred kilobytes or a few megabytes. ■ K Native Interface (KNI). The CLDC HotSpot Implementation system includes an implementation of the KNI API that is intended to provide source-level compatibility for the native functions that are written for virtual machines that conform to the CLDC standard. Also, extensions to KNI are provided to support the threading models detailed in Chapter 5. More information on the KNI is available in a separate publication, K Native Interface (KNI) Specification, (Sun Microsystems, Inc., 2002). ■ Debugging support. This support uses the KVM Debug Wire Protocol (KDWP). It also provides support for debugging in commercial IDEs. Refer to Chapter 11 for details of debugging support. 2.2 New Technical Features in This Release CLDC HotSpot Implementation 1.1.3 includes the following powerful new features: ■ Support for in-place execution in multitasking mode ■ Multiple profile support with API isolation ■ Dynamic native method support to allow adding optional packages after manufacture ■ Vector floating point support ■ Incremental JAR file reader ■ Support for interpreter-only mode ■ Improved debugger support with commercial IDEs The following sections describe these new features in more depth. 2.2.1 In-Place Execution in Multitasking Mode The 1.1.2 release of CLDC HotSpot Implementation did not allow in-place execution in multitasking mode. This release removes that restriction. 2-10 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  31. 31. 2.2.2 Multiple Profile Support This feature allows building a system ROM image containing multiple profiles. The meaning of profile for this feature is different than a Java ME platform profile (such as MIDP). Multitasking support in CLDC HotSpot Implementation now defines new APIs, allowing a new task to be assigned a profile. The profile defines what APIs must be hidden or restricted for a MIDlet running in that task. 2.2.3 Dynamic Native Method Support CLDC HotSpot Implementation now supports the downloading and linking of native methods as part of JAR files downloaded to the device after manufacture and deployment. With this mechanism, support for additional optional packages can be added to the device after manufacture. 2.2.4 Vector Floating Point Support Vector floating point (VFP) is a generic hardware coprocessor that can be used with any ARM processor core. VFP can be run either in IEEE-compliant slow mode or in a non-compliant fast mode. This release of CLDC HotSpot Implementation fully supports both modes. CLDC HotSpot Implementation can be built to invoke this hardware when a floating point instruction is encountered. Since the implementation uses the VFP coprocessor for other purposes, building in this mode is beneficial for the performance of all programs. 2.2.5 Incremental JAR File Reader In past releases of CLDC HotSpot Implementation, the JAR file reader cached the whole decoded JAR file entry in the Java heap. This is undesirable with JAR filescontaining large data files such as audio or video streams. The new incremental JAR file reader supports incremental reading, which provides a new method to decode small portions of a JAR file entry. Chapter 2 Technical Overview 2-11
  32. 32. 2.2.6 Interpreter-Only Mode The availability of this build option helps a device manufacturer support a wide range of ARM processors while standardizing on one virtual machine. Simply by building with different options, CLDC HotSpot Implementation can scale up as well as down and fit in all devices with a wide variety of resources. This mode also is of interest when building with Jazelle integration. 2.2.7 Improved Debugger Support With Commercial IDEs Above, corrected init capping per SESG. The CLDC HotSpot Implementation debug module (KDWP) can communicate with commercial IDEs such as NetBeans, WebSphere, JBuilder X Developer and JBuilder 2005 Developer. This allows on-device debugging using these IDEs. 2-12 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  33. 33. CHAPTER 3 Heap Architecture and Garbage Collection CLDC HotSpot Implementation supports a“segregated” heap architecture, which features a separate heap area for compiled methods. This greatly reduces the likelihood of noticeable pauses. Although it is possible to build the CLDC HotSpot Implementation virtual machine without this segregated heap, this is not recommended. 3.1 Garbage Collection Within each heap area, the CLDC HotSpot Implementation virtual machine employs a two-generational mark-and-compact garbage collector, as illustrated in FIGURE 3-1. Old Generation New Generation Object Heap FIGURE 3-1 The CLDC HotSpot Implementation Two-Generational Garbage Collector 3-1
  34. 34. 3.1.1 Structure of the Heap The object heap is divided into old generation, new generation, and as-yet-unused portions of memory. The old generation region contains objects that were previously garbage collected and compacted. New objects are allocated in the new generation region, which is generally much smaller. When the new generation region is full, the garbage collector runs briefly and reclaims the unused memory for that generation. In this case, the former new generation becomes part of the “new” old generation. A part of the unused portion of the heap is allocated to become the “new” new generation. When all memory in the object heap is consumed, the garbage collector runs across the entire heap and compacts all live objects into a single “new” old generation. Only during this large garbage collection does a longer pause occur, but it occurs infrequently. This scheme takes advantage of the fact that the vast majority of objects are short lived. Because most objects are short lived, only a small portion of allocated objects are promoted to the old generation. Most garbage collection operations focus only on the new generation, resulting in only very small garbage collection pauses. 3.1.2 Tracking Pointers Across Generations One requirement of a generational system is the ability to track pointers from old generation to new generation. For this, CLDC HotSpot Implementation uses a write barrier. Whenever a pointer store takes place, the field is marked as a possible future pointer from the old to the new generation. 3.1.3 Fast Allocation A side benefit of a compacting garbage collecting is that new objects are allocated contiguously in stack-like fashion in the young generation. Object allocation is then simply a matter of increasing a pointer value. 3-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  35. 35. CHAPTER 4 Dynamic Compiler Two different compilers are appropriate in the CLDC HotSpot Implementation virtual machine: a dynamic compiler and an ahead-of-time compiler. The dynamic compiler is an adaptive compiler, because it uses data gathered at runtime to decide which methods to compile. Only the methods that execute most frequently are compiled. The other methods are interpreted by the virtual machine. The ahead-of-time compiler is available to compile classes and methods that are to be ROMized. The dynamic compiler is essentially a one-pass compiler that provides a number of basic optimizations. The compiler makes a preliminary scan of a method to determine entry points. Then a target-dependent optimizer makes a final pass through the generated code. The dynamic compiler works as a co-routine in a single Java thread. Parameters can be set so that the compiler can suspend itself after a given time interval. 4.1 Code Set Management The set of methods that are interpreted and compiled must be managed in real time by the dynamic compiler. This is done as follows: ■ The profiler detects hot interpreted and compiled methods. ■ The compiled code cache uses cost-benefit analysis to limit space occupied by compiled code. ■ The compiled code cache size is dynamically adjustable. ■ Program startup and phase transitions are handled in a special way. ■ Compiled code is stored a dedicated region within the object heap. 4-1
  36. 36. 4.2 Tuning the Dynamic Compiler Because the performance characteristics of small devices can vary considerably from one platform to another, even when using the same CPU architecture, the CLDC HotSpot Implementation system provides a large number of compilation options and parameters that allow the performance of the dynamic compiler to be tuned. For more information on tuning the dynamic compiler, refer to the CLDC HotSpot Implementation Porting Guide. 4-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  37. 37. CHAPTER 5 Threading System This chapter provides an overview of the threading system in CLDC HotSpot Implementation 1.1.3. More implementation details are given in Chapter 3 of the CLDC HotSpot Implementation Porting Guide. The system has two distinct threading models. The simplest and preferred model supports LWTs (light weight threads). In this model, CLDC HotSpot Implementation implements all LWTs on a single native OS thread. LWTs are essentially co-routines created and scheduled by the virtual machine. This is transparent at the Java runtime environment level. Using this simple model, CLDC HotSpot Implementation can be ported to environments that do not offer any threading capability. Even more importantly, the virtual machine has complete control over all memory allocation aspects for LWT stacks. It can dynamically “right size” LWT stacks. Thus the implementation avoids otherwise unavoidable pathological program failures due to lack of either stack space or heap space. As a consequence of only having a single active execution context for LWTs, it is a strict requirement that all native methods return virtually immediately. Otherwise the whole virtual machine stalls and the user perception of preemptive multi- threading at the Java level is foiled. A special style of handling threading might be preferable in some ports. This style relies on the availability of native thread support in the target platform OS. It is called hybrid threading, and is further described in Chapter 3 of the CLDC HotSpot Implementation Porting Guide. 5-1
  38. 38. 5.1 Long-Running Compared With Blocking Native Methods It is useful to distinguish between ordinary long-running and blocking native methods. For native methods that are long-running simply because they execute a lot of free-flowing application code, one can often maintain the appearance of “smooth” thread scheduling by breaking the code up into repeated native calls that return to Java after “reasonably short” execution intervals. This gives the virtual machine the opportunity to perform sufficient thread context switching. Blocking calls pose a greater challenge in that they carry the program execution into a system that is not under virtual machine control. A typical example is a socket read() call into the underlying OS. As long as such a call does not return, the virtual machine is trapped in inaction and the user is waiting and other LWTs are suspended even though they are ready to execute. Chapter 3 of the CLDC HotSpot Implementation Porting Guide describes the APIs and the SPI in CLDC HotSpot Implementation for efficient implementation of native methods that make calls to potentially blocking routines. 5-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  39. 39. CHAPTER 6 Multitasking This document describes the multitasking feature of the CLDC HotSpot Implementation virtual machine. The multitasking feature allows multiple user MIDlets to run in addition to a system MIDlet, which can be used by an application management service (AMS) to coordinate the creation and termination of user MIDlets. The CLDC HotSpot Implementation virtual machine can be built with or without the option to support multitasking. If it is built not to support multitasking, the virtual machine is said to be running in SVM mode. 6.1 Introduction Multitasking is the ability to handle multiple tasks or applications simultaneously. Of course, they aren't actually running at the same time on a single CPU, but the user perceives concurrency. In earlier CLDC HotSpot Implementation virtual machines, each application had to run in its own virtual machine to run multiple Java applications. The amount of wasted memory space due to separate copies of the virtual machine usually outweighs the usefulness of running multiple applications. Running multiple Java applications in a single virtual machine in such a way that each application is unaware of other applications running at the same time is a better solution. All the code of the virtual machine and much of the data is shared among all applications. In particular, applications can share common immutable data such as method bytecodes, final data types, and compiled method code. Sharing of free memory is also very important. The frequency of garbage collection depends on the amount of free memory. Free memory sharing reduces the frequency of garbage collection and the overall time spent in garbage collection. 6-1
  40. 40. 6.1.1 Isolates At the Java level, each separate running Java application within one virtual machine is called an isolate. The API used to instantiate each isolate is a stripped-down version of the Isolate API defined in JSR 121. Refer to Section 6.1.3, “Reduced Isolate API” on page 6-5. At the virtual machine level, each isolate is represented as a Task. A task consists of one or more threads of execution. The CLDC HotSpot Implementation Isolate API is in the source tree at src/javaapi/share/com/sun/cldc/isolate. The isolate mechanism comes close to combining the isolation guaranteed by UNIX system style processes and the lightweight resource consumption of threads. To the user, isolates very much resemble processes, but internally they are represented by tasks consisting in groups of threads operating on logically disjoint object graphs. Physical sharing between those object graphs can occur if it only applies to constant objects. Sharing opportunities typically arise from metadata, such as internal symbols and field descriptors. Dynamically compiled code is also shared (by not making use of certain optimizations). Conceptually, the main architectural change in the multitasking from the non- multitasking (SVM) virtual machine is that each isolate or task has a separate, private copy of the static variables of all the loaded Java classes. Normally, in the SVM case, if an application loads a Java class, the static variables of that class are global to all threads running in that virtual machine. In the multitasking case, static variables are only global to all threads within a particular isolate. 6.1.1.1 Example Program The CLDC HotSpot Implementation Isolate API is quite simple to use. A new isolate starts executing at the main method just like a “normal” Java application. To create a new isolate, set up a String array of arguments to the new isolate, set up the classpath for the new Isolate object, and call the constructor. Think of calling the Isolate constructor the same way as calling the Thread constructor. In the case of the Thread constructor, when you subsequently call the start method, a new thread starts executing at the run method of the class you just instantiated. In case of the Isolate constructor, when you subsequently call start, the main method of the class you pass into the constructor is run in a new task (and a new thread). To enable this, you must build the CLDC HotSpot Implementation virtual machine with Isolate support compiled in. Use the ENABLE_ISOLATES=true compilation flag in the gnumake command. This provides for Isolate support in the virtual machine and compiles the Java level Isolate API classes. 6-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  41. 41. CODE EXAMPLE 6-1 is an example of programming a new isolate. To run this example, put HelloMVM.class in HelloMVM.jar, and MyIsolate.class in MyIsolate.jar. Then run the following command: cldc_hi -cp HelloMVM.jar HelloMVM CODE EXAMPLE 6-1 isolate Constructor import com.sun.cldc.isolate.Isolate; public class HelloMVM { public static void main(String args[]) { String[] isoArgs = {"hello"}; String[] classpath = {"MyIsolate.jar"}; System.out.println("Starting child"); try { Isolate iso = new Isolate("MyIsolate", isoArgs, classpath); iso.start(); iso.waitForExit(); } catch (Throwable t) { t.printStackTrace(); } System.out.println("Child exited"); } } class MyIsolate { public static void main(String args[]) { System.out.println("You're saying " + args[0]); } } 6.1.2 Multitasking in MIDP 2.0 Sun’s reference implementation of MIDP 2.0 does not support multitasking. The MIDP 2.0 specification, while not requiring multitasking, does allow it provided the following distinctions are made: ■ MIDlets in the same MIDlet suite share resources and must not be isolated. ■ MIDlets from different MIDlet suites must be isolated. Chapter 6 Multitasking 6-3
  42. 42. As part of Sun Java Wireless Client, Sun Microsystems developed a MIDP implementation that supports multitasking. The main architectural changes from non-multitasking MIDP to multitasking MIDP are in MIDlet management and in the handling of events. MIDlet management is conducted by a singleton “task manger” object, which can be accessed both from Java programs and at the native virtual machine level. Native code can access the task manger object with the API function SNI_AddStrongReference. A native method must be implemented to make the task manger object reference reachable by every isolate in Java programs. Thus, every isolate can invoke methods on the shared singleton task manager. This mechanism is used, for example, to communicate isolate state changes to the AMS. The AMS runs in the system MIDlet and never terminates unless the entire virtual machine is shut down. By using the task manager object as a repository for all its bookkeeping about other isolates, the AMS can quickly access all relevant system state information in one central place. FIGURE 6-1 Multiple Java Program Event Queues A new requirement implied by a multitasking environment is that native events such as button presses and keyboard presses need to be routed to an appropriate running MIDlet. Thus, simple mapping of one native event queue to one MIDlet event queue no longer applies. Instead, now one native event queue caters to multiple Java program event queues. One queue is created for each MIDlet. See FIGURE 6-1. An event multiplexer determines which event needs to be routed to which MIDlet. The implementation code for this can be found in the midpEvents.c file in the MIDP code base. 6-4 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  43. 43. 6.1.3 Reduced Isolate API As mentioned earlier, the CLDC HotSpot Implementation Isolate API is a stripped- down version of the JSR 121 implementation for the Java SE and Java EE platforms. This API is hidden from developers of user MIDlets. It is available only to the developers of AMS software. See the source code at src/javaapi/share/com/sun/cldc/isolate. 6.2 Isolate Implementation This section presents implementation details about isolate support in the CLDC HotSpot Implementation virtual machine. 6.2.1 Virtualization of Static Variables The key concept in the multitasking implementation is that static variables are not part of the JavaClassDesc memory object (as they are in the SVM case). Instead, it has a table of pointers to TaskMirrorDesc for each active task. An entry in this table points to a TaskMirrorDesc object for a given class. The table is indexed by class ID. The TaskMirrorDesc object contains the actual storage for the static variables. During execution, a global variable, _current_task_mirror_list, contains the pointer to the TaskMirrorDesc table for the current running task. 6.2.2 Static Class Initialization When the Java bytecode attempts to access a static variable, it must first load the TaskMirrorDesc for the particular InstanceClass in which the static variable is instantiated. If the TaskMirrorDesc is NULL, it means that this class has not been initialized for this task. Initialization involves running the method Class.initialize for that class, and initializing any static variables. The same process is involved to invoke a static method. The virtual machine must first determine if the class that contains the method has been initialized, and if not, it must go through the initialization process. Following are examples of how to load a static variable for different classes: ■ Non-multitasking case JavaClassDesc = _class_list_base[class ID] value = *JavaClassDesc[static_var_offset] Chapter 6 Multitasking 6-5
  44. 44. //where static_var_offset is calculated at class load time. ■ Multitasking case TaskMirrorDesc = *_current_task_mirror_list[class ID] value = *TaskMirrorDesc[static_var_offset] In the multitasking case, an extra load is required to get the pointer to the appropriate TaskMirrorDesc to obtain the static variable value. 6-6 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  45. 45. 6.2.3 Isolate Creation FIGURE 6-2 illustrates the overall process of creating a new isolate. FIGURE 6-2 Isolate Creation Chapter 6 Multitasking 6-7
  46. 46. 6.2.4 Synchronization This section discusses two kinds of synchronization that are handled by CLDC HotSpot Implementation: synchronization of instances of Java classes and synchronization of interned string objects. 6.2.4.1 Synchronization of Java Classes In the SVM case, each InstanceClass created in the virtual machine has a pointer to a Mirror object. This Mirror object is an instance of Class.java and is used during initialization as well as for synchronizing on the InstanceClass. In the multitasking case, in order for synchronization to be task-private, each InstanceClass loaded into the system must have one private copy of this Mirror object per task. The TaskMirrorDesc object that contains the static variables also contains a pointer to a Mirror object. Because each InstanceClass has a separate TaskMirrorDesc for each running task, threads in one task cannot block threads in another task. 6.2.4.2 Synchronization of Interned String Objects Because String objects are interned when a class is loaded, they are global across all tasks. In order to synchronize on String objects (which is done rarely in practice) the virtual machine maintains a table of proxy objects that are used to do the actual synchronization. These objects are task private, so that synchronization is task private. This code is used in the SVM case as well, because it allows String objects in ROMized classes to be in the TEXT section. Thus, the implementation doesn’t need to modify the Near pointer in the String to lock it. The String object itself is never locked, but is used as a key to find or allocate a proxy object that is actually locked. 6.2.5 Resource Management When multiple isolates are running in the same virtual machine, they share computational resources such as CPU time and memory. The virtual machine is in charge of administering CPU time and memory resources to ensure that all isolates get an appropriate share. Other resources, such as network bandwidth and communication ports, are managed by the MIDP layer or by optional packages such as MMAPI. 6-8 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  47. 47. 6.2.5.1 Scheduling and Priorities To prevent one task from taking a disproportionate amount of CPU time, CLDC HotSpot Implementation uses a simple fair scheduling algorithm. Each time a thread from a particular task is run, a counter for that task is incremented. If the count exceeds a value determined by the priority of that task, an attempt is made to run a thread from another task. If all tasks exceed their quota, all the counts are reset and the algorithm starts over. A task can have one of three priority levels: low, normal, and high. You can set the priority with the method Isolate.setPriority. 6.2.5.2 Object Heap Sharing The virtual machine allows all isolates to allocate from the same global heap region. This provides more flexible control and sharing. The object graphs of different isolates are intertwined without intersecting, except when sharing constant objects. The virtual machine has a bookkeeping mechanism that accounts for each isolate’s object graph’s total heap memory consumption and it injects OutOfMemoryError as needed to inform isolates that heap space has become scarce. The CLDC HotSpot Implementation virtual machine implements an exact synchronous memory quota mechanism. Memory quota violations are detected and signalled to the isolate if they are encountered upon an attempt to allocate memory. The memory quota for an isolate is defined by two fields: reservation and limit. The reservation is the minimum amount of memory to needed to run the isolate. The limit is the maximum amount of memory the isolate is allowed to use. You can set the memory quota for an Isolate using the method Isolate.setMemoryQuota. 6.2.6 JSR 121 JSR 121 defines a Java API for multitasking that is oriented towards larger (Java SE and Java EE platforms) systems. Recently the CLDC space is being taken into consideration. But at the time of this writing, this JSR is still ongoing and, for now, it is not formally integrated by CLDC, MIDP, or Java Technology for the Wireless Industry. To provide services similar to those defined in JSR 121, CLDC HotSpot Implementation offers a much reduced subset of the JSR 121 API and adds features. One noteworthy example is that the original Links API, which controls inter-isolate communication, is by a more lightweight mechanism. This significantly reduces complexity and footprint. Chapter 6 Multitasking 6-9
  48. 48. The CLDC HotSpot Implementation extensions for multitasking are located in the package com.sun.cldc.isolate. Use of these extensions is described in Section 6.1.2, “Multitasking in MIDP 2.0” on page 6-3.” Note – These extensions are available only to system programmers and are not presented to user applications. 6-10 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  49. 49. CHAPTER 7 Ahead-of-Time Compilation Support This chapter describes the ahead-of-time (AOT) compilation support in CLDC HotSpot Implementation. Selected methods can be compiled ahead of time, and the result can be burned into ROM when the device is manufactured. The AOT feature offers two key advantages. ■ Reduced startup time, because AOT-compiled methods do not need to be compiled again at run time. ■ More efficient usage of RAM, because AOT-compiled methods live in ROM. 7.1 Methods Eligible for AOT Compilation Only Java methods in ROMized system classes can be AOT compiled. The compilation happens during the build process on the development host. The result of the compilation is saved as a part of the constant data of the system class image. AOT-compilation of Java methods in downloaded Midlets is not supported in this release. 7.2 Choosing Methods to AOT Compile A new syntax in the ROM configuration file is available to specify the methods to be AOT compiled. If ROM footprint is not an issue, you can specify that all ROMized methods be AOT compiled. AOT-compiled methods are typically four to eight times 7-1
  50. 50. larger than the original Java bytecodes. To save footprint, you can specify only a subset of methods to be AOT compiled. This subset can be determined by running benchmark programs and determining the hot ROMized methods. 7.3 AOT Compilation of Downloaded Classes The possibility of combining AOT compilation with the application image converter from in-place execution (see Chapter 8, so that methods in downloaded classes can be compiled and saved in the execute-in-place format is under invenstigation. This feature might be included in a future release. 7-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  51. 51. CHAPTER 8 In-Place Execution This chapter describes in-place execution support in CLDC HotSpot Implementation. It presents an overview of the design, its advantages, and platform requirements. 8.1 Design Overview The goal of the in-place execution feature is to reduce RAM usage of the Java class loader and improve start-up time. The core of this feature consists of two modules: ■ The Application Image Converter converts an application’s JAR file into an application image, a format that requires much less memory and executes much faster. ■ The Fast Class Loader loads the application image into the Java heap of the virtual machine for execution. An application image is the memory content of an application after being loaded by the virtual machine. It contains Java class data structures such as JavaClass, ArrayClass, Method and ConstantPool, as well the static variables of a application. It is equivalent to the results produced by the ClassFileParser module in CLDC HotSpot Implementation versions prior to 1.1.2. 8.2 Security Considerations Special security considerations exist when using the in-place execution feature. Because the verifications normally performed by the Java class loader are bypassed in the fast class loader, application image files must be maintained on a secured file 8-1
  52. 52. system that cannot be modified by users or by untrusted applications. The manufacturing processes by which these image files are transferred to product ROM or flash memory must also be securely controlled. 8.2.1 Storing Application Image Files The verifier is an important part of the Java virtual machine that ensures the integrity and safety of MIDlets. The verifier must be run before a MIDlet is run through the application image converter. After conversion, the application image files must be stored in a secured storage device, inaccessible by untrusted applications and by the phone’s user. This must be done with extreme care. Because the verifications normally performed by the Java class loader are bypassed by the Java class loading enhancement feature, if an application image file is altered by malicious parties, the security safeguards of the verifier are circumvented. In such cases, invalid Java programs might be allowed to execute on the phone and gain access to arbitrary memory locations. The results can include, but are not limited to, the following: ■ The phone might crash. ■ Sensitive information might be stolen from the phone. ■ The phone might be used in a coordinated denial-of-service attack of the cellular network. Different phones may have different ways of storing secured information, so we are not able to recommend how to store the verification results without specific information about your devices. However, following are examples where verification must not be stored because the storage device is not secured: ■ The results are stored in a removable storage device (such as an SD card) that the user can modify using a Personal Computer. ■ The results are stored in a file in the phone’s internal file system, but the user can modify the file (for example, by connecting the phone to a personal computer or by using a built-in application on the phone). ■ The phone allows the user to download arbitrary native applications that are able to modify the verification results. 8-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  53. 53. 8.2.2 Warning Message The code provided in this implementation contains a special mechanism that is invoked when you create an application image file: the following warning message is printed. This message is to remind you of the security requirements. Remove the code that prints this warning message after you implement the required security mechanisms. ****warning*** ****Binary ROM Images must be created in secured file system. ****Please refer to CLDC-HotSpot(TM) Porting Guide for more information*** ****warning*** Refer to Appendix E of the CLDC HotSpot Implementation Porting Guide for additional security considerations for the in-place execution feature. 8.3 Integrating the In-Place Execution Feature CLDC HotSpot Implementation provides APIs for integrating the in-place execution feature into a Java ME MIDP platform. 8.3.1 Running the Converter The Converter transforms an application JAR file (.jar) into an application image binary file (.bin). The Converter is a part of the virtual machine that uses the virtual machine to load the Java classes from JAR file into the heap, verify the class contents, and write the classes to a .bin file. Typically, the Converter is executed by the Application Management Software (AMS) immediately after a JAR file is downloaded to the device, with the following method call: JVM_CreateAppImage(char *jarFile, char *binFile, int flags); The flags argument to the JVM_CreateAppImage function specifies whether class files are to be removed from the JAR file after the conversion process. If your device is configured to use CLDC HotSpot Implementation in the single virtual machine (SVM) mode, you must run the Converter in a clean virtual machine state. That is, if a Java application is executing, you must exit the Java application before running the Converter. Chapter 8 In-Place Execution 8-3
  54. 54. 8.3.2 Executing an Application Image No new API exists for executing an application image (.bin) file. Instead, the virtual machine recognizes a .bin file from its classpath by reading a magic number from the first four bytes of the .bin file. A .bin file contains only the classes of an application. The resources and JAR manifest files are untouched in the JAR file. Therefore, when executing an application image, the AMS must specify both the .bin and JAR files in the classpath. 8.3.3 In-Place Execution Example Here is an example for using in-place execution inside MIDP. This assumes that the classpath contains MyMidlet.jar, which the AMS is about to launch. The function JVM_CreateAppImage creates a in-place execution bundle for the JAR file if necessary and launches the virtual machine to execute from the bundle (instead of from the JAR file). void startMidlet(char *classpath) { char * bundleName = "MyMidlet.bun"; if (!file_exists(bundleName)) { JVM_CreateAppImage(classpath, bundleFile, JVM_REMOVE_CLASSES_FROM_JAR); } // Was: JVM_StartVM(classpath, main_class, argc, argv); JVM_StartVM(bundleName, main_class, argc, argv); } 8.4 In-Place Execution from Flash With this technology, the majority of the application image is run directly from the flash file system without first loading it into RAM. This might be achieved with careful modifications of the virtual machine on your platform. Contact your Sun Java Licensee Engineering representative for more information. 8-4 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  55. 55. 8.5 Experimenting With In-Place Execution This section describes how to try the in-place execution features in CLDC HotSpot Implementation 1.1.3. Note that much of this is subject to change in future releases: ■ Build when setting the build-time option ENABLE_MONET=true, as follows: cd build/linux_i386 make ENABLE_MONET=true ■ Run the virtual machine to create an application image file, as follows: target/bin/cldc_hi -cp HelloWorld.jar -convert. ■ Load the application image file into the virtual machine and execute the program that it contains, as follows: target/bin/cldc_hi -cp ROM_binary.bun HelloWorld Chapter 8 In-Place Execution 8-5
  56. 56. 8-6 CLDC HotSpot™ Implementation Architecture Guide • July 2006
  57. 57. CHAPTER 9 Jazelle Option for ARM Implementations This chapter describes Jazelle support in CLDC HotSpot Implementation. This option is especially interesting for ARM-based implementations that lack sufficient memory resources to support the full dynamic compiler of CLDC HotSpot Implementation. However, on any implementation, Jazelle can improve performance during startup. It also can provide an improvement during transition phases: When the virtual machine is moving from one hotspot to another, the next method might not yet be compiled. Thus, while the virtual machine is running in interpreted mode, Jazelle- enabled fast hardware improves performance and provides a better user experience. Although Jazelle support can be enabled on a platform in which memory is abundant, it is always preferable from a performance standpoint to use the dynamic compiler if it is available. Jazelle provides essentially no performance improvement while Java code is executing in compiled mode. 9.1 Flags to Enable Jazelle It is necessary to set seven flags to enable Jazelle. For convenience, these settings are contained in the file .../build/ads_jazelle/ads_jazelle.cfg. As usual, you must create a copy of the build directory that pertains to your platform and tool chain to make customized build settings. 9-1
  58. 58. Notice to Sun’s Licensees – This confidential and proprietary software may be used for evaluation or testing purposes for internal use only. Any commercial use requires execution of a separate JTEK licensing agreement from ARM Limited. This is in addition to any license agreement the licensor may have entered into with Sun. For the avoidance of doubt, distribution of products containing software code to exercise the BXJ instruction and enable the use of the ARM Jazelle architecture extension without a JTEK licensing agreement from ARM is expressly forbidden. © COPYRIGHT 1999 to 2004 ARM Limited © COPYRIGHT 2004 Sun Microsystems, Inc. ALL RIGHTS RESERVED 9-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006

×