Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Operating system support for persistent and recoverable computations
Rosenberg J., Dearle A., Hulse D., Lindström A., Norris S. Communications of the ACM39 (9):62-69,1996.Type:Article
Date Reviewed: Mar 1 1997

In a persistent computation, the lifetime of data is orthogonal to the method used to access it. This allows a uniform mechanism of manipulating all data. The authors define a persistent operating system with these characteristics: the base abstraction is the persistent object; data are recoverable in consistent form; processes are persistent and resilient; and there is a uniform protection mechanism. They introduce Grasshopper as an example of a persistent operating system.

The authors use the term “container” to mean either a file or the address space of a process, and the term “locus” to mean thread of control. An instantiation of Grasshopper is some ensemble of loci executing in some collection of containers. Only one container at a time is visible to a locus, but many loci may execute in a particular container. Loci can migrate between containers, thereby realizing interprocess communication, and containers can share memory. Protection is afforded by a capability mechanism, and name service is implemented in user-level containers.

Every container is associated with a manager container responsible for data management, fault management, the relationship between physical memory and disk, and the ability to recover the state of the container.

Loci checkpoint their state at will, so Grasshopper can recover data and processes to a self-consistent state. There are situations where it is not desirable to restore state to the last envelope of checkpoints. The state of some loci may be internally inconsistent, the state may lead shortly to a crashed or hung system, or some loci may be cooperating with nonpersistent entities on other machines. I wish the authors had supplied information on how they handle such issues.

The authors demonstrate that they have implemented a functioning Grasshopper by executing a benchmark involving random lookup, full table scan, and record insertion using a 7 Mb database. Comparing their results to an implementation of the same benchmark on OSF Mach, the authors see a 15-times advantage for Grasshopper. Somehow, I doubt it.

The paper is much too short to cover the territory. The authors do not describe any algorithms, not even the critical ones they use to checkpoint loci. They do not explore the implications of checkpointing. It would have been interesting to see a few one-page sketches of user-level containers.

Reviewer:  Jason Gait Review #: CR120473 (9703-0199)
Bookmark and Share
 
Organization And Design (D.4.7 )
 
 
File Organization (D.4.3 ... )
 
 
Virtual Memory (D.4.2 ... )
 
 
Communications Management (D.4.4 )
 
 
File Systems Management (D.4.3 )
 
 
Performance (D.4.8 )
 
  more  
Would you recommend this review?
yes
no
Other reviews under "Organization And Design": Date
Implicit system specification and the interface equation
Shields M. The Computer Journal 32(5): 399-412, 1989. Type: Article
Nov 1 1990
Disco: running commodity operating systems on scalable multiprocessors
Bugnion E., Devine S., Govil K., Rosenblum M. ACM Transactions on Computer Systems 15(4): 412-447, 1997. Type: Article
Sep 1 1998
The V distributed system
Cheriton D. Communications of the ACM 31(3): 314-333, 1988. Type: Article
Nov 1 1988
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy