Vaughan, F., Schunke, T., Koch, B., Dearie, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems, vol 5, 3, California, 1992.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....by following pointers in virtual memory. The system moves the necessary data between main memory and secondary storage or between the main memory of remote sites, according to application needs. We have found very few systems extending DSM with persistence in the literature. One of them is Casper [121]. It takes advantage of the external pager mechanism [65] of the Mach operating system [1] to provide transparent access to data in secondary storage. Given that its GC specification is sketchy [70] it is not clear how PBR could be supported. Feeley et. al [49] describe a transactional DSM that ....

Francis Vaughan, Tracy Lo Basso, Alan Dearle, Chris Marlin, and Chris Barter. Casper: a cached architecture supporting persistence. Computing Systems, 5(3):337--359, 1992.

....can define their own persistent types, they either make all instances of that type persistent or none at all. Among the systems that support orthogonal persistence, some do not distinguish between volatile and persistent objects and simply make the entire address space persistent, as in Casper [17]. Here, the persistent store provides an abstraction similar to a stable distributed shared memory, with all clients sharing the same address space. We want clients to share a global object space, not a global virtual memory space. This allows applications to run on different and heterogeneous ....

F. Vaughan, T. Basso, A. Dearle, C. Marlin, and C. Barter. Casper: a Cached Architecture Supporting Persistence. Computing Systems, 5(3):337--359, 1992.

....to access remote entities and a third to manipulate persistent information. Various approaches have been followed to extend the object oriented model to distributed and persistent environments. A line of research has been to extend or define new languages to support distributed [1,2] or persistent [3,4,5] objects. We feel that these two approaches should be addressed together, providing distribution and persistency of fine grained objects in a uniform model, where object references can be freely passed in remote invocations or stored persistently. IK [6,7] is an object oriented platform which ....

....5 During the copy, references are swizzled, the data converted to XDR format and the object is tagged with the mark of the cluster head object. 6 Secondary Storage in Comandos Architecture parlance. 7 Also possible using servers as external pagers like in Mach based operating systems (as in [5]) 8 For classes it is a natural assumption since they substitute traditional object code files. 7 GARBAGE COLLECTION 14 containers are readable and writable only by the storage server. When an application wants to map a cluster the server changes the protection and group of the respective ....

Francis Vaughan, Tracy Lo Basso, Alan Dearle, Chris Marlin, and Chris Barter. Casper: a Cached Architecture Supporting Persistence. Computing Systems, 5(3):337--359, Summer 1992. REFERENCES 18

....recovery of the token state with minimal run time overhead. Tam and Hsu describe an approach that is based on one of Li s dsm algorithms. A checkpointing and logging scheme is used to store the actual pages; the token database just helps maintain a consistent view after a failure. Vaughan, et al. [195] describe a fault tolerant persistent object system called Casper that provides a dsm service. Casper is implemented using shadow paging and concentrates primarily on maintaining a self consistent view of the system that may be pushed to disk. Markatos and Dramintinos [140] study the use of main ....

....that a dsm providing persistency must address. Due to the inherently distributed nature of the data in a dsm system, it is not easy to obtain a globally consistent snapshot of the data on secondary storage. All of the fault tolerant dsms (x3.7) address this issue in one way or another, and Casper [195] illustrates techniques that may be used to obtain a self consistent view of the shared data to push to secondary storage. Kato, et al. 112] describe a different approach where the application programmer is given explicit control over the migration of shared data segments between memory and ....

Francis Vaughan, Tracy Lo Basso, Alan Dearle, Chris Marlin, and Chris Barter. Casper: a Cached Architecture Supporting Persistence. Computing Systems, 5(3):337--364, Summer 1992. USENIX Association / University of California Press.

....Unfortunately, such systems incur the overhead of data format translations that must be performed when structured data (e.g. relations in a relational data base) are moved between memory and non volatile storage. More recently, persistence has been added to operating systems and object systems [39, 45, 40]. Such systems provide persistence with difficulty due to limitations of the supporting environment (both software and hardware) Wide address space architectures provide a more natural environment for persistence where the memory bytes themselves are persistent [11, 20] The large address space ....

F. Vaughan, T.L. Basso, A Dearle, C. Marlin, and C. Barter. Casper a Cached Architecture Supporting Persistence. USENIX Computing Systems, 5(3):337 -- 359, Summer 1992.

....and distribution in such systems has been deferred and is now proving difficult to integrate, possibly because of the long deferment. Many recent and current research programmes include work on concurrency specification, for example CACS [3] operating system developments such as Casper [4] and Grasshopper [5] and architectural support such as Monads [6] Two aspects make this work difficult: the representation of concurrency, and the time needed to prototype and evaluate models of distribution. The discussion in [7] is a clear summary of the problems of adding distribution to ....

....of concurrency, and the time needed to prototype and evaluate models of distribution. The discussion in [7] is a clear summary of the problems of adding distribution to persistence. The latter is typically costly if implementation work is carried out at the operating system level as in [4,5]. In this paper we look at the problem from the other side and ask the question: is there any benefit in trying to integrate persistence into a concurrent, distributed programming language In particular we focus on SR Synchronising Resources [8,9] because it is a mature multiparadigm language ....

VAUGHN F., SCHUNKE T., KOCH B., DEARLE A., MARLIN C. & BARTER C. Casper: A Cached Architecture Supporting Persistence.Computing Systems , vol 5,3, California, 1992.

....is largely a matter of resources. Concurrency and distribution support: initial work has been done on concurrency and distribution in persistent languages [35,36,54] though some important semantic problems are still to be solved. Current effort is mainly focussed on implementation issues [52,53]. Persistent stores: developments in persistent store technology should give better support for bulk data. Persistent programming environments: current research into configuration management of persistent programs and novel binding schemes [24] could revolutionise persistent programming ....

F. Vaughan, T. Schunke, B. Koch, A. Dearle, C. Marlin and C. Barter, "Casper: a Cached Architecture Supporting Persistence", Computing Systems Vol 3 No 3, pp337--363, Summer 1992.

....its run time support uses almost only Mach abstractions and Unix dependencies are isolated in the storage and name servers. 5 Related work This section compares MIKE with other systems that exploit micro kernel functionality with similar goals. Namely COOL [2] the multi server [6] and Casper [15]. The first one exploits the Chorus [10] functionality and the last two exploit the facilities offered by Mach. MIKE s distributed object sharing support is similar to the one in the multi server. The two systems use a function shipping model implemented using Mach inter process communication. ....

F. Vaughan, T. Basso, A. Dearle, C. Marlin, and C. Barter. Casper: a Cached Architecture Supporting Persistence. Computing Systems, 5(3):337--359, 1992.

....property of some types. Even though programmers can define their own persistent types, they either make all instances of that type persistent or none at all. Some systems do not distinguish between volatile and persistent objects and simply make the entire address space persistent, as in Casper (Vaughan et al. 1992). Here, the persistent store provides an abstraction similar to a stable distributed shared memory, with all clients sharing the same address space. We promote independence between applications address space, and thus the global object space must be independent of applications address space. ....

....respective container, giving read or read write access to k During the copy, references are swizzled, the data converted to XDR format and the object is tagged with the mark of the cluster head object. Also possible using servers as external pagers like in Mach based operating systems as in (Vaughan et al. 1992). the application. There is a well known group per user to be used in these cases. Next, we had to decide the way clusters are allocated among files, i.e. if there is one or many per each file. Since we did not know what would be the average size of clusters, we decided to start with the simpler ....

Vaughan, F., Basso, T., Dearle, A., Marlin, C., & Barter, C. 1992. Casper: a Cached Architecture Supporting Persistence. Computing systems, 5(3), 337--359.

....independence, data must be accessed in a uniform manner, regardless of the location of that data. In distributed persistent systems, location independence is extended to the entire computing environment by permitting data resident on other machines to be addressed in the same manner as local data [9, 10, 12, 25, 26]. Protection of data: A protection mechanism must be provided to protect data from accidental or malicious misuse. In persistent systems this is typically provided via the programming language type system [20] through data encapsulation [17] using capabilities [6] or by a combination of these ....

....programs which reside and execute within their own containers. Managers are responsible for: provision of the pages of data stored in the container, responding to access faults, receiving data removed from physical memory by the kernel, implementation of a stability algorithm for the container [3, 14, 18, 22, 26], i.e. they maintain the integrity and resilience of data, and maintenance of coherence in the case of distributed access to the container [10, 15, 21] Managers are responsible for maintaining a resilient copy of the data in a container on stable media. It is only within a manager that the ....

Vaughan, F., Schunke, T., Koch, B., Dearie, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems, vol 5, 3, California, 1992.

....to be concerned whether the data is in RAM or on disk; the data is accessed in a uniform manner. In distributed persistent systems, location independence is extended to the entire computing environment by permitting data resident on other machines to be addressed in the same manner as local data [14, 15, 20, 40, 41]. This approach is also followed in distributed shared memory systems [36] Data resilience: All systems containing long lived data must provide a degree of resilience against failure. In conventional operating systems, tools such asfsck in Unix permit the repair of long lived data (the file ....

....This model is used to implement the Napier88 persistent programming system [32] The construction of very large stores using this technique was, until recently, not feasible on conventional architectures due to address size limitations. However, the advent of machines such as the DEC Alpha [41] and the MIPS R4000 [18] which (logically) support a 64 bit address has created renewed interest in this approach. A number of research groups have suggested that this is an appropriate direction for modern operating systems [22] Such an approach is tempting since it fits in well with the goals ....

[Article contains additional citation context not shown here]

Vaughan, F., Schunke, T., Koch, B., Dearie, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems, vol 5, 3, California, 1992.

....does not have to worry if data is in RAM or on disk; the data is accessed in a uniform manner. In distributed persistent systems, location independence is extended to the entire computing environment by permitting data resident on other machines to be addressed in the same manner as local data [14, 15, 19, 40, 41]. This approach is also followed in distributed shared memory systems [36] Data resilience: All systems containing long lived data must provide a degree of resilience against failure. In conventional operating systems, tools such asfsck in Unix permit the repair of long lived data (the file ....

....for: provision of the pages of data stored in the container, responding to access faults, and receiving data removed from physical memory by the kernel. In addition, Grasshopper managers have the following responsibilities: implementation of a stability algorithm for the container [6, 21, 26, 33, 41], i.e. they maintain the integrity and resilience of data, and maintenance of coherence in the case of distributed access to the container [15, 24, 30] A manager is invoked whenever the kernel detects a memory access fault to data stored in the container it manages. Making data accessible in a ....

Vaughan, F., Schunke, T., Koch, B., Dearle, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems, vol 5, 3, California, 1992.

....our porting efforts, a number of problem areas have been identified. Sections 3.3.1 through 3.3.5 describe the main problems and their origins. 3.3. 1 Overhead of Page Fault Resolution From past experience of building persistent object stores on top of Mach using the external pager interface [47, 48], it was decided that Grasshopper should support a similar mechanism to enable various store architectures to be tested without changing the kernel. Thus, the concept of a manager was developed to provide user level control over the storage of persistent data. Since each container can have its own ....

F. Vaughan, T.L. Basso, A. Dearle, C. Marlin, and C. Barter, "Casper: A Cached Architecture Supporting Persistence", Computing Systems, 5(3), pp. 337-359, 1992.

....persistent operating system, Eumel L3 has no file system, eliminating the need for file buffers and so the extent of this problem may be overstated. Nevertheless, performance might be improved by employing a finer grain checkpointing mechanism. A process oriented scheme such as that used in CASPER [62] or the scheme proposed by Jalili and Henskens [34] would reduce the need for extra memory by eliminating the need for global checkpoints. A drawback of this approach is that application programs have no knowledge of shutdowns or restarts. Consequently they cannot adjust their behaviour to take ....

F. Vaughan, T. Schunke, B. Koch, A. Dearle, C. Marlin, and C. Barter, "Casper: A Cached Architecture Supporting Persistence", Computing Systems, 5(3), pp. 337-364, 1992.

....at the same address within the container in which they are executing. This considerably simplifies memory management and adds a degree of inter thread protection unavailable in most systems. The technique of giving each concurrent persistent process its own local heap was used in the CASPER system [23]. In this system it was found that the use of copy out techniques borrowed from generational garbage collection considerably reduced the work of garbage collecting the global heap. It is expected that similar results will be found in the case of Java whose architecture is very similar to that of ....

Vaughan, F., Schunke, T., Koch, B., Dearle, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems, vol 5, 3, California, pp. 337-364, 1992.

....the kernel invokes its manager with parameters that include the address of the fault. It is the manager s responsibility to service this fault in an appropriate way; for example, by retrieving the page from disk. This facility was inspired by experience with the Mach external pager facility[21, 22] but extends the model to include responsibility for stability and resilience. 4 The Model of Persistence One of the perceived problems with persistent systems is that they incur an unreasonable overhead due to checkpointing. The reason for this is that stabilisation in most persistent systems ....

Vaughan, F., Lo Basso, T., Dearle, A., Marlin, C. and Barter, C. "Casper: a Cached Architecture Supporting Persistence", Computing Systems, vol 5, 3, pp. 337-359, 1992.

....[19] quicksort sorting a 10,000 element array of integers, listed in appendix 1. Measurements were made on a Sun Sparcstation 2 with 64 megabytes of main memory. The native code generation experiments were conducted using a Napier88 system based on a single user, page based (CASPER [18]) object store held on a local disk. Computationintensive benchmarks are used for two reasons. Firstly, the 15 performance characteristics of the persistent object store cannot significantly affect the results. Secondly, a C implementation of the benchmarks can be used to give an upper bound on ....

Vaughan, F., Schunke, T., Koch, B., Dearle, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems , vol 5, 3, California, 1992.

....of inter thread protection unavailable in most systems. However, this approach was not employed in the Java system due to the requirement of the garbage collector to view thread stacks. The technique of giving each concurrent persistent process its own local heap was used in the CASPER system [23]. In this system it was found that the use of copy out techniques borrowed from generational garbage collection considerably reduced the work of garbage collecting the global heap. It is expected that similar results will be found in the case of Java whose architecture is very similar to that of ....

Vaughan, F., Schunke, T., Koch, B., Dearle, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems, vol 5, 3, California, pp. 337-364, 1992.

....its start and end are identical. This technique is illustrated in conjunction with after look shadow paging in Figure 1. The next sections describe two commonly used forms of shadow paging known as after look and before look. 2.1. 1 After Look Shadow Paging In an after look shadow paging system [12, 13, 15], a dirty page is never written to the site from which the clean version of the page was fetched; this is analogous to deferred write logging [4, 9] Instead, modified pages are shadowed by writing them to unused disk blocks. Since the locations of pages change, it is necessary to maintain a ....

....efficiency reasons. However, larger stores require proportionately larger LP Maps which may not fit entirely within memory. In this case the map could be paged from a transient region of disk which would require a separate mapping. This introduces complexities which some systems, such as CASPER [15], have solved by embedding the LP Map in the persistent address space that it describes. This has the advantage that it will be paged and shadowed as it is modified using a single mapping. Atomicity is achieved through the use of Challis algorithm. If the embedded LP Map technique is employed, ....

Vaughan, F., Schunke, T., Koch, B., Dearle, A., Marlin, C. and Barter, C. "Casper: A Cached Architecture Supporting Persistence", Computing Systems, Volume 5, Number 3, California, pages 337-364, 1992.

No context found.

F. Vaughan, T.L. Basso, A Dearle, C. Marlin, and C. Barter. Casper a Cached Architecture Supporting Persistence. USENIX Computing Systems, 5(3):337 -- 359, Summer 1992.

No context found.

Vaughan F., Koch, T., Dearle, A., Marlin, C. & Barter, C. "Casper: A Cached Architecture Supporting Persistence". Computing Systems 5, 3, (1992) pp 337-359. 142

No context found.

Vaughan, F. , et al., "Casper: a Cached Architecture Supporting Persistence," Computing Systems, Vol. 5, No. 3, Summer 1992.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC