Realtime programming in Java: Part 2 - Embedded.com

Realtime programming in Java: Part 2

Since realtime programming usually involves sensing and controlapplications, the Real Time Specification for Java includes featuresfor accessing devices andreacting to external events.

The PhysicalMemory class provides a means of accessing data on memory mapped I/O devicesand the AsynEventHandler provides a mechanism for triggering processing based on an event suchas a signal, a timer, or a hardware interrupt. Together thesefacilities offer a rudimentary interface for writing device drivers.

Figure6: Device Access

Figure 6, above , illustratesaccessing an I/O mapped data channel. First a port address is writtenand then the port data is sent. Subsequently, a second port is writtenand then data is retrieved from the port and returned.

Figure 7, below , shows anevent handler to handle a simple POSIX signal. The routine just printsa message to the standard output stream whenever it is triggered. Bycombining an event handler with raw memory access, data can be sent orretrieved whenever an interrupt occurs.

Figure7: Asynchronous Event Handlers

Realtime Garbage Collection
In a system with fully deterministic, realtime garbage collection, thestrict separation of an application into realtime and non realtimethreads is not necessary. The strict splitting of an application isconsequently not required. Threads are activated based solely on theirpriorities.

Figure 8, below , illustratessuch a system. The JamaicaVM is a Java implementation that providesrealtime behavior for all threads by using a deterministic garbagecollector. The realtime garbage collector performs its work predictablywithin the application threads. It is activated when memory isallocated.

Figure8: Thread interaction with Realtime Garbage Collection

The work done at allocation time must be preemptable, so more urgentthreads can become active without delay. The implementation of arealtime garbage collector has to solve a number of technicalchallenges. Garbage collector activity must be performed in very smallbase increments of work.

In the JamaicaVM, one increment consists of garbage collecting only32 bytes of memory. On every allocation, the allocating thread pays forthe memory by performing a small number of these increments. The numberof increments can be analyzed, such that this is possible even inrealtime code.

A deterministic GC greatly extends the power of the RTSJ byeliminating the need to distinguish between threads that may use theheap and threads that may not.

Safety Critical Java
Though the RTSJ provides most of the features needed to write realtimeprograms using Java technology, it was not designed for safety criticalapplication per se. The RTSJ is defined as an extension to the Javalanguage resulting in a language that is too complex for the currentcertification processes such as DO-178B used in aviation.

Garbage Collection is a particular problem for certificationauthorities due to its inherent dynamic nature. Therefore there is astandardization effort going on in The Open Group to propose a subsetof both the RTSJ and Java for safety critical applications. A newconfiguration for Java 2 Micro Edition incorporating core elements ofthe RTSJ and excluding a garbage collector is planned.

Application written for this safety critical subset would still berunnable on a full RTSJ enabled Java virtual machine. When completed,safety critical Java would extend Java technology from the enterpriseall the way down to the most critical control applications.

Open Issues
The RTSJ is an important step in the development of Java technology;however, the specification still has weaknesses. As mentioned above,the size issue is being addressed by the safety critical Java effort.More fundamentally, there are the issues of device access and controltransfer. The Java language collection API is also less than ideal interms of memory consumption.

Though RawMemoryAccess offers a means of accessing device registersthat are memory mapped it provides neither access to I/O channels norproper type casting and data width control. For example, an I/O cardwith two 16 bit unsigned values must be assembled and masked from handinto an appropriate pair of int values. Though the I/O channel could beprovided for by an additional memory area, no such area exists.

How interrupts are to be mapped into RTSJ happenings is simply leftto the implementation. This means that although the handler itself canbe written to be portable, device management itself is not. In fact,there is no standard way to describe devices at all. In any case,interrupt handlers in the RTSJ are limited to second level interrupthandling.

Finally, enumerations and iterators are problematic when used withScopedMemory .They result in an allocated object being passed back froma call. Using the visitor pattern would be much better. In thispattern, instead of getting an object back, the caller would provide anobject which implements a Visitor interface.

This interface would define a special method with one argument, anelement in the collection. The method would then be called once foreach element in the collection. This solution not only would makememory management more efficient and work properly with memory scoping,but it would also be easier to synchronize properly as well.

Still the RTSJ is a major advancement for realtime programming andfuture versions of the specification are likely to address these andother realtime programming issues.

Conclusion
Even though a number of technical challenges had to be solved, theReal-Time Specification for Java now provides a standard that enablesthe development of time critical software using the Java language.Commercial implementations exist from at least three vendors.Consequently, Java technology can now be used for programming embeddedand realtime systems.

The RTSJ provides a solution for realtime programming, but it alsobrings new difficulties to the developer. The most importantconsequence is that applications have to be split strictly into twoparts: a realtime and a non realtime part. Communication between theseparts is heavily restricted.

Realtime threads cannot perform memory operations such as theallocation of objects on the normal heap which is under the control ofthe garbage collector. Synchronization between realtime and nonrealtime threads is limited since sharing a monitor with a normal Javathread would allow the realtime threads to blocked by the garbagecollector.

The advantages of using the features of Java technology and the RTSJare even higher when realtime garbage collection is used. A fullydeterministic GC does not oblige realtime threads to suffer from therestriction of not using the heap. Realtime GC along with the RTSJbrings the full benefits of Java technology to the development ofrealtime systems.

To read Part 1 in this series, gotoInadequacies of Java for realtime programming.

Dr.James J. Hunt, is CEO, and Dr.Fridtjof B. Siebert is CTO at real time Java developer aicas GmbH in Karlsruhe, Germany.

References
[1] Greg Bollella. Real-TimeSpecification for Java. Addison-Wesley, 2001.
[2] Peter C. Dibble. Real-TimeJava Platform Programming. Prentice Hall, 2002.
[3] Hija, high-integrity Java.www.hija.info,2004-2006
[4] Jamaica virtual machine.www.aicas.com/jamaica,1999-2005.
[5] The real-time for Javaexpert group (RTIEG ).
[6] Fridtjof Siebert. HardRealtime Garbage Collection in Modern Object OrientedProgramming Languages. aicas Books, 2002.

This article is excerpted from a paper of the same name presentedat the Embedded Systems Conference Silicon Valley 2006. Used withpermission of the Embedded Systems Conference. For more information,please visit www.embedded.com/esc/sv.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.