Sovereign Software

At the dawn of the PC Age, when it became clear that the Intel 8086 architecture had a future, but before the term "x86" entered the lexicon, several companies introduced "integrated software." Everyone hoped productivity would improve as employees used word processing, spreadsheet, database, graphics, and communication programs lumped under a more-or-less common user interface. It didn't quite work out that way.

What actually happened was Windows, where the OS enforced a more-or-less common user interface on every program. As a result, you could readily collect and use disparate best-of-breed programs, rather than endure whatever a single vendor could lash together. Microsoft Works, Lotus SmartSuite, and (whoever owns) WordPerfect Office seem to be the last remnants of that era, each sufficient for most purposes and often given away (that's pronounced "bundled") with new PCs.

Software-development tools lag about a decade behind the mass-market technology that pays the bills, so it's only recently that full-throttle Integrated Development Environments have come to fruition. Yes, Borland's Turbo Pascal 1.zilch sported a larval IDE back in '83-ish, but the concept didn't sprout wings until a decade later when Windows made it feasible. Now, one must look to Linux for command-line compilers and linkers.

IBM's Object Technology International subsidiary (http://www.oti.com/) produces the well-regarded VisualAge IDE for embedded Java. OTI's VisualAge Micro Edition (VAME) includes the specializations required for the Java2 Micro Edition subset of the Java language and classes, along with support for the various embedded Configurations and Profiles I mentioned last month.

It's worth noting that the VisualAge IDE also appears in Java Enterprise Edition, C++, and even RPG, among others, directly from Big Blue. The WebSphere Studio WorkBench IDE will replace VAME and, presumably, the other VisualAge products about the time you read this, but it's similar in style and intent.

IDEs belong to the class of programs that Alan Cooper calls "sovereign programs" — those that justifiably take over the entire screen for hours while you do useful work. More importantly, sovereign programs assume you'll invest the time required to figure out:

• How they work.

• How to get them to do what you want done.

• How to adapt what you want done to what they can do.

Despite the fact that VAME simplifies the mechanics of developing an embedded J2ME program and makes debugging about as easy as it can get, you should not expect to simply sit down, deploy your favorite caffeine delivery system, and be productive. If you don't understand how Java works, what the implications of particular choices may be, and how all this fits in your target system, you're sunk. It's that simple.

For example, the VAME SmartLinker removes unused Java classes from the final bytecode file, with the intent of delivering the smallest possible file to your precious ROM. The results, however, depend on which configuration you choose and can range from only a few hundred kilobytes up to several megabytes.

Why? The linker is smart enough to realize that it can't chop unused classes from standard library configurations. Those class libraries must remain intact to support other embedded CDC Java programs that you may add to the system later on. OTI includes several custom configurations that do allow class removal, but those aren't standard and must be used in well-controlled systems that need not support the full Java environment.

Moral of the story? Make sure you understand the system-level implications before you start coding and building. Well, okay, expect to do some playing around while tracking down all the knobs and switches, but know what you're looking for.

VAME includes the J9 Virtual Machine, which has been tuned to about eight different CPU and OS combinations. Rather than hand adapt the VM, OTI chose a more elegant solution. They wrote a VM compiler that converts high-level descriptions of the JVM architecture, the target CPU, and the OS resources into an executable JVM.

That's both high risk and high reward: It takes longer to get the first VM out the door, but optimizing for successive targets becomes much easier. I suspect the first few were much more difficult than the last.

As with all commercial JVMs, you must add a royalty for J9 to your product's recurring cost. Data Representations offers low-volume J9 licenses over the Web for $20 each (https://www.datarepresentations.com/products/purchase/j9VM.shtml). They're intended for Palm PDA programs developed with the Simplicity RAD tools and give a rough idea of just how much a Java application can add to your cost.

Given that midrange Palms of late 2001 sold for perhaps $200 before Christmas rebates, adding $20 to the cost of a program indicates a multihundred-dollar selling price. That probably restricts the programs to specialty niches, where customers don't blink at spending more for the program than for the hardware. In fact, it implies "free" hardware with every purchase of the program.

I don't have any information on the cost of other JVMs, although prices certainly drop dramatically for higher volumes. Keep royalties in mind when considering Java: Yes, money may trump technical considerations.

Incidentally, if you run an ad-blocking filter on your Internet connection, you may have a hard time getting any information about VisualAge products from the IBM web site. The HTML files reside under a directory acronymed from (I think) "application development," which means the URLs resemble http://www.ibm.com/software/ad/vajava/. My ad-blocking software spotted those "/ad/" tokens and smacked the links right out of the byte stream.

Hauling Trash

Garbage collection isn't unique to Java, although it has a much higher profile and more stringent requirements in a system that automatically handles memory allocation and cleanup. Memory management in C++ remains largely the responsibility of application programmers, although the underlying OS and library routines handle free-memory allocation, fragmentation, and compaction.

Adding real-time behavior to the memory manager makes it even more difficult to get right. The garbage collector (GC) must not halt the VM's execution while it combs through memory in search of a chunk large enough for the current allocation request, lest the VM stall before a looming deadline.

JVMs, at least in the early days, used straightforward, even academic, GC algorithms that did exactly that. Stalling the VM was a perfectly defensible design decision in a desktop system, as you want the first versions to be as simple and bulletproof as possible. Besides, who'd notice a stall or two in the overall response time? Unfortunately, the default GC routines in those JVMs contributed to the persistent belief that Java can't get out of its own way.

Kelvin Nilsen, one of NewMonics's principals, probably knows more about high-performance GC than any one person should. You can follow his trail through the white papers at http://www.newmonics.com/about/tech/realgarb.shtml, at least up to the mid '90s when garbage collection suddenly morphed from an interesting collegiate research topic to a hot business plan.

Note the progression from exploring and simulating a staggeringly intricate hardware-assisted garbage collector to the later software-only systems. It turns out that although garbage collection can be a performance bottleneck, it simply doesn't require enough CPU time to justify separate hardware, particularly in systems where designers must fight for each dollar of recurring cost.

Sometimes you must explore all the possibilities before concluding that the obvious solution is correct. And, if you have expertise in, say, garbage collection as it relates to C++, Java represents a heaven-sent opportunity.

Although adroit garbage collection isn't the complete key to JVM success, it's a vital part of real-time performance. NewMonics's PERC system includes several code-tweaking tools in addition to the JVM: an optimizing compiler, ROM loader, debugger, and tailored libraries.

The PERC development matrix covers not quite every cell of the full 3D array of four target CPU architectures, 10 target operating systems, and three host development environments. I remain amazed that tool suppliers can cope with the fragmented embedded marketplace as well as they do!

The Persistence of Vision

So you get your code checked out, the hardware perfectly tuned, everything works fine, and...the lights go out. What happens next?

Embedded applications have configuration data that defines the hardware, initialization data that defines how the system should begin operation, and state data that defines what's going on at any given time. The application must recover from outages at least gracefully if not with aplomb.

In the bad old days before objects were all the rage, you stashed bare data in EEPROM, read it with binary I/O instructions, plunked it into structures, and went about your business. Much of the hardware configuration information would be burned into a ROM that personalized the circuit board; changing that data began by prying a ceramic caterpillar out of its socket and throwing it away.

With Java, wrestling binary data into and out of EEPROM (or, more likely, Flash ROM or a disk subsystem or some such) isn't discussed in polite circles, let alone the problems that arise when the lights go out. Rather than using the JNI for hardware access, you'd prefer some way of storing objects so that, when the lights come back on, the objects magically reappear with their original contents intact.

That's one function of FastObjects j2, a real-time, embedded, object-oriented, Pure-Java-based persistent store from Poet Software (http://www.fastobjects.com/). I think that's the highest buzzword density to date in this column, by the way.

As it happens, though, FastObjects didn't start out with Java, either. The initial work supported persistent objects in C++ and involved, based on my reading of the documentation and white papers at http://www.fastobjects.com/, an awe-inspiring amount of user-level duct tape and gimmickry. Not to take anything away from the folks at Poet, but C++ object persistence was neither transparent nor simple to achieve.

A persistent object, somewhat by definition, doesn't go away when the lights go out. You simply refer to it and it's there the next time you need it. The background persistence machinery takes care of storing and retrieving objects without bothering you about all the little details like actually reading and writing the data.

The central implementation problem involves pointers to other objects, be they persistent or transient, in memory. Those pointers depend on having the referenced objects remaining at fixed memory addresses for the life of the pointer. Anyone who has written any software involving pointers knows that obsolete (aka "dangling") pointers have catastrophic consequences.

A persistent object may be flushed to disk (or Flash ROM or whatever) and restored to a different address in each invocation of the program. So all pointers to that object must be invalidated when it's no longer in RAM and updated when it's restored. The entire collection of objects used by the program forms a complex web (not, typically, an academically tidy tree) of pointers, all of which must be consistent at all times.

In C++, however, there's no sure way to tell just from the structure of the source code when a given operation is dealing with a pointer, nor which object members will hold memory addresses. The obvious cases are easy, but subtle issues involving casts and unions and similar underhanded (yet all too essential and common) techniques are basically intractable. Thus, the FastObjects manual for C++ devotes many pages to the programming techniques and source-code markers required to identify pointers to persistent objects and keep them up to date.

Two attributes of Java greatly simplify that process. By eliminating much of the user-level memory hocus-pocus found in C++, it's easier to figure out which parts of which objects refer to which other objects. Because Java is interpreted, it's also (relatively) easy to figure out when an address will be used to touch memory, and make a preemptive strike before something bad happens.

It is disconcerting to note that, in the context of systems requiring such features, FastObjects can refer to a 450-KB memory footprint for the basic persistence machinery as "small." This package is obviously not for the faint of heart nor the resource-constrained crowd. If your program requires only a smidge of setup and state data, you'll be better served by getting cuddly with JNI.

Reentry Checklist

So what's new? If anything, the admission that Java is a language with both benefits and limitations, not a cure-all balm for every itchy and inflamed embedded project. Given sufficient hardware and reasonable performance expectations, Java can probably get the job done.

Second, a notable decrease of coffee-related puns is certainly grounds for celebration. Oops.

If you don't remember, slept through, or weren't born until after the PC revolution, go to http://www.zdnet.com/pcmag/special/anniversary/ for a high-speed survey.

To see that larval IDE in action, download Borland's Turbo Pascal 1.0 directly from the source at http://community.borland.com/article/0,1410,20693,00.html. It runs snappily in a Win2K DOS box (uh, "command prompt" window), if you're not too fussy about graphics.

John Varley's short story "The Persistence of Vision" looks at a rather different blind community. It's collected in his 1978 book of the same name (ISBN 0-440-17311-6) or, in the UK, look for In the Hall of the Martian Kings. Both are, alas, long out of print.

Alan Cooper's About Face: The Essentials of User Interface Design (ISBN 1-56884-322-4) should be required reading for anybody even thinking of designing a computer program. Read it at your desk with any current app up on your screen and weep.

DDJ