HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

PERC is the embodiment of the technologies described in last month's article. PERC is a commercial clean-room implementation of Java designed specifically to address the needs of developers of embedded and real-time systems.The PERC acronym stands for Portable Executive for Reliable Control. PERC is intended to serve a spectrum of real-time application domains ranging from simple multimedia entertainment software for children to highly complex hard-real-time applications critical to the nation's defense systems. The intention is to standardize this programming notation as a common platform for the development of shared real-time software development tools and reusable real-time software components. Clearly, the rigor with which particular applications need to comply with real-time constraints depends on price and performance issues and risk analyses that are different for each application. The design of PERC is such that individual developers can choose to handle these tradeoffs differently.

PERC is a superset of Java in that it offers additional syntax and additional time and memory related semantics to the Java programmer. However, it is a subset in that it forbids certain legal Java practices in situations where the use of these practices would interfere with the system's ability to support reliable compliance with real-time requirements. In particular, there are certain contexts in which PERC must be able to analyze the time required to execute particular code segments. In these contexts, PERC disallows the use of code that cannot be efficiently analyzed.

The PERC development and execution environment is illustrated in Figure 1. PERC syntax includes two control structures that are not a part of standard Java. These are the timed and atomic statements, which will be described in next month's column. Thus, PERC source code cannot be directly compiled by traditional Java compilers. The preprocessor, p2jpp, converts the timed and atomic statements into standard Java source code. The output of p2jpp is ready for a traditional Java compiler, such as Sun's javac. Note that PERC source code can also be translated directly to Java byte codes by the Percolator program. Percolator outputs byte codes that are essentially the same as what is generated by Sun's javac. However, the class files emitted by Percolator also include special attribute information to identify particular parts of the program that require real-time determinism. The PERC virtual machine uses this attribute information to assist in its analysis of worst-case execution times and to enable it to perform transformations on the byte code that will allow the real-time program to run much faster than would be possible without the transformations.

Figure 1
Figure 1

Execution of PERC programs on a traditional Java virtual machine with accompanying PERC libraries is less efficient and less predictable than execution on a PERC virtual machine. For example, the traditional Java virtual machine:

  1. Does not understand the special attributes that are inserted by Percolator. As a result, it is not able to perform the transformations necessary to improve performance and determinism.
  2. Is unable to perform schedulability analysis so it cannot guarantee that real-time tasks will execute within their real-time constraints.
  3. Lacks the ability to distinguish between memory allocated to different real-time activities. Thus, it cannot enforce memory budgets on particular real-time tasks.
  4. Probably lacks support for real-time garbage collection. Thus, there is no way for the PERC program to configure the system's garbage collector to support a guaranteed rate of new memory allocation.
Nevertheless, for applications that are constrained by real-time expectations, executing PERC on a traditional virtual machine offers important benefits over attempting to achieve real-time determinism without the use of PERC extensions. In particular:
  1. Application programmers are provided with standard notations in which to encode the desired real-time behavior as part of their source program. This contributes to the ease of long-term software maintenance.
  2. Though the execution environment may not be able to satisfy all of the desired real-time constraints, the PERC libraries are able to determine where real-time performance is falling short. This information can be used by the run-time system and the application code itself to dynamically adjust service quality and load balancing.
Of course, for best performance and real-time determinism, it is desirable to run the PERC byte codes on a PERC virtual machine.

About the Author
Kelvin Nilsen is president of NewMonics Inc., a small start-up company that is actively developing the PERC technologies described in this column.


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: info@sys-con.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.