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.

• 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.