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 RTSJs assignment rules. These issues are addressed from
a practitioners 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.,
Yoshiki.Ohshima@acm.org John Maloney,
MIT Media Lab,
JohnMaloney@earthlink.net Andy Ogden,
Strategy, Design, and Development Consulting,
aogden@earthlink.net
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.
|
|