Is another VM necessary for resource-constrained embedded devices?

An intriguing pair of articles posted recently on Embedded.com (B#: A programming language for small footprint embedded systems applications,Part 1and Part2, by Michel de Champlain and Brian G.Patrick) raised important questions regarding the future ofembedded computing.

Accompanying these articles in the Embedded.com newsletter was editorial commentary by Embedded.com Editor Bernard Cole. Thecommentary indicated that the response to the B# articles was thestrongest of any online article in quite some time, suggesting that thesubject matter struck a chord with many people.

The editorial comment that accompanied the B# articles stated that “The response (the readers) have had to theB# series on Embedded.com tells me that if the Java community does notquickly respond to the need, developers will move on to somebody whowill.”

It is interesting in this context to note that a study by EmbeddedMarket Forecasters [3] askedsurvey participants that had opted against using Java to specify thereasons for their decision. Key reasons identified included:

Run time speed is slow
• Memory requirements are large
• Inability to satisfy hard real-time constraints
• Inability to perform low-level operations
• Inadequate support for target systems
• Startup time is too long
• Inability to satisfy soft real-time constraints
• Lack of safety certification

The articles by de Champlain and Patrick introduced a new languageand virtual machine called B#, intended to provide an object-orientedevolution of C giving some of the advantages of C++ while maintainingcompactness, and providing a portable threading abstraction intended torun on top of an interpreted virtual machine, yet without the baggagetypically associated with Java.

These are noteworthy ideas and the effort is a noble one, but thearticles beg the question: Do we really need yet another programminglanguage and VM architecture? Or do we have existing alternatives thatcan achieve the desired goals within an already recognized andcommercially accepted framework?

The salient point of the B# articles was that the C language andparadigm is aging and fragile, but nothing sufficiently worthy hasemerged to fully replace it in the realm of resource-constrainedapplications. This disparity is disconcerting given the rapid expansionof embedded devices, not only in volume of device deployment, but alsoin application complexity. Worthy successors to C have been suggested,but none have yet fully gained traction in the resource-constrainedcommunity for a variety of reasons. For example:

C++ – While in many ways animprovement over C, C++ nevertheless increases the complexity of thelanguage without addressing many of the core flaws of C, such as typeinsecurity, unsafe memory operations, a lack of portable low leveloperations, and no portable threading model. Further, although manysurveys will show C++ as the dominant language in embedded computing,evidence indicates that many who are using C++ compilers are primarilyusing the C subset of the language, typically avoiding objectorientation and other C++ features entirely.

Ada – The Ada language,a chronological contemporary of C and C++, offers technologicaladvantages comparable to Java and has been shown to be quite effectivefor resource-constrained and safety-critical applications. Theroadblock for Ada is not technological. Ada has failed to gainwidespread acceptance for historical reasons stemming from itsinception and incubation as a government sponsored, military-mandatedlanguage in the mid-80s to mid-90s. The heavy bureaucratic burdenplaced on vendors made Ada too costly to ever become a significantfactor in commercial applications. Although the eventual relaxation ofgovernmental overhead made it possible to produce cheaper Ada productswith faster time to market, much of the damage had already been done.Meanwhile the proliferation of inexpensive C compilers kept Ada frombecoming widely used in academia, resulting in a flood of graduatesaccustomed to the C style of development who are less comfortablephilosophically with – and more resistant to learning – Ada due to itssyntactic heritage from ALGOL/Pascal.

Java – Java has enjoyedextraordinary popularity in desktop, web, and mobile device markets,and currently dominates those markets [2] while providing up to 10ximprovement in programmer productivity. The abstraction, portability,scalability, and safety of Java are among its many attractivecharacteristics especially suitable to large, complex, and dynamicapplications. However, Java has run into a major roadblock with regardto adoption across the broader spectrum of embedded development,particularly the very large class of applications that must operate ondevices with tightly constrained resource budgets for footprint,execution speed, and response times. Ordinary Java typically runs 2-3times slower than optimized C code, with a footprint many times larger,and with response times that are often sluggish and unpredictable withconventional garbage collection. Further, Standard Edition Java lacksportable mechanisms for low level device access. The Real-TimeSpecification for Java (RTSJ), introduced through the Java CommunityProcess (JSR-1) as an official augmentation of Java, providesmechanisms for offering sub-millisecond latencies. However other issuesthat are important to the resource-constrained market, such asexecution speed, footprint, and low-level device access, are outsidethe scope of the RTSJ. Any Java solution must address these issues tobe acceptable to the resource-constrained community.

B#, the language introduced by de Champlain and Patrick, offers thefollowing benefits to the resource-constrained computing market:

o compact language andefficient code generation
o familiar syntax (derived fromC)
o full support for objectorientation
o low level device access
o interrupt support
o simple type system
o portable multithreadedkernel abstraction

These are all important benefits for the embedded programmer.However, it would be a mistake to assume that these are the onlybenefits one would seek in an ideal solution. These features might beconsidered desirable or necessary, but not sufficient. A short list ofother important characteristics one would seek includes:

o uses safe programmingtechniques
o is based on commerciallydominant technology
o does not require “newlanguage” evangelization
o is based on openspecifications that promote standardization
o is already productized forready market access
o does not need to build up anall new market ecosystem
o is scalable across multipleapplication dimensions

These benefits and more can be made available to the hard real-timeand deeply embedded applications domain without resorting to a newprogramming language and VM architecture. While B# uses C as itsstarting point (and some clever readers have pointed out the irony thatB# and C are equivalent in musical terms), one could argue that thisapproach reinvents the wheel. Object orientation has already been addedon top of the C syntactic heritage, first in C++ and then in Java amongothers, and a portable threading abstraction is already available fromJava.

There is a significant advantage to using Java as the baselinerather than C. The trick is to make it possible to use Java code in away that hasn’t been possible in the past: a way that results in verysmall, very fast, very responsive applications, and offers portablemeans of accessing low level devices while also being interoperablewith increasing levels of network-centric complexity. If such asolution were available, divergent branches such as B# would becomeredundant, and the yearnings of the resource-constrained computingcommunity for an acceptable way out of the C quagmire finally would besatisfied.

The good news is that a resource-constrained solution based on theJava baseline is not idle speculation and wishful thinking. It existstoday in the form of a technology called PERC Pico that is already licensed and inuse today in limited release. Previous attempts at providing a hardreal-time solution for Java have fallen short in that they have notresolved the common need of embedded developers to fit within stricttiming and memory budgets, while at the same time introducing newcomplexities detrimental both to productivity and portability. PERCPico has adopted valuable elements of those earlier attempts whilediscarding the problematic components.

It allows Java programmers to achieve execution speeds, memoryfootprint, and response times comparable to that available to Cprogrammers while retaining many of the key benefits of full Java evenfor the most deeply embedded applications. Further, PERC Pico providesa portable threading model, safe memory management, and even thecapability for dynamic loading, without resorting to a Java VM in theconventional sense. No doubt this will come as a relief to manyembedded developers who, fairly or not, spontaneously cringe when theyhear the term Virtual Machine.

In addition to being able to operate in a stand-alone mode “close tothe silicon”, PERC Pico is also interoperable with full Java StandardEdition VMs, an ideal situation for the growing class of applications,such as network-centric distributed devices, that have both highfunctional complexity as well as the need for components with hardreal-time constraints and a portable approach to low level deviceaccess. In the past, such applications would typically use Java for thecomplex application logic, but resort to C for the low level code,requiring problematic and inefficient cross-language interfacing. It isnow possible to create low level components directly using Java code.

In the months following its initial commercial release in mid-2006,PERC Pico will be ported to all of the platforms supported by itssibling technology, PERC Ultra  – a soft real-time solutionbased on Java Standard Edition. In addition to “bare board” deployment,PERC Pico can be used with major RTOS platforms.

The guidelines for scalable Java development of real-time systems are openly available [2] and Aonix is actively involvedwith the current efforts of the Open Group and the Java CommunityProcess to usher these specifications into standardization.

KelvinNilsen, Ph.D. is chief technology officer at Aonix North America

References
[1] IEEE Software, May/June2005, An Empirical Study of Programming Language Trends, Chen et al. www.ieeesoftware.com
[2] Guidelines for ScalableJava Development of Real-Time Systems, available athttp://research.aonix.com/jsc/rtjava.guidelines.3-28-06.pdf
[3] 2005 Survey by EmbeddedMarket Forecasters. www.embeddedforecast.com/