Check out the new USENIX Web site. next up previous
Next: Conclusion Up: Automatic Persistent Memory Management Previous: Remaining Safety Issues


Related Work

Pocket Smalltalk [Arsenau and Brault, 1999] is a Smalltalk-80 implementation for the Palm Connected Organizer. Like our system, Pocket Smalltalk circumvents PalmOS's database API and implements an in-store execution model by directly modifying its segmented heap in the static RAM area. The system does not offer an elaborate protocol to manage the persistent state of external data.

MERPATI [Suezawa, 2000] extended the JDK 1.1 VM through a checkpointing mechanism for purposes of error recovery and migration of computations. After suspension of all computation, the whole program state is transferred to disk. Contrary to our work, MERPATI does not offer a checkpointing protocol to internalize partially external state. Also, the system does not persist class file contents but requires them to be installed at every migration target. MERPATI employs a conservative garbage collector, so type accurate descriptions of stack contents are only needed for checkpoints. Consequently, the system computes reference maps on demand, instead of updating them with every bytecode instruction, as our system does.

The PJama research prototype [Atkinson and Jordan, 2000] features a modified high-performance Java 2 VM and runs on top of a recoverable, scalable persistent object store. Through incremental faulting and eviction on a per-object basis, the system can operate on stores much larger than physical memory. PJama does not persist threads -- this allows for a simpler checkpointing procedure, as synchronization issues between the checkpointing thread and other mutators do not need to be addressed. However, in order to achieve a consistent checkpoint, all executing threads have to agree that they have currently reached a consistent state by using synchronization on the application level.

The GemStone/JTM Persistent Cache ArchitectureTM [GemStone, 2000] uses modified Java 2 VMs to provide access to a multi-user, transactional store. Its multi-user architecture provides a logical separation between the store and the execution engines operating on it. Hence, persistence of execution state (threads) is not within the scope of this system.


next up previous
Next: Conclusion Up: Automatic Persistent Memory Management Previous: Remaining Safety Issues

2001-02-27