This document provides an architecture guide for the CLDC HotSpot Implementation virtual machine. It describes the key components and features of CLDC HotSpot Implementation, including its dynamic compiler, threading system, multitasking support, ahead-of-time compilation, in-place execution, Jazelle option, ROMizer utility, and Java programming language debugging support. The guide is intended for engineers porting or implementing CLDC HotSpot Implementation.
Top 5 Benefits OF Using Muvi Live Paywall For Live Streams
CLDC HotSpot Guide: Optimize Java Performance
1. CLDC HotSpot™ Implementation
Architecture Guide
CLDC HotSpot Implementation, Version 1.1.3
Java™ ME Platform
Sun Microsystems, Inc.
www.sun.com
July 2006
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