Feature Archives | Feedback

PERC™ ROMizer™ offers time and space optimizations for embedded Java™ products

Dr. Kelvin Nilsen, President of NewMonics Inc.

This is a hypertext document. Read the section abstracts below and link to the sections you find most interesting.

Introduction
This article describes ROMizer, which is part of the PERC environment, that allows Java class files to be pre-loaded in preparation for placing them into ROM memory.

Performs byte-code verification of class files
Verifying byte codes protects the Java virtual machine from viruses and programming errors. In a PERC environment, system integrators can verify when classes are pre-loaded by the ROMizer.

Resolves symbolic references
When the ROMizer loads class files, it replaces symbolic references with numeric indexes and pointers that refer directly to the desired information.

Eliminates certain common constant subexpressions
Useful for eliminating redundant copies of symbolic string information.

Loads the specified class into a ROM image
Enumerates benefits of pre-loading classes instead of storing standard class-file representation in ROM.

Selective class loading
Why Java's dynamic class loader can be omitted from the ROM image.

Future ROMizer benefits

Faster execution
NewMonics is developing an optimizing ahead-of-time compiler

Smaller memory footprint
Using pre-run-time analysis techniques determines which variables and/or functions will not be required at run time.

Additional speed and memory footprint optimizations
The picoPERC software spec should offer a kernel subset less of less than 64 Kbytes of ROM compared to EmbeddedJava's 512 Kbyte footprint.

Introduction

PERC, a product of NewMonics Inc., is a clean-room implementation of the Java programming language designed to meet the special needs of embedded and real-time software developers. PERC provides real-time extensions to Java, including special timed and atomic control structures, and a set of class libraries implementing standard RTOS services in the form of a Java package named RealTime. See "Java brews better with Percolator on," published in the August 4, 1997 edition of Electronic Engineering Times for a description of the PERC real-time extensions.

Java is a high-level programming language which achieves portability across operating systems and CPU architectures by adopting a portable byte-code representation. Java programs are compiled into Java class files comprising the byte-code translations of the source code. "Java virtual machine" is the name given to the run-time environment that is required to execute programs represented as Java byte-code class files. Class files can be embedded in World Wide Web pages, distributed as e-mail attachments, or sold on CD-ROM disks as portable reusable software components.

PERC offers the same high-level benefits as Java, and adds capabilities designed to address the special needs of embedded real-time developers. An important component of the PERC development environment is the ROMizer, a tool that allows Java class files to be pre-loaded in preparation for placing them into the ROM memory of an embedded Java application. NewMonics' ROMizer is currently undergoing Beta testing. As currently designed, the ROMizer provides the following important capabilities:

Performs byte-code verification of class files
Java is designed to support secure dynamic loading of byte-code programs into a Java virtual machine. Dynamic loading means that new byte-codes can be loaded while previously loaded Java programs are executing. Secure dynamic loading means that the loader verifies that the loaded byte-code program is a legal program. The process of checking the loaded byte-code, which is known as byte-code verification, is important because it protects the virtual machine from viruses and inadvertent programming errors that might compromise valid operation of the interpreter.

Java was designed to be a secure programming language. It has no pointer arithmetic operations and all array subscripting operations include a check for index-out-of-bounds errors. As long as a Java program passes byte-code verification, the Java program is known to not violate the memory of any other Java tasks. Thus, there is typically no hardware memory-management protection in an embedded real-time system comprised entirely of byte-code verified Java tasks. For this reason byte-code verification is considered to be an essential component of a secure virtual-machine environment. With traditional Java implementations, byte-code verification is performed when classes are dynamically loaded. In a PERC environment, system integrators have the option of performing byte-code verification when classes are pre-loaded by the ROMizer.

Resolves symbolic references
Since Java supports dynamic class loading, Java class files use symbolic string names to describe references to information contained in other classes. This symbolic information allows for very late binding. In essence, Java defers the traditional process of linking object files together until the various byte-code programs are loaded into a virtual machine. When the ROMizer loads class files, it replaces symbolic references with numeric indexes and pointers that refer directly to the desired information. In the process of resolving symbolic references, certain byte-code instructions are replaced with instructions that can be interpreted more quickly than the fully portable symbolic instructions that are present in the class file representation.

Eliminates certain common constant subexpressions
Often, the same constant information is required in the representation of multiple independent classes. Rather than create multiple copies of certain common information, the ROMizer arranges to place only a single copy of this information into the resulting ROM image. This optimization is especially useful for eliminating redundant copies of symbolic string information.

Loads the specified classes into a ROM image
All of the classes processed by the ROMizer are output into a single file representing the raw bits that are to be burned into the ROM of the target embedded-computer system. The benefits of pre-loading classes using the ROMizer instead of storing the standard class-file representation in ROM is that (1) the embedded system boots up faster because it doesn't need to perform byte-code verification or resolve symbolic references as part of the booting up process; (2) memory requirements are reduced, thanks to the ROMizer's common constant subexpression elimination and because only a single ROM copy of each ROMized class is required; and (3) electric power requirements are reduced because the classes are represented in ROM rather than in RAM.

Selective class loading
The developer who builds an embedded-computer system decides which classes to put into the ROM image and which classes, if any, will be loaded dynamically. The dynamic class loader is itself a Java program. If a system designer chooses to ROMize all of the classes necessary for the embedded system and the system does not need the ability to dynamically load new classes, then the dynamic class loader can be omitted from the ROM image, further reducing the memory requirements of the PERC virtual machine.

Future ROMizer Benefits
The PERC ROMizer is a key component of the PERC family of embedded-system developer tools. Within NewMonics, enhancing the ROMizer is a high priority. Several exciting new capabilities are currently under development. These include ahead-of-time compilation, tree shaking, and support for standard PERC subsets.

Faster Execution
With funding support from the U.S. Defense Department's Advanced Research Projects Agency, NewMonics is working on an optimizing ahead-of-time compiler. This tool, which will be integrated into a future variant of the ROMizer, translates Java byte-codes into the native instruction set of the target computer. Based on preliminary analysis and early measurements, the translated programs will run much faster than existing virtual-machine interpreters and several times faster than most existing JIT translators. If all of the classes are compiled by the ROMizer and if there is no need to dynamically load new classes, then even the byte-code interpreter can be eliminated from the load image.

Smaller Memory Footprint
Tree shakers, long known to the Lisp programming community, are tools designed to reduce the size of the run-time environment required to support application software. Tree shaking works, whenever it is possible, through pre-run-time analysis to determine that certain variables and/or functions will not be required at run time. Based on this analysis, these unnecessary components are eliminated from the run-time memory image.

In Java, certain class information is characterized as private. This information is only visible within the class. By analyzing only that class, the tree shaker can determine that certain information that is part of that class representation is extraneous and eliminate it. Other information is identified as being visible only within a particular Java package (In Java, multiple classes are assembled into modules known as packages). If a system integrator tells the ROMizer that particular packages are complete and will not be extended by dynamically loaded classes, then the tree shaker can analyze the package-level information to determine which, if any, variables and functions can be eliminated from the generated ROM image.

The greatest savings come when the system integrator tells the ROMizer that the application is entirely self-contained and no new classes will be loaded dynamically. In this case, the tree shaker can do extensive analysis of the application program's call graph, determining exactly which other classes are referenced by the application program, and which variables and methods (functions) are required for each of the referenced classes.

Additional Speed and Memory Footprint Optimizations
picoPERC (not to be confused with picoJava, which is a hardware product) is a software specification, currently under development, for a layered sequence of standard PERC subsets. NewMonics projects that the core or kernel subset will require a combined total of less than 64 Kbytes of RAM and ROM. Contrast this with the 512-Kbyte footprint that Sun Microsystems, Inc. has projected for its yet-to-be-defined Embedded Java™ product.

At the core layer, the picoPERC virtual machine lacks support for floats and doubles, long integers, and Java's Unicode strings. Dynamic memory is reclaimed explicitly rather than by an automatic garbage collector. Real-time tasking is provided by low-level tasks that are much simpler than Java's standard Thread implementation. The core layer does not support dynamic loading, and thus depends on the ROMizer to configure the complete application.

picoPERC saves memory by pruning unnecessary functionality and by using explicit memory management in place of automatic garbage collection. It improves execution speed by eliminating the bookkeeping overhead required to support real-time garbage collection. Each picoPERC layer defines a different set of standard functionality which is added to the layer beneath it. Programmers can target their programs to a particular picoPERC layer, depending on which underlying services they require and the size of their memory budget. The picoPERC ROMizer will make sure that the application code does not use any features beyond what is available in the targeted picoPERC layer.

Additional Information
Refer to http://www.newmonics.com, http://www.isi.com, and http://www.vci.com for additional information about PERC.

Trademarks
PERC, pERC, picoPERC, Percolator,and ROMizer are trademarks of NewMonics Inc. Java and picoJava are trademarks of Sun Microsystems, Inc.


		Click here to get your listing up.