• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cldc Hotspot Architecture
 

Cldc Hotspot Architecture

on

  • 2,713 views

 

Statistics

Views

Total Views
2,713
Views on SlideShare
2,713
Embed Views
0

Actions

Likes
1
Downloads
44
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cldc Hotspot Architecture Cldc Hotspot Architecture Document Transcript

    • CLDC HotSpot™ Implementation Architecture Guide CLDC HotSpot Implementation, Version 1.1.3 Java™ ME Platform Sun Microsystems, Inc. www.sun.com July 2006
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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 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
    • 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 Potentially Blocking Native Function 5-6 CODE EXAMPLE 6-1 isolate Constructor 6-3 xi
    • xii CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • ■ 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • ■ 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • //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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 8-6 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • 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
    • 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
    • CHAPTER 10 ROMizer CLDC HotSpot Implementation supports a ROMizer utility. This is also known as the class prelinker or the class preloader. The ROMizer enables classes compiled from the Java programming language to be linked directly in the virtual machine, reducing virtual machine startup time considerably. At the implementation level, the ROMizer utility combines Java class files and produces a C++ file that can be compiled and linked with the CLDC HotSpot Implementation virtual machine. In conventional class loading, you use javac to compile Java source files into Java class files. These class files are loaded into a Java technology system, either individually or as part of a JAR file. Upon demand, the class loading mechanism resolves references to other class definitions. The ROMizer provides an alternative means of program linking and symbol resolution, one that provides a less-flexible model of program building, but which helps reduce the virtual machine’s bandwidth and memory requirements. The ROMizer can accomplish the following tasks: ■ Combine multiple input files ■ Determine an object instance’s layout and size ■ Load only designated class members, discarding others 10.1 Running the ROMizer The standard CLDC HotSpot Implementation build process for Linux on i386 and Win32 on i386 creates the following ROMizer executables: ■ $(JVMBuildSpace)/build/linux_i386/dist/bin/romgen ■ $(JVMBuildSpace)/build/win32_i386/dist/bin/romgen.exe 10-1
    • You can use these executables to generate the ROM image of your system classes by issuing a command such as: romgen.exe -cp classes.jar -romize romizer-options ... This command converts all class files in classes.jar into a ROM image, which is stored in the output file ROMImage.cpp. You can then compile and link ROMImage.cpp into your virtual machine executable. 10.2 Requirement for System Classes The system classes that you wish to ROMize must satisfy the following requirements: ■ All classes must be packaged into a single JAR file, such as in the file classes.jar in the previous example. ■ The standard CLDC HotSpot Implementation process creates the file $(JVMBuildSpace)/classes.zip. This file includes important classes that the ROMizer requires for correct operation. Your classes.jar file must include all the classes stored at the following subdirectories in this file, without alteration or omission, for the ROMizer to function properly: ■ classes/com/sun/cldchi ■ classes/java/lang Note – Your CLDC HotSpot Implementation license might require that you must also include other CLDC HotSpot Implementation classes in as-is form. 10.3 ROMizer Options The ROMizer supports the following options. ■ GenerateROMComments, VerboseROMComments These two options tell the ROMizer to generate comments inside the ROMImage.cpp output file. The comments may be useful for understanding the structure of ROMImage.cpp and for debugging. Example: +GenerateROMComments -VerboseROMComments 10-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • ■ GenerateRelaunchableROM If this option is enabled, the ROMizer generates a “relaunchable image,” which means the virtual machine can be restarted in the same process. This is useful if your virtual machine process never terminates, but the virtual machine is restarted inside the same process to execute different Java applications. This option is enabled by default. If your virtual machine process always terminates after running one Java program, you can turn off this option to save footprint. Example: -GenerateRelaunchableROM The syntax of these options is the same as other command-line options for the CLDC HotSpot Implementation virtual machine. Note – Whether -GenerateRelaunchableROM saves footprint depends on your system’s handling of the .data, .text, and .bss segments. Experiment with GenerateRelaunchableROM turned on and off to see which yields the best result. 10.3.1 ROMizer Optimization Options The CLDC HotSpot Implementation ROMizer can perform a large number of optimizations to reduce the ROM footprint and increase performance. None of these optimizations change the semantics of your Java code. When used correctly, these options can help you save as much as 30% of the ROM image footprint. For example, the RenameNonPublicROMSymbols option only affects methods and fields that are not accessible by user applications. Also, the SimpleROMInliner option does not inline methods that may potentially be overridden by user applications. Certain options must be used in conjunction of a ROM configure file (see the -romconfig option in the following list) to produce the correct results. Please read this section carefully so that you can use these ROM optimization options effectively and safely. The CLDC HotSpot Implementation ROMizer has the following optimization options: ■ EnableAllROMOptimizations This option enables all available ROM optimization options, including the following: ■ AggressiveROMSymbolRenaming ■ CompactROMFieldTables ■ RenameNonPublicROMClasses ■ RenameNonPublicROMSymbols ■ SimpleROMInliner Chapter 10 ROMizer 10-3
    • Some of these optimizations require special care with KNI methods. Please read the description of each individually optimization option before enabling EnableAllROMOptimizations. Example +EnableAllROMOptimizations ■ CompactROMFieldTables If this option is enabled, the field tables of the ROMized classes are compacted. That is, fields that are not accessible by user applications are removed from the field tables to save footprint. This option is disabled by default. ■ RenameNonPublicROMClasses Many non-public ROMized system classes are not accessible by user applications. If this option is enabled, all such non-public classes are renamed to save footprint. This option is disabled by default. Example: +RenameNonPublicROMClasses If you use this option, be sure to use the DontRenameClass command in your ROM configuration file to exclude any classes that cannot be renamed. For example, do not rename any classes that are accessed using the Class.forName Java method or the KNI_FindClass C function. ■ RenameNonPublicROMSymbols ROMized system classes must contain many non-public symbols (such as the names of private and package-private fields and methods). User application cannot refer to these symbols because of Java programming language security. Hence, you can use this option to rename these symbols such that they take up less space. However, this option might interfere with your KNI code if you use KNI_GetFieldID() to access non-public fields. Thus, the RenameNonPublicROMSymbols option is disabled by default and must be used with caution. It is best to enable this option, but to use the DontRenameNonPublicFields command in your ROM configuration file (see below) to exclude any classes that might be accessed by KNI_GetFieldID(). ■ AggressiveROMSymbolRenaming This option takes effect only if you enable the RenameNonPublicROMSymbols option. If you enable this option, all fields and methods (even the ones declared with the public keyword) in your non-public ROMized classes are renamed to save space. Note that when this option is enabled, a user application can still access public fields and methods in a non-public class as long as these fields and methods are inherited from a public super class. For example, if you have the following code, application classes can still access f() in B: 10-4 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • public class A { public void f() {...} } class B extends A { public void f() {...} public void g() {...} } However, they cannot access g(), because it is not declared in a public class. ■ MakeRestrictedPackagesFinal This option applies to non-public classes in restricted Java packages (see the -romconfig option ). When this option is enabled, the ROMizer adds the final attribute to the class’s declaration, provided it is not a public class and one of the following is also true: ■ It is not a public class and it belongs to a restricted package ■ It belongs to a hidden package This makes it possible for the CLDC HotSpot Implementation virtual machine to use the faster invokevirtual_final bytecode to execute methods in this class. This option is enabled by default. ■ RewriteROMConstantPool Conventionally, each Java class owns an individual constant pool. Usually, constant pools of ROMIZED system classes have many duplicate entries. This option (enabled by default) enables you to share a single constant pool among all the ROMized system classes to reduce space. ■ MergedConstantPoolLimit This option controls the maximum number of entries allowed in a merged constant pool. The default value is 65535, which is the maximum number allowed by the Java Programming Language Specification. The main purpose for this option is for debugging the ROMizer. Use the default value in most cases. ■ EmbeddedROMHashTables This option takes effect only if RewriteROMConstantPool is enabled. When this option is enabled, the ROMized String and Symbol hashtables are embedded into the merged constant pool. ■ ROMHashTableDepth This option controls the average size of hashtable buckets for the ROMized String and Symbol tables. The default value is 8. Larger values save space, at the cost of longer search time. Shorter search times require more space. Chapter 10 ROMizer 10-5
    • Example: =ROMHashTableDepth12 ■ SimpleROMInliner If this options is enabled, certain methods in the ROM image are inlined. Example: class Foo { int bar; private void setBar(int value) { bar = value; } static void doSomething(Foo foo) { foo.setBar(1234); } } The setter method like the setBar() method in the previous example is inlined to produce the following code, which is both smaller and faster: class Foo { int bar; /* eliminated from ROM image private void setBar(int value) { bar = value; } */ static void doSomething(Foo foo) { foo.bar = 1234; } } ■ GenerateROMStructs If this option is enabled, the ROMizer outputs a file called ROMStructs.h, which declares C structures that represent the layout of all ROMized Java classes. You can use these structures to write native code that directly accesses non-static fields in the romized classes. This approach is much faster than the KNI_GetFieldID() API. Note – If you write native code using ROMStructs.h, the code is not portable to other CLDC virtual machines that do not support this functionality. ■ HeapCapacity, HeapMin 10-6 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • Currently the ROMizer requires quite a bit of memory. The ROMizer allocates an 8-megabyte heap by default (that is, the =HeapCapacity8M flag is on). However, if you have many classes in your classes.jar file, the ROMizer might fail with a cryptic message. If this happens, try adjusting HeapCapacity to 16M or higher. The HeapMin option must never be set during ROMization. ■ -romconfig filename All the options describes so far apply to the entire ROM image. The -romconfig option, on the other hand, enables you to configure individual classes in the ROM image. The filename parameter specifies a ROM configuration file. The file can contain the following entries: ■ InitAtBuild = class-name The InitAtBuild entry tells the ROMizer to initialize the given class at build time. This feature is useful if you have classes with large class initializer methods, especially those that initialize large arrays. You can reduce virtual machine startup time and shrink footprint by initializing such classes at build tim. That is, during the generation of ROMImage.cpp. Note – This option must be used with great caution. Initialize a class at build time only if its class initializer always produces the same result. For example, if your class initializer produces different output depending on the return value of System.currentTimeMillis(), then it is obviously not a candidate for initialization at build time. Also, the ROMizer prints a warning if any class initializer calls System.getProperty(). In most cases you perform cross-ROMization. For example, you run the ROMizer on a PC and use its output, ROMImage.cpp, to build a MIDP stack for a target device. The System.getProperty() method in the ROMizer returns an incorrect value, because it does not know anything about the properties defined in MIDP. The ROMizer’s warning message includes a stack trace to tell you the offending class that calls System.getProperty(). ■ DontRenameClass = class-name If you use KNI_GetClass() or Class.forName() to access a class, use the DontRenameClass entry to tell the ROMizer not to rename the given class. ■ DontRenameNonPublicFields = class_name If you use KNI_GetFieldID() to access fields of a class, use the DontRenameNonPublicFields entry to tell the ROMizer not to rename the non-public fields in this class. ■ RestrictedPackage = package-name Chapter 10 ROMizer 10-7
    • For security reasons, you might need to disallow applications from defining classes in certain Java packages. This prevents malicious applications from accessing the package-private members of these packages. This is an example that makes java.lang into a restricted package: RestrictedPackage = java.lang ■ HiddenPackage = package-name This entry makes the given package completely hidden from a user application. The application cannot access any of the classes of the give package, even those explicitly declared public. HiddenPackage implies RestrictedPackage. The main reason for using HiddenPackage is to hide the API implementation classes (for example, a com.sun.* implementation for a javax.microedition.io.* API). It can prevent malicious applications from using even the public interfaces of such packages. It can also prevent naive applications from accidentally using some implementation packages that might not be available in future versions of your software. HiddenPackage also makes it possible for the ROMizer to perform more optimizations to further reduce footprint. ■ DontCompile = pattern On slow platforms, dynamic compilation of Java methods into native code can take significant amount of virtual machine startup time. Many methods in a typical MIDP implementation are executed only once during startup. To help minimize star-up time, you can use the DontCompile entry to disable compilation for such methods. pattern is a match pattern for the fully qualified name of a method. For example, any of the following patterns matches the Object.toString method: java.lang.Object.toString java.*.Object.toString *.Object.toString The ROMizer output file, ROMLog.txt (see Section 10.5, “ROMizer Log File” on page 10-10), contains a listing of all the methods that are marked as do-not- compile. Use this listing as an aid to check if your patterns match the desired methods. 10.3.2 Example An example configuration file is included in the CLDC HotSpot Implementation source distribution at $(JVMBuildSpace)/src/vm/cldc_rom.cfg: 10-8 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • InitAtBuild = java.lang.Integer InitAtBuild = java.util.Calendar InitAtBuild = com.sun.cldc.util.j2me.CalendarImpl InitAtBuild = java.lang.Runtime InitAtBuild = com.sun.cldc.util.j2me.TimeZoneImpl InitAtBuild = com.sun.cldc.io.j2me.socket.Protocol InitAtBuild = java.util.TimeZone InitAtBuild = com.sun.cldc.i18n.j2me.ISO8859_1_Reader DontRenameNonPublicFields = com.sun.cldc.io.ResourceInputStream RestrictedPackage = java.io RestrictedPackage = java.lang 10.4 Ahead-of-Time (AOT) Compilation The ROMizer supports the ahead-of-time compilation of Java methods in ROMized system classes. 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. A new syntax is included in the ROM configuration file to specify the methods to be AOT-compiled: Precompile = pattern Note – If a method matches patterns for both Precompile and DontCompile, that method is not 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 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 hottest candidate ROMized methods. Following are the advantages of AOT compilation: ■ Reduced startup time - AOT-compiled methods do not need to be compiled again at runtime. ■ More efficient usage of RAM - AOT-compiled methods reside in ROM. Chapter 10 ROMizer 10-9
    • 10.5 ROMizer Log File Besides the ROMImage.cpp output file, the ROMizer also creates a log file, ROMLog.txt, which contains various statistics about the ROM image. One important purpose of the ROMLog.txt file is to list the unintialized classes at build time, and why they are uninitialized. Here’s an example: [Uninitialized Classes] javax.microedition.lcdui.TextEditor -> <clinit> not executed (435 bytes) -> uninitialized super class javax.microedition.lcdui.TextBox -> uninitialized super class javax.microedition.lcdui.Screen This log entry shows that the TextEditor class was not initialized at build time for the following reasons: ■ Its static initializer method (<clinit>) was not executed because this class was not specified by an InitAtBuild entry in the ROM configuration file. ■ Two of its superclasses were not initialized. In this example, because the <clinit> method of TextEditor is relatively large, consider rearranging the code so that TextEditor can be initialized and its <clinit> method remove, at build time. Also check in ROMLog.txt the list of non-restricted packages (see the [classes in non-restricted packages] section of ROMLog.txt). Typically this list is empty so that malicious applications cannot be able to access package-private members of the system classes. 10-10 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • CHAPTER 11 Java Programming Language Debugging (KDWP) CLDC HotSpot Implementation can plug its virtual machine into third-party Java platform development and debugging environments, provided they are compliant with the Java Platform Debug Architecture (JPDA) specification supported by the Java SE platform. Further information on the JPDA architecture is available at http://java.sun.com/products/jpda/. Due to strict memory constraints, CLDC HotSpot Implementation does not implement support for the Java Virtual Machine Debug Interface (JVMDI) and full Java Debug Wire Protocol (JDWP) specifications required by JPDA. Instead, CLDC HotSpot Implementation implements a subset of the JDWP known as KVM Debug Wire Protocol (KDWP). A specification of the KDWP protocol is available in a separate document, KVM Debug Wire Protocol (KDWP) Specification, (Sun Microsystems, Inc., 2001). 11.1 KDWP Architecture The KDWP is a strict subset of the JDWP, primarily based on the resource constraints imposed on the CLDC HotSpot Implementation virtual machine. To make CLDC HotSpot Implementation run with a JPDA-compatible debugger IDEs, a debug agent (debug proxy) program is interposed between the virtual machine and the JPDA- compatible debugger. The debug agent enables many of the memory-consuming components of a JPDA-compliant debugging environment to be located on the development workstation instead of in the virtual machine, therefore reducing the memory overhead on the virtual machine and target devices due to the debugging interfaces. Of course, the debugging interfaces can be turned off completely (at compile time) on those platforms and ports that do not need debugging support at the level of the Java programming language. 11-1
    • At the high level, KDWP debugging support implementation consists of two parts: ■ The actual code in the virtual machine to support a subset of the JDWP ■ The debug agent that performs some of the debug commands on behalf of the virtual machine The overall architecture for the Java-level debugging interface is illustrated in FIGURE 11-1. In that figure, the top-most box represents the JPDA-compliant debugging environment (“JPDA Debugger”) running on a development workstation. The debugger is connected to a debug agent, which communicates with the virtual machine. JPDA Debugger Socket Connection Debug Agent Socket Connection CLDC HotSpot Implementation Virtual Machine FIGURE 11-1 Java Programming Language Debugging Interface Architecture The debug agent connects to the virtual machine via a socket connection. Similarly, the debugger connects to the debug agent over a socket. The debugger is unaware that it is connected to the debug agent. The debugger appears to be communicating directly with a JDWP-compliant Java virtual machine. In fact, the debug agent can be configured in pass through mode so that all packets are passed from input to output using the debug agent with a Java virtual machine. In normal CLDC HotSpot Implementation debug mode, the debug agent examines packets from the debugger and determines which packets are to be handled by the virtual machine and which are to be handled within the debug agent. The main processing done in the debug agent is the parsing of class files to extract debugging information. This includes line number and code offset information and variable information. The KDWP implementation within the virtual machine includes some vendor-specific commands that the debug agent uses to communicate with the virtual machine. 11-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • 11.2 Debug Agent An executable for the debug agent (also known as debug proxy) is included with the CLDC 1.1 release. The debug agent is written in the Java programming language. The source code can be downloaded from http://java.sun.com/products/cldc/. The code has two main portions: the portion that handles connections to the debugger and to the virtual machine, and the portion that handles the parsing of the class files. The latter code is located in subdirectory classparser. 11.2.1 Connections Between a Debugger and CLDC HotSpot Implementation The portion of the code that handles connections to the debugger and to the virtual machine resides in file KVMDebugProxy.java. This code creates two objects: DebuggerListener and KVMListener. The DebuggerListener class handles the retrieval of packets from the debugger and the KVMListener class handles the retrieval of packets from the virtual machine. DebuggerListener and KVMListener are both subclasses of class Thread. Therefore, when they are invoked, they start a new thread of execution (on the development workstation.) Each object also is passed a handle to the other object (that is, the KVMListener object is passed a handle to the DebuggerListener object, and vice versa). This enables cross-communication of packets between the debugger and the virtual machine. The following diagram (FIGURE 11-2) clarifies this further. Chapter 11 Java Programming Language Debugging (KDWP) 11-3
    • JPDA Debugger Debugger Listener Class Manager CLDC HotSpot Implementation Listener Debug Agent CLDC HotSpot Implementation Virtual Machine FIGURE 11-2 Debugger and CLDC HotSpot Implementation Connections In a typical scenario, the CLDC HotSpot Implementation virtual machine is started with the -debugger flag, which puts it into a debugger-enabled mode. In this mode, the virtual machine listens on a socket for a connection from the debug agent. When the debug agent is started, it connects to this socket, and then listens on another socket for a connection from the debugger. When the debugger connects, it issues the JDWP handshake command, which consists of the string JDWP-Handshake. The debug agent acknowledges by reflecting this string back to the debugger. Meanwhile, the debug agent has sent the handshake command to the virtual machine, which has responded back with information about which optional events it supports. The KVMListener then queries the virtual machine for a list of all the classes that are currently loaded into it. This information is used to build a hash table of ClassFile objects that is used later when the debugger requests information about a specific class (such as line number information, method information, and so forth.) At this point, each thread is listening for packets. The virtual machine sends a VMInit event to the debugger using the debug agent, which indicates to the debugger that the virtual machine is starting its execution of the Java technology application. The debugger might also send packets that indicate to the virtual machine to start other events such as ClassPrepare or ClassLoad. 11-4 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • The communication code for the debug agent is in source file SocketConnection.java. In this file, each object (KVMListener and DebuggerListener) creates a thread of execution that waits for packets to arrive from its respective socket. If the packet is a command packet (the Packet.Reply bit is not set), it puts that packet on a packetQueue list (see file ProxyListener.java) and a notification is sent to any object waiting on that queue. The packet is then extracted from the queue by whatever listener is waiting for that packet on that queue. In the run method for the KVMListener and DebuggerListener, each packet is analyzed to determine if the debug agent needs to process the packet or whether it is to be transmitted to the other object for further processing. 11.2.2 Packet Processing The DebuggerListener object intercepts a number of packets as is evident by examining the code for the large switch statement located after the call to waitForPacket. When waitForPacket returns with a packet, the debug agent first creates a new PacketStream object, then checks to see if the debug agent needs to process that packet. For example, the SENDVERSION_CMD packet is processed by the debug agent directly and a response is created and sent to the debugger without any interaction with the virtual machine. A more complex commandis the FIELDS_CMD of the REFERENCE_TYPE_CMDSET. For this command, the debugger passes in a class id, which is used by the debug agent to find a ClassFile object via the ClassManager.classMap object. The classMap object is filled by the KVMListener object when it receives the ClassPrepare events from the virtual machine. Once the debug agent obtains the ClassFile object, it uses the getAllFieldInfo method to obtain a list of fields and iterates through this list passing the information back to the debugger. Once again, no interaction with the virtual machine occurs. Similarly, within the source file for the KVMListener.java, the KVMListener object intercepts the CLASS_PREPARE events that are passed up from the virtual machine. KVMListener creates a new ClassFile object using the call to manager.findClass and inserts it into the ClassManager.classMap hashtable. KVMListener then passes the event to the debugger so that it can process the event as well. Chapter 11 Java Programming Language Debugging (KDWP) 11-5
    • 11.3 Debugger Support The debugger support within the CLDC HotSpot Implementation virtual machine consists primarily of the files in the directory src/vm/share/debugger. All debugger code is included with the conditional compilation flag ENABLE_JAVA_DEBUGGER. If this flag is enabled and the virtual machine is rebuilt, the Java debugger support is included within the virtual machine. If Java debugger support is not desired, rebuild with ENABLE_JAVA_DEBUGGER=false. Note – If your target platform or port does not require Java level debugging support, turn the debugging code off at compile time by rebuilding with ENABLE_JAVA_DEBUGGER=false This makes the virtual machine executable much smaller. The following files are located in the debugger directory of the source tree: ■ JavaDebugger.* - Main interface to the debug agent. Handles the processing of commands and replies. ■ SocketTransport.* - Handles debugger packets to and from a socket. ■ VMEvent.* - Handles events to the debugger. ■ VMEventModifier.* - Supports various attributes of events. ■ DebuggerStream.* - Manages the debugger packets to and from the debugger. ■ *Impl.* - Handles specific commands from the debugger to obtain information about the program being debugged. 11.3.1 Events Events are essentially commands generated by the virtual machine. Events are passed up to the debug agent, which can in turn pass them up to the debugger. The code for handling an event is similar to the following example: #if ENABLE_JAVA_DEBUGGER { VMEvent::new_class_prepare_event(&ic);} #endif /* ENABLE_JAVA_DEBUGGER */ A typical event routine in VMEvent.cpp first determines if the event attempting to be sent was enabled by a previous Set Event command from the debugger. Then, findSatisfyingEvent is invoked to determine if this particular event matches an event request sent down from the debugger. The get_event_request function also checks the event counter as well as any modifiers that the debugger applied to 11-6 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • this event. If the event passes, it is sent on the outputStream. After an event is sent, handleSuspendPolicy is invoked to process whatever suspend policy the debugger attached to this event when the debugger issued the Set Event command. Some events, such as breakpoints or single stepping, generally have a suspend policy of ALL, which means that all threads are suspended and that the virtual machine continually polls the debugger for commands. The Resume command eventually comes from the debugger when the user issues a Continue command or when the user explicitly issues a Resume Thread command. 11.3.2 Breakpoints When the Java bytecode interpreter hits the Breakpoint opcode (see TemplateTable_<arch>.cpp), if it is not single stepping, the handle_breakpoint function is invoked, which sends an event to the debugger via the debug agent. Eventually, the user presess the Continue button on the debugger, which causes all threads to resume execution. 11.3.3 Single Stepping When the debugger issues a SingleStep event request, the code in VMEvent.cpp must determine which type of step function it is, that is, step by bytecode or step by line. It also must determine which tipe of step it is, as follows: ■ Step Into - Step into a function. ■ Step Over - Step over calls to functions. That is, do not single step into another function. ■ Step Out - Go back to the function that called this function. Additionally, if it is a step by line, the virtual machine needs to know what the code offset is for the next line number. To obtain this information, the virtual machine calls a private API within the debug agent to return the target offset and the next line offset. The debug agent returns this information to the virtual machine, which stores it into a StepModifier object. Within the interpreter loop, a flag is checked to determine if this particular thread is in single-step mode. If so, the handle_single_step function in VMEvent.cpp is invoked to process this single step. The handle_single_step function determines if the instruction pointer reached the target offset or if it popped up a frame or if it exceeded the target offset. Depending on the type of stepping being performed, this function determines when to send a SingleStep event to the debugger. In most cases, if the user is single stepping line by line, and when the code offset is equal to the target offset, it results in a SingleStep event to be sent to the debugger. All threads are typically Chapter 11 Java Programming Language Debugging (KDWP) 11-7
    • suspended at this point, and as was the case for the breakpoint scenario described earlier, the virtual machine waits until the debugger resumes the threads using a Continue command or a subsequent SingleStep event. 11.4 Using the Debug Agent and the JPDA Debugger To run the debug agent, it is necessary to build the application class or classes being debugged to include debug information. It is also necessary to transform the application class file(s) using the preverifier. Then, after the virtual machine is invoked on a specified host and port, the debug agent can be started so that it listens to requests on the virtual machine port, and a local port is specified for connecting with a JPDA-compatible debugger. The following section summarizes the steps necessary to start a debug session in much more detail. Note – CLDC HotSpot Implementation debugger functionality is integrated into the Java ME platform wireless toolkit. Therefore, if you are using the wireless toolkit, the detailed steps in the next section are not necessary. 11.4.1 Starting a Debug Session 1. Build the application classes to be debugged with the -g option to include debug information. 2. Place the output in a separate directory for transforming the resulting class file using this command: javac -g -classpath <path> -d <directory> <class> Note the following: ■ -g indicates debug information is to be included. ■ In -classpath <path>, <path> indicates the directory that contains the virtual machine Java library classes and the application classes for the application being debugged. ■ In -d <directory>, <directory> indicates the directory in which output classes are to be written. The default output directory is ./output. ■ <class> is the application class or classes being debugged. 11-8 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • 3. Invoke the preverifier for transforming the class file with this command: preverify -classpath <path> -d . <directory> This transforms all classes under <directory> and places the transformed class files in the current directory (as specified by the -d option). 4. Start the CLDC HotSpot Implementation process with this command: cldc_hi -debugger -classpath <path> -port <CLDC-HotSpot-Implmentation-port> <class> Note the following: ■ -debugger indicates that the virtual machine is to be placed in debugger-enabled mode ■ In -classpath <path>, <path> specifies the directory that contains the virtual machine Java library classes and the application classes for the application being debugged. ■ -port <CLDC-HotSpot-Implmentation-port> is the CLDC HotSpot Implementation port. The default port is 2800. This must match the port specified by the debug agent in Step 5. ■ <class> is the application class being debugged. 5. Start the debug agent (debug proxy) with this command: java -classpath <path> kdp.KVMDebugProxy -l <localport> -p -r <CLDC-HotSpot-Implmentation-host> <CLDC-HotSpot-Implmentation-port> -cp <CLDC-HotSpot-Implmentation-path> ■ -classpath <path>, where <path> specifies the directories in which the debug proxy classes are located. ■ -l <localport>, where <localport> is the port that the debugger connects to. ■ -p indicates to run as a debug proxy. ■ -r <CLDC-HI host>, where <CLDC-HI host> is the remote host name. ■ <CLDC-HI port> is the port that must match the port specified in step 3 above. ■ -cp <path>, where <path> is the directory or directories which contain the virtual machine Java library classes and the application classes for the application being debugged. 6. Connect to the debug agent with the debugger. For Sun ONE Studio debugger, go to the Debug->Attach dialog box and insert the host where the debug agent is running and the local port number that was specified using the -l <localport> option. Chapter 11 Java Programming Language Debugging (KDWP) 11-9
    • Note – To obtain Sun ONE Studio, go to http://wwws.sun.com/software/sundev/jde/buy/index.html. When running the Sun ONE debugger, JDK version1.3 or later must be installed and be on the classpath, because only this version (or later) of the JDK includes support for the JPDA. For further information on downloading the latest JDK version, please refer to the web site at http://java.sun.com/j2se. For jdb (Java debugger), the command is as follows: jdb -attach <agent hostname>:<localport> 11.4.2 Debugging Example If the CLDC HotSpot Implementation virtual machine is running on a system called siciy, and the debug agent and debugger are running on debughost, then the commands for starting the debug session appears as follows: 1. On the sicily system, build the application testusing this command: javac -g -classpath ../api/classes:../samples/classes -d output test.java 2. Invoke the preverifier for building a preverified class file, using this command: preverify -classpath ../api/classes:../samples/classes -d . output 3. On the sicily system, type the following command to invoke CLDC HotSpot Implementation: cldc_hi -debugger -classpath ../api/classes:../samples/classes -port 2800 test 4. On the debughost system, assuming the current directory is tools/kdp/classes, the following command invokes the debug agent (debug proxy): java -classpath . kdp.KVMDebugProxy -l 1234 -p -r sicily 2800 -cp ../../../api/classes:../../../samples/classes 5. Invoke the Sun ONE debugger, followin gthese steps: a. Select the Debug->Attach dialog and select the socket transport. b. Enter debughost in the host name box, and enter 1234 in the port number box. c. Press OK. 11-10 CLDC HotSpot™ Implementation Architecture Guide • July 2006
    • Index A compiler, dynamic, 4-1 adaptive compilation, 2-2 compiler, tunability, 4-2 ahead-of-time compilation (AOT), support for, 7-1 ahead-of-time compiler, 4-1 D AMS (application management service), 6-1, 6-4 debugger support with KDWP protocol, 11-1 ANI (asynchronous native interface), 5-5 dynamic compiler, 4-1 ani.h, 5-5 dynamic compiler, tuning, 4-2 AOT(ahead-of-time compilation), support for, 7-1 application management service (AMS), 6-1, 6-4 G Garbage Collection, 3-1 asynchronous native interface (ANI), 5-5 garbage collector, accurate, 2-6 B garbage collector, mark-sweep, 2-6 blocking calls, 5-2 garbage collector, two generational, 3-1 C H class prelinker, 2-8 heap, structure of, 3-2 class prelinker utility (ROMizer), 10-1 HotSpot™ performance engine, 1-2 classes, ROMized, 4-1 hybrid threading coding style, 5-2 CLDC HotSpot Implementation, 1-1 CLDC HotSpot Implementation Porting Guide, 4-2 I in-place execution, 8-1 CLDC Hotspot Implementation, components, 2-1 in-place execution, security considerations, 8-1 CLDC Hotspot™ Implementation, key ideas, 2-1 integrated class prelinker, 2-8 CLDC libraries, 2-9 integrating in-place execution, APIs, 8-3 coding style, hybrid threading, 5-2 interpreter, optimized, 2-3 coding style, non-blocking scheduling, 5-2 isolate, 6-2 Coding Styles for Long-running Native Methods, 5- 2 isolate, API, 6-5 compiler, adaptive, 1-3, 2-2 isolate, compared to JSR 121, 6-2 compiler, ahead-of-time, 4-1 isolate, creating new, 6-7 Compiler, Dynamic, 2-2 Index-1
    • isolate, support in CLDC HotSpot R Implementation, 6-5 resource management in multitasking, 6-8 ROMizer utility, 10-1 J ROMizer, optimization options, 10-3 Java classes, synchronization of in multitasking, 6-8 ROMizer, options, 10-2 Jazelle, flags to enable, 9-1 ROMizer, running, 10-1 Jazelle, startup performance improvement, 9-1 ROMizer, supports for ahead-of-time compilation Jazelle™ support, 9-1 (AOT), 10-9 ROMizer, system class requirements, 10-2 K runtime verifier, 2-9 K Native Interface, 2-10 K virtual machine, 1-1 S KDWP support, 2-10 scheduling algorithm in multitasking, 6-9 KDWP, architecture, 11-1 segregated heap architecture, 3-1 KNI, 2-10 sni.h, 5-3 KVM, 1-1 Sun Java Wireless Client, multitasking in, 6-4 SVM mode, 6-1 L lightweight thread, 2-3 T long-running methods, compared to blocking native thread synchronization, 2-8 methods, 5-1 thread, lightweight (LWT), 5-1 LWT, 2-3 tunability of compiler, 4-2 LWT (lightweight thread), 5-1 tuning the dynamic compiler, 4-2 M U multitasking in CLDC HotSpot Implementation, 6-1 unified resource management, 2-5 multitasking in Sun Java Wireless Client, 6-4 V N virtual machine, performance of, 1-3 native methods, compared to blocking long-running methods, 5-1 near class, 2-4 non-blocking scheduling coding style, 5-2 O object heap, 3-2 object heap, new generation, 3-2 object heap, old generation, 3-2 object layout, compact, 2-4 OS thread, 2-3 P Porting Guide, CLDC HotSpot Implementation, 4-2 Index-2 CLDC HotSpot™ Implementation Architecture Guide • July 2006