Practitioners Reports

Real-World Objects

Wednesday, 29 October – 15:30-17:00

15:30 - 16:00
Programming with Non-Heap Memory in RTSJ

Greg Bollella, Sun Microsystems Laboratories
Tim Canham, Jet Propulsion Laboratory, California Institute of Technology
Vanessa Carson, Jet Propulsion Laboratory, California Institute of Technology
Virgil Champlin, Jet Propulsion Laboratory, California Institute of Technology
Daniel Dvorak, Jet Propulsion Laboratory, California Institute of Technology
Brian Giovannoni, School of Computer Science, Carnegie Mellon University
Kenny Meyer, Jet Propulsion Laboratory, California Institute of Technology
Alex Murray, Jet Propulsion Laboratory, California Institute of Technology
Kirk Reinholtz, Jet Propulsion Laboratory, California Institute of Technology

The Real-Time Specification for Java (RTSJ) provides facilities for deterministic, real-time execution in a language that is otherwise subject to variable latencies in memory allocation and garbage collection. In particular, RTSJ introduces two kinds of non-heap memory area (ScopedMemory and ImmortalMemory) and a kind of real-time thread (NoHeapRealtimeThread) that, together, can satisfy very demanding timeliness requirements because they run without interference from the garbage collector. What new RTSJ programmers quickly discover, though, is that the RTSJ "assignment rules"—governing references from one kind of memory to another—force designers to think more carefully about how data flows among the components of a system. In particular, for the hard real-time portions of a system, the normal Java practice of freely passing around references and letting the garbage collector recognize when an object is no longer needed simply doesn't apply.

This report discusses two related design issues that all RTSJ users will face: how to explicitly manage non-heap memory and how to communicate information among components without violating RTSJ’s assignment rules. These issues are addressed from a practitioner’s viewpoint in the context of designing real-time control loops for driving and steering a 6-wheel Mars rover. The solution described here is termed “scoped memory scratchpads” and is believed to provide a good combination of Java-natural style and safety from programmer error. In this approach, transient data is allocated within a scoped memory area that is emptied later when all Runnables exeunt the memory area. Data that must be preserved across cyclic executions use memory pools, restricted so that all pool management is confined to a single component and is thus much easier to design and verify. Importantly, by maintaining a distinction between application-specific software and framework software, some of the details and discipline of using RTSJ can be hidden from application programmers.

16:00 - 16:30
The Parks PDA: A Handheld Device for Theme Park Guests in Squeak

Yoshiki Ohshima, Twin Sun, Inc.,
John Maloney, MIT Media Lab,
Andy Ogden, Strategy, Design, and Development Consulting,

The Parks PDA is a lightweight, handheld device for theme park guests that functions as a combination guidebook, map, and digital camera. Together with a small team of artists and designers, we created a prototype Parks PDA and content for a three hour guest experience, including a camera interface, a hyper-linked guide book, three games, an animal spotters guide, a cross-referenced map, animated movies with lip-synched sound, a ride reservation system, and more. Over 800 visitors to Disney's Animal Kingdom theme park tested the Parks PDA over a two week period.

Developing the software for this test posed a number of challenges. The processor and memory of the target device were slow, the screen was small, and we had only three months of development time.

We attacked these problems using Squeak, a highly-portable, open source Smalltalk implementation. We ported Squeak to the target device and used it to provide nearly bit-identical behavior across four different platforms. This supported a cross-platform development style that streamlined the production of both software and content. We created a tiny user interface and application framework for pen-based devices and implemented a simple card-stack media editor and player using it. We isolated and fixed several performance problems.

The project was completed on time and guest response was favorable. Looking back, we can identify ten aspects of Squeak that contributed to the success of the project. While we feel that Squeak was the ideal tool for this job, many of the key benefits of Squeak could be enjoyed using other object-oriented languages such as Java J2ME or Python, especially if the source code of the virtual machine is available.