Atego's PERC Ultra stack includes a profiler
I hear from many embedded programmers that their hard real time projects are always done in C because that is the only way to get real time response. Many even shy away from C++ and C# or Java are rarely in the mix. I’ve cover RTSJ and Atego’s PERC products for a number of years so I am more familiar than most with Java in the real time realm. I finally had a chance to check out the PERC virtual machine (VM) and I found it both very transparent from a Java point of view to very powerful from a real time view.
I’ll leave the discussion of the Real Time Specification for Java (RTSJ ), the Java Community Process JSR-1 standard, and more details about PERC to related articles that are linked to this article. RTSJ is actually a very extensive standard because it is such a complete real time specification. Rarely will an application take advantage of even a large fraction of the standard.
Three issues that tend to come up in a discussion of real time Java include: compilation issues, garbage collection, and real time control. Conventional ahead-of-time (AOT) compilation is an option in addition to the usual just-in-time (JIT) Java compilation. AOT addresses on aspect of the compilation. Likewise, Java compilers can crank out code on par with the most efficient C compilers. Of course, consistent code is actually more important in a real time environment although everyone likes more compact and efficient code. Real time garbage collection is a standard part of real time JVMs. The discussion of real time garbage collection is beyond the scope of this article but, in general, real time garbage collection is as efficient or more efficient than manual memory management and less prone to errors. Finally, RTSJ addresses real time interfaces that is better than any C implementation I have seen.
Atego has a number of real time Java products that address a range of platforms and applications. The PERC Ultra product targets single core platforms. It is essentially a Java 2 Standard Edition (J2SE) that supports the real time extensions including real time garbage collection. Atego’s PERC Ultra SMP extends PERC Ultra to a multicore environment. The PERC Pico and PERC Raven platforms move in the other direction. PERC Pico targets more compact platforms that tend to have more limited memory facilities.
Sun is now part of Oracle and real time concerns are less of an issue to the database giant although even a small interest on Oracle’s part is a significant investment of time and money. Sun does have a major RTSJ implementation and there are other alternatives in the real time Java space such as DDC-I. For now we take a closer look at Atego’s PERC Ultra offering.
Installation and Operation
Atego supports a number of platforms but the x86 platform is one of the primary ones Atego offers. It is also the one I tested. I looked at the PERC Ultra and PERC Ultra SMP but, as expected, did not find much difference in terms of installation and operation. This is like discussing the difference between an SMP operating system running on a single core versus multicore platform. There are core related functions but these tend to be minor issues and ones rarely encountered by developers.
The products come on CDs that target a particular platform, like the x86, and development platform such as Windows or Linux. I checked out the development platform on Windows XP and Fedora Linux. There was effectively no difference between the two. The virtual machine is the core of the product but IDE integration and samples are part of the puzzle as well. Installation of the VM tends to be a manual process because it may be utilized without an IDE. Likewise, the VM will used in the target system that may be different than the development platform. I was able to test out applications on the development platform since I was using Linux. PERC can run with a range of operating systems including a large number of real time operating systems from the likes of Lynuxworks, Wind River and QNX. The printed and online documentation address the installation process. It was not very difficult and only takes an hour or less to get everything straight. Of course, it only needs to be done once.
Luckily, the main IDE that is supported by the platform is Eclipse. I have used Eclipse for ages. It also has the advantage of being the base for most of the development tools in this space such as Wind River’s WorkBench, QNX Momentics, and Lynuxworks Luminosity. Other IDE support includes popular platforms like JBuilder and Forte.
The setup of the VM and IDE plug-ins, including the PERC console shell, is the same for any Eclipse-based IDE. One of the useful additions is the online help for the added real time methods. This turns out to be very handy once I started taking advantage of these classes and methods. Configuration for remote debugging was simple and obviously necessary when the target is different than the development platform. I did not try configuring the TFTP class loader since I was working with higher end x86 PC platforms.
The AOT compilation and linking were one things that was different from normal Java development but it is essentially the same as C and C++ development. In general, a project will usually be all AOT or JIT but mixing the two is not difficult. It is just a matter of configuring the making process.
The ROMizer enables execution from ROM using AOT. I didn’t have a need to do more than run through the process since my targets did not have ROM but the process is simple. Like AOT, this is something that is part of the make configuration One thing I did not try was using PERC’s JNI (Java Native Interface) or the more compact PNI(PERC Native Interface). JNI will provide more portability, in theory, but it obviously must match any underlying programming alternative, typically C.
I also checked out the profiler support. This is extremely important for real time applications. It is inherent in the system and utilizes the standard Java Agent class support.
Real Time Summary
Working with Atego’s PERC Ultra turned out to be relatively uneventful having done Java development with Eclipse for awhile now. Things got more interesting when playing with the real time and garbage collection methods. I’m definitely not well versed in their use but they are straight forward and standard. Moving an existing Java application to PERC is essentially transparent. Moving a real time application to a different RTSJ platform should be straight forward.
I did want to add a couple notes about PERC’s garbage collector. First, not having the system stop for garbage collection is very nice. There is no application hesitation. This is due to pacing that keeps the garbage collector ahead of memory requirements. Second, the garbage collector can be preempted. On a typical system, the latency is 150 microseconds. Native tasks or device drivers can interrupt the system with normal interrupt latency but they cannot call Java methods. On the other hand, they can enable Java threads that will run at the next scheduling interval.
Deciding to use PERC for real time applications obviously takes a good bit of consideration especially if developers are more versed in C or C++. On the other hand, real time Java offers significant benefits including real time garbage collection. Migration from a conventional Java platform to PERC should be relatively trivial. Test applications I wrote for J2SE worked fine under PERC. PERC’s real time garbage collector is deterministic, incremental, defragmenting, precise, and paced. That will benefit even soft real time applications.
From a tools standpoint, PERC represents a familiar and solid platform. Check out Atego’s website if you are interested in testing PERC yourself. Next time I will have to try PERC on a platform like Freescale’s Power platforms or an ARMv4-based system.