Apogee's
JREs are advanced software middleware for reliable execution of Java applications on embedded systems used in many types
of devices, from cell phones and PDAs to set-top boxes and sophisticated
Telematics devices.
Apogee’s
JREs are based on Java technologies licensed in form of reference implementations from IBM, such as the
J9VM, JIT compiler, Java class libraries, and Java API packages, which are enhanced by
Apogee for effective use on the targeted devices and for fast execution of Java
applications on such devices.
Apogee
creates each JRE by porting to the OS/processor platform requested by a given
customer suitable reference implementations of J9VM and JIT compiler, thus
creating a base JRE, or by adapting for this platform one of the existing base
JREs. Then, Apogee adds to the base JRE the OS/processor ports of optional components needed by customer's Java applications, and tunes the JRE for fast execution of such applications. This results in the final JRE in
one of the following two configurations:
- MJRE (Micro edition JRE) fully compatible with Sun’s Java ME
CDC platform.
- CJRE (Custom edition JRE) compatible with Sun’s Java 5
platform with respect to being capable of running the Java 5 compatible Java
applications and optionally supporting the customer-requested Java 5 features
(e.g. assertions)
Each
MJRE can be certified as compliant with the Java ME platform, in which case the devices having the MJRE deployed on them can be distributed with Sun's
"steaming coffee cup" logo and/or "Java Powered"
slogan.
Each CJRE includes the implementations of most of Java 5 features. However, some features requiring runtime support from the underlying VM may not be fully implemented. For example assertions are accepted but not acted upon. In such situations, a customer can request Apogee to add the full runtime support for each such feature to its CJRE, such as Reflection of Generics, Annotations, Metadata, etc.
Features of Apogee’s JREs
Apogee's
JREs offer the following features not offered in their entirety by JREs from
other providers, including Sun and IBM.
- Facilitate reliable and high performance deployments of Java
applications on devices based on the following types of embedded processors
running Linux or other commonly used operating systems:
- x86, ARM, XScale, MIPS, PowerPC, or SH4 processors running
Linux, including any of the “embedded” Linuxes.
- x86, ARM, or XScale processors running Windows Mobile or
Windows CE.
- x86, PowerPC, ARM, XScale, or MIPS processors running
VxWorks.
- x86, PowerPC, or MIPS processors running LynxOS, Neutrino,
Integrity, or BSD UNIX.
- Can be targeted at many types of devices, including:
- Wireless communication devices (cell phones and other
'hand-helds', telemetrics devices, navigational and global positioning systems, etc.).
- Electronic consumer appliances (smart phones, PDAs, set-top
boxes, residential gateways, etc.).
- Internet devices (residential hubs, routers, distributed
servers, etc.).
- RFID readers, 'edge' servers, and premises servers.
- Industrial devices (monitors, controllers,
gateways, robots, etc.).
- Devices used in distributed enterprise management systems.
- Point-of-sale terminals including the PoS terminals with color
touch-screens, and premises controllers of such terminals.
- Telematics and infotainment devices.
After Apogee licensed
IBM's Java technologies in 2003, it created at least one MJRE or CJRE for each
of the above types of devices (over 50 JREs in total).
- Can run many kinds of Java applications, including:
- Large and/or complex applications for advanced devices, such
as the set-top boxes, multi-purpose residential gateways, Internet routers, Telematics and
Infotainment devices, etc.
- Applications compatible with the Java 5 platform, which can optionally use the Java 5 features relevant to embedded systems.
- Applications the components of which are available in form
of dynamically loaded OSGi bundles or CORBA objects.
- Applications that use client-side "runtimes" and/or
application-level packages from Apogee's extensive offering of such runtimes
and packages (for example, the Tomcat servlet container or Jetty web server).
- Applications that use advanced graphics, including the Java
SE AWT & Java2d graphics, as well as graphics created with Sun's Swing widget
toolkit.
- Applications that use extensively the C/C++ native methods.
- Applications that need fast access to the Internet.
- Real-time Java applications and, in near future, safety-critical
Java applications.
- Each JRE can be provided in a development configuration
highly suitable for testing, debugging, profiling, and performance tuning of Java
applications, which effectively facilitates:
- Remote (from a Windows/x86 or Linux/x86 development
platform) debugging and profiling of Java applications during the runtime execution
of their JAR files on the development JRE.
- Tracing of Java heap allocations, garbage collections, and
executions of Java threads.
- Dynamic dumping of Java heap or selected portions of Java
heap.
The obtained tracing and
dumping information can be used to minimize heap allocations and garbage
collections, and to reduce the multi-threading overhead.
- Each JRE can be provided in a configuration customized for
runtime execution on multi-core processors, in which case:
- Its port of J9VM concurrently executes multiple Java threads
of a given Java application on multiple cores of the target processor.
- Its JIT or JAOT compiler produces native (binary) methods
for bytecode methods in multiple Java threads, which are concurrently executed
on multiple cores of the target processor.
- The interpreter loop of its port of J9VM and the code
generator of its JIT compiler are adapted to work effectively with the
multi-threading support provided by the OS.
- For the memory-constrained devices, each JRE can be provided
in a configuration that can be directly executed from a flash memory, as long as a given device has a sufficiently large flash memory
with the fast access time, and the OS running on the device supports such execution.
- Each graphics-supporting MJRE includes a port of
IBM's Universal Graphics Library (UGL) or, in case of the OS
that is not yet supported by UGL, a port of eSWT (embedded Software Widget Toolkit) from
Eclipse.org. Either of these ports
provides a thin transition layer between the Java ME AWT APIs and graphical functions of a low-level graphics library (LLGL) that comes with the OS (GTK2 + X-Server that come with most Linuxes,
or GDI that comes with Windows Mobile or Windows CE).
- Each graphics-supporting
CJRE includes the ports of java.awt, Java2D, and (for applications having the graphics created with Sun's Swing widget toolkit) javax.swing packages
from the Harmony class library. The graphics APIs of these packages are enhanced to work effectively with a port of X-Server LLGL or DirectFB runtime library provided by a given customer or created by Apogee. Note that Apogee is the first and only provider of graphics-supporting JREs that have the java.awt, Java2D, and javax.swing packages
from Harmony working directly and effectively with the DirectFB runtime libraries.
- Each JRE can be provided in a configuration enhanced for effective
use on RFID readers, "edge" servers, and other RFID-enabled devices
by including in it the ports of:
- The RFID runtime from IBM's RFID Data Capture and Delivery
product offering, which allows JRE to receive and transmit the RFID signals.
- Apogee's LLRP adapter that makes the JRE to execute Java applications conforming to LLRP (Low Level Reader Protocol, a common
I/O protocol defined for the RFID devices by EPC Global consortium).
- Each JRE can be provided with IBM's JXE Linker tool, which
performs the following functions to reduce the runtime footprint of the deployed
JRE when executing Java applications:
- Analyzes the uses of Java classes and methods in JAR
file(s) of a given Java application and in JAR files of Java-written components of
the JRE (the JAR files of Foundation Class Library or Harmony, for example).
- Removes from each analyzed JAR file the Java classes that
are not actually used.
- Removes from each remaining class file the bytecode
methods that are not actually used.
- Optionally (if requested by the user) creates a single
ROMable image, which has only the actually used Java classes of the application
and JRE components, and which includes the executable files of ports of J9VM,
JIT compiler, and all other components of JRE
Features of IBM’s J9VM Technology
Originally developed
by IBM over 15 years ago in a clean-room environment, and continuously enhanced and improved since
then, the J9VM technology is based on a configurable architecture that allows
its effective use for most types of embedded processors running
popular operating system.
The J9VM technology
is highly portable, because it has an operating-system-independent layer that allows
productive use of needed resources from an underlying OS and, at the same time,
shields the other parts of J9VM from the idiosyncrasies of such an OS.
The J9VM
technology also provides a wide range of settings with respect to the supported
functions. For example, it allows static or dynamic class loading, configuring
of memory usage for the Java heap and loaded JAR files of Java applications, tuning
of garbage collection to minimize its impact on runtime performance, and guiding
the JIT compiler to achieve maximum speed-ups of executing Java applications.
The
J9VM technology has the following features not available in their entirety in Java
VM technologies from other providers.
- Based on the clean bottom-up design.
- Its performance-critical parts are written in assembler.
- Can be used in a multi-core/multiprocessor environments.
- Fully supports effective local/remote debugging.
- Provides the plug-ins for class libraries and API packages.
- Works cooperatively adn effectively with the integrated JIT or JAOT compiler.
- Comes with a fast, accurate, and configurable generational garbage collector.
- Is configurable at three levels:
- At build time: changing the VM-OS code or Application code,
enabling the use of space-optimized ROMable images produced by JXE linker, changing the thread model or scheduler.
- At integration time: selecting the desired set of modules
and removing unneeded shared objects (math, dbg, zip, jxe, etc.).
- At runtime: using command options for changing the default
memory settings or garbage collector characteristics and controlling the
JIT compiler.
- Allows three memory settings:
- Set memory maximum to a desired limit.
- Set ROM class segment to a desired increment.
- Set RAM class segment to a desired increment.
- Allows tuning of the garbage collector:
- Define a desired remembered set size.
- Set maximum memory to a desired limit.
- Set a size of space for "old" objects to a desired limit.
- Set "old" space increment to a desired limit.
- Set a size of space for "new" objects to a desired limit.
To
make the J9VM technology more usable for use in Apogee's JREs, Apogee enhanced it
in the following areas:
- The class loader loads more rapidly the JAR files of large
Java applications that have many Java classes and/or use many C/C++ written
native methods.
- The JNI (Java Native Interface) handles more effectively the
Java programs that use a lot of native methods, and passes more rapidly the
native methods and their arguments to the underlying OS/processor platform for
native execution.
- The bytecode verifier can be turned off in each
deployment-ready JRE, after the JAR files of all Java applications that will be
running on the JRE were verified for correctness.
- The interpreter loop and other relevant parts of J9VM
provide the full support for:
- More extensive debugging and profiling of Java applications.
- Tracing of Java heap allocations, garbage collections, and
executions of Java threads.
- Dynamic dumping of Java heap or selected portions of Java
heap.
The
J9VM technology is provided to Apogee in form of reference implementations
(RIs) targeted at popular types of embedded processors running commonly used
operating systems. These RIs are ported by Apogee to devices requested by Apogee’s
customers and optimized for high performance when running customers’ Java
application on them.
Features of IBM’s JIT Compiler Technology
Each
Apogee’s port of J9VM comes with integrated IBM’s 'small' JIT compiler called
Cinquecento. Unlike the 'large' JIT compiler used with IBM's Java SE
and Java EE configurations of J9VM, or the JIT compilers used in Java VMs of other providers of JREs,
which have the runtime footprints 2 to 3 Mbytes, Cinquecento runtime footprint
is 0.6 to 1.2 Mbytes depending on the target processor and the selected
options.
In addition, Cinquecento is remarkably
fast when compiling bytecode methods of Java applications into native code,
because it only applies such optimizations to the compiled methods that yield high speed
ups without requiring extensive analysis of bytecode of each method.
In
spite of its small size and fast compilation speed, Cinquecento typically
speeds up the runtime execution of most Java applications by 5 to 8 times of compared
with 100% interpretive execution of such applications.
The
use of Cinquecento is controlled with the -Xjit directive, which includes a
number of options for instructing Cinquecento to selectively compile the
bytecode methods of a given Java application for the highest possible runtime execution
speed-up. There are three set of such
options:
- Code generation options, for example the options for
defining the code cache size, data cache size, and compilation thread stack
size.
- Optimization options, for example:
- Setting the number of invocations of each method containing a
loop before it is compiled into native code.
- Setting the number of invocations of each method that does not
contain a loop before it is compiled into native code.
- Providing a list of methods that should not be compiled.
- Providing a list of methods that should not be in-lined.
- Turning selectively off specific optimizations, such as: array copy
optimizations; basic block extension; generation of direct memory instructions;
direct calls to JNI; floating point code generation; floating point code
emulation; global register allocation; all in-lining; in-lining of natives;
local common sub-expression elimination; local value propagation; redundant GOTO elimination; instruction scheduling; tree simplification; verification of
internal data structures between passes; etc.
- Debugging options, for example insert entry break point instruction
in generated code.
-
Recompilation and profiling options, for example setting the number of
milliseconds between samples for “hotness” of methods for JIT compilation.
To
make the JIT technology more usable for use in Apogee's JREs, Apogee enhanced it in
the following areas:
- The compiler-produced native (binary) methods are in a
"direct JNI format", which allows their rapid invocation and native
execution on the underlying target processor.
- The code generator of each port of JIT technology is
optimized to produce the most effective native (binary) code for execution on a
given target processor.
-
The JIT technology used in JAOT compilers includes a special
Apogee-invented "fuzzy logic", which identifies the bytecode methods
in each JAR file about to be executed on a given RTSJ JRE that are most
suitable for compilation into native (binary) methods.
|