SlideShare uma empresa Scribd logo
1 de 80
Baixar para ler offline
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
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture
Cldc Hotspot Architecture

Mais conteúdo relacionado

Semelhante a Cldc Hotspot Architecture

Virtualization & Network Connectivity
Virtualization & Network Connectivity Virtualization & Network Connectivity
Virtualization & Network Connectivity itplant
 
GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...
GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...
GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...Juarez Junior
 
Solution Architecture for Mailbox Archiving 5,000 Seat Environment
Solution Architecture for Mailbox Archiving 5,000 Seat EnvironmentSolution Architecture for Mailbox Archiving 5,000 Seat Environment
Solution Architecture for Mailbox Archiving 5,000 Seat EnvironmentCorporate Technologies
 
SevillaJUG - Unleash the power of your applications with Micronaut® ,GraalVM...
SevillaJUG - Unleash the power of your applications with Micronaut®  ,GraalVM...SevillaJUG - Unleash the power of your applications with Micronaut®  ,GraalVM...
SevillaJUG - Unleash the power of your applications with Micronaut® ,GraalVM...Juarez Junior
 
VxWorks - Holistic Security (Art of Testing)
VxWorks - Holistic Security (Art of  Testing)VxWorks - Holistic Security (Art of  Testing)
VxWorks - Holistic Security (Art of Testing)Aditya K Sood
 
A fun cup of joe with open liberty
A fun cup of joe with open libertyA fun cup of joe with open liberty
A fun cup of joe with open libertyAndy Mauer
 
Requirement for creating a Penetration Testing Lab
Requirement for creating a Penetration Testing LabRequirement for creating a Penetration Testing Lab
Requirement for creating a Penetration Testing LabSyed Ubaid Ali Jafri
 
Apache Tomcat 7 by Filip Hanik
Apache Tomcat 7 by Filip HanikApache Tomcat 7 by Filip Hanik
Apache Tomcat 7 by Filip HanikEdgar Espina
 
Ecc6 sr3 ora_win_instguide
Ecc6 sr3 ora_win_instguideEcc6 sr3 ora_win_instguide
Ecc6 sr3 ora_win_instguideyashkr571
 
The Java EE 7 Platform: Developing for the Cloud (FISL 12)
The Java EE 7 Platform: Developing for the Cloud  (FISL 12)The Java EE 7 Platform: Developing for the Cloud  (FISL 12)
The Java EE 7 Platform: Developing for the Cloud (FISL 12)Arun Gupta
 
TDC 2011: The Java EE 7 Platform: Developing for the Cloud
TDC 2011: The Java EE 7 Platform: Developing for the CloudTDC 2011: The Java EE 7 Platform: Developing for the Cloud
TDC 2011: The Java EE 7 Platform: Developing for the CloudArun Gupta
 
Crap shit head
Crap shit headCrap shit head
Crap shit headShash
 
Groovy & Grails for Spring/Java developers
Groovy & Grails for Spring/Java developersGroovy & Grails for Spring/Java developers
Groovy & Grails for Spring/Java developersPeter Ledbrook
 
Build your first DApp using Substrate Framework - Part I
Build your first DApp using Substrate Framework - Part IBuild your first DApp using Substrate Framework - Part I
Build your first DApp using Substrate Framework - Part IKnoldus Inc.
 
Enterprise manager cloud control 12c(12.1) &agent安装图文指南
Enterprise manager cloud control 12c(12.1) &agent安装图文指南Enterprise manager cloud control 12c(12.1) &agent安装图文指南
Enterprise manager cloud control 12c(12.1) &agent安装图文指南maclean liu
 
Analyzing the Performance of Mobile Web
Analyzing the Performance of Mobile WebAnalyzing the Performance of Mobile Web
Analyzing the Performance of Mobile WebAriya Hidayat
 
Learning AOSP - Building AOSP for Nexus 7
Learning AOSP - Building AOSP for Nexus 7Learning AOSP - Building AOSP for Nexus 7
Learning AOSP - Building AOSP for Nexus 7Nanik Tolaram
 
GWT Introduction and Overview - SV Code Camp 09
GWT Introduction and Overview - SV Code Camp 09GWT Introduction and Overview - SV Code Camp 09
GWT Introduction and Overview - SV Code Camp 09Fred Sauer
 

Semelhante a Cldc Hotspot Architecture (20)

Virtualization & Network Connectivity
Virtualization & Network Connectivity Virtualization & Network Connectivity
Virtualization & Network Connectivity
 
GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...
GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...
GeeCon Prague 2023 - Unleash the power of your applications with Micronaut®, ...
 
Solution Architecture for Mailbox Archiving 5,000 Seat Environment
Solution Architecture for Mailbox Archiving 5,000 Seat EnvironmentSolution Architecture for Mailbox Archiving 5,000 Seat Environment
Solution Architecture for Mailbox Archiving 5,000 Seat Environment
 
SevillaJUG - Unleash the power of your applications with Micronaut® ,GraalVM...
SevillaJUG - Unleash the power of your applications with Micronaut®  ,GraalVM...SevillaJUG - Unleash the power of your applications with Micronaut®  ,GraalVM...
SevillaJUG - Unleash the power of your applications with Micronaut® ,GraalVM...
 
VxWorks - Holistic Security (Art of Testing)
VxWorks - Holistic Security (Art of  Testing)VxWorks - Holistic Security (Art of  Testing)
VxWorks - Holistic Security (Art of Testing)
 
A fun cup of joe with open liberty
A fun cup of joe with open libertyA fun cup of joe with open liberty
A fun cup of joe with open liberty
 
OpenGL Spec 4.4 Core
OpenGL Spec 4.4 CoreOpenGL Spec 4.4 Core
OpenGL Spec 4.4 Core
 
Requirement for creating a Penetration Testing Lab
Requirement for creating a Penetration Testing LabRequirement for creating a Penetration Testing Lab
Requirement for creating a Penetration Testing Lab
 
Apache Tomcat 7 by Filip Hanik
Apache Tomcat 7 by Filip HanikApache Tomcat 7 by Filip Hanik
Apache Tomcat 7 by Filip Hanik
 
SCALE 10x Build a Cloud Day
SCALE 10x Build a Cloud DaySCALE 10x Build a Cloud Day
SCALE 10x Build a Cloud Day
 
Ecc6 sr3 ora_win_instguide
Ecc6 sr3 ora_win_instguideEcc6 sr3 ora_win_instguide
Ecc6 sr3 ora_win_instguide
 
The Java EE 7 Platform: Developing for the Cloud (FISL 12)
The Java EE 7 Platform: Developing for the Cloud  (FISL 12)The Java EE 7 Platform: Developing for the Cloud  (FISL 12)
The Java EE 7 Platform: Developing for the Cloud (FISL 12)
 
TDC 2011: The Java EE 7 Platform: Developing for the Cloud
TDC 2011: The Java EE 7 Platform: Developing for the CloudTDC 2011: The Java EE 7 Platform: Developing for the Cloud
TDC 2011: The Java EE 7 Platform: Developing for the Cloud
 
Crap shit head
Crap shit headCrap shit head
Crap shit head
 
Groovy & Grails for Spring/Java developers
Groovy & Grails for Spring/Java developersGroovy & Grails for Spring/Java developers
Groovy & Grails for Spring/Java developers
 
Build your first DApp using Substrate Framework - Part I
Build your first DApp using Substrate Framework - Part IBuild your first DApp using Substrate Framework - Part I
Build your first DApp using Substrate Framework - Part I
 
Enterprise manager cloud control 12c(12.1) &agent安装图文指南
Enterprise manager cloud control 12c(12.1) &agent安装图文指南Enterprise manager cloud control 12c(12.1) &agent安装图文指南
Enterprise manager cloud control 12c(12.1) &agent安装图文指南
 
Analyzing the Performance of Mobile Web
Analyzing the Performance of Mobile WebAnalyzing the Performance of Mobile Web
Analyzing the Performance of Mobile Web
 
Learning AOSP - Building AOSP for Nexus 7
Learning AOSP - Building AOSP for Nexus 7Learning AOSP - Building AOSP for Nexus 7
Learning AOSP - Building AOSP for Nexus 7
 
GWT Introduction and Overview - SV Code Camp 09
GWT Introduction and Overview - SV Code Camp 09GWT Introduction and Overview - SV Code Camp 09
GWT Introduction and Overview - SV Code Camp 09
 

Último

Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 

Último (20)

Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 

Cldc Hotspot Architecture

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