S.I. Feldman and C.B. Brown. IGOR: A system for program debugging via reversible execution. In Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and Distributed Debugging, pages 112--123, May 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....large memory and time overheads during program execution, especially with programs that modify the state frequently. Reverse execution is also applied in so called replay techniques for e#cient debugging of nondeterministic sequential or parallel programs using either hardware [4, 25] or software [11, 20, 23, 24]. In a replay technique, first, the state of a program is saved at a coarser granularity during execution of the program and then the program state at a finer granularity is reconstructed by replaying the program using previously saved runtime information. In hardware approaches, state saving is ....

S. I. Feldman and C. B. Brown. IGOR: A system for program debugging via reversible execution. In Workshop on Parallel and Distributed Debugging, pages 112--123, 1988.

....at. a time. This method also applies to taking incremental checkpoints: saving the pages that have been changed since the last. checkpoint. Instead of protecting all the pages with read only, the algorithm can prot. ect only dirtied pages since the previous checkpoint. Feldman and Brown [17] implemented and measured a sequential ver sion for a. debugging system by using reversible executions. They proposed and implemented the system call DIRTY. This algorithm uses TRAP, PROT1, PROTN, UNPROT, and DIRTY ; a medium PAGESIZE may be appropriate. Generational garbage collection An ....

S. Feldman and C. Brown. Igor: A system for program debugging via reversible execution. A UM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112-123, January 1989.

....checkpoints. Their analysis is similar to ours except that our incremental checkpointing analysis is more comprehensive since it not only excludes dead and read only regions of memory but also excludes those regions of memory which have been checkpointed earlier and haven t changed since then. [6] and [18] use virtual memory protection hardware to perform page based read only memory exclusion. While the program is executing, the checkpointer maintains a list of all pages that have been modi ed since the most recent checkpoint. This approach has the drawback that it requires kernel ....

S.I. Feldman, C.B. Brown, "IGOR: A System for Program Debugging via Reversible Execution", In ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, January 1989

....critical events and generate traces for them. A major drawback of such approaches is the overhead, in time and particularly in space, of capturing critical events and in generating traces. Igor, Recap, and PPD are some of the early works that provide replay capability as part of debugging [8, 15, 13, 6]. They all support replay (or reverse execution ) by checkpointing and re executing from a previous checkpoint. Igor, however, does not directly address the issue of non determinism in multithreaded applications [8] Recap checkpoints the program state by forking and suspending a new process ....

....of the early works that provide replay capability as part of debugging [8, 15, 13, 6] They all support replay (or reverse execution ) by checkpointing and re executing from a previous checkpoint. Igor, however, does not directly address the issue of non determinism in multithreaded applications [8]. Recap checkpoints the program state by forking and suspending a new process [15] It handles non determinism in multithreaded applications by capturing the effect of every read of shared memory locations, which is quite expensive. PPD performs program analysis to reduce the size of snapshots at ....

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. In Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and Distributed Debugging, pages 112--123, May 1988.

....second at a time. This method also applies to taking incremental checkpoints; saving the pages that have been changed since the last checkpoint. Instead of protecting all the pages with read only, the algorithm can protect only dirtied pages since the previous checkpoint. Feldman and Brown [17] implemented and measured a sequential version for a debugging system by using reversible executions. They proposed and implemented the system call dirty. This algorithm uses trap, prot1, protN, unprot, and dirty ; a medium pagesize may be appropriate. Generational garbage collection An ....

S. Feldman and C. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112--123, January 1989.

....Dead memory locations need not be included in a checkpoint file since upon recovery the application program will resume at a point where the dead memory locations may be left uninitialized; these locations will have new values written to them before they are ever read. Incremental Checkpointing [FB89, WM89] With incremental checkpointing, page protection techniques are used to identify pages that have been modified since the most recent checkpoint. Only the dirty pages are saved in each checkpoint file. Upon recovery, the state of the program is rebuilt from all the checkpoint files. This ....

....exhibits good locality. For other programs in which a sizable portion of the address space is dirty during each checkpoint, incremental checkpointing can degenerate to the unoptimized case. In this situation the cost of catching the page faults can actually increase the checkpointing overhead [FB89, EJZ92, PBKL95] Word level Memory Exclusion [NW94] This technique tracks every read and write in the program so that both clean and dead memory can be excluded from checkpoint files. This leads to (nearly) optimally small checkpoint files. However, the extra overhead incurred due to this ....

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112--123, January 1989.

....to transform C programs into semantically equivalent C programs that are additionally capable of saving and recovering from portable checkpoints. This technology can be exploited to provide fault tolerance in heterogeneous systems and may also be used for debugging or retrospective diagnostics [3]. To the latter end, a portable checkpoint can be used to restart or inspect a program on a binary incompatible system architecture. In this paper, we explore extensions to the porch compiler and its runtime system to support portable, faulttolerant file I O. Our studies are based on a prototype ....

Stuart I. Feldman and Channing B. Brown, "Igor: A System for Program Debugging via Reversible Execution," ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, vol. 24, no. 1, pp. 112--123, Jan. 1989.

....application called pcell. pcell is a program that executes a large grid of cellular automata for numerous iterations. pcell is challenging for a checkpointing system for several reasons. First, for each pair of iterations, it writes almost every word in memory. Thus, incremental checkpointing [10, 38] cannot optimize the performance if checkpoints are taken more than two iterations apart. Second, if checkpoints have a high latency, then the copy on write optimization does not work very well since many pages are written to and copied during checkpointing. Third, the checkpoint images are not ....

....evenodd parity was not used for this experiment, but should be used in preference to Reed Solomon coding for two processor fault tolerance. Finally, there are other techniques that have been presented and implemented to reduce checkpoint overhead and latency, including incremental checkpointing [10, 38], memory exclusion [25] compression [27] and compiler assistance [17, 24] These techniques should affect all checkpointing strategies equally, and will not alter any of the conclusions in this paper. 8. Conclusion This paper has explored several strategies for taking coordinated checkpoints on ....

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Par. and Dist. Debugging, 24(1):112--123, January 1989.

....For the purposes of this paper we distinguish between three distinct entities: application frameworks; user programs that run within these frameworks; and OS services. Application frameworks include programming languages, databases, and diverse custom systems such as Arjuna[1] and IGOR[2]. They are of particular relevance to the SIGOPS 94 theme 1 because in adapting to existing OS services they highlight the shortcomings of current OS provision. This paper argues that application level local checkpointing is such a common need that it should routinely be catered for by an ....

.... Application frameworks which rely on checkpointing include: transaction based programming[1,6,13] and databases in general[12] persistent object systems[7,10,16] virtual time based distributed computation[6, 15] job control systems for long running programs[9,14] replay debugging[2,17], distributed simulation[18,19] 1 Matching Operating Systems to Application Needs Wanted: An Application Aware Checkpointing Service 2 W2 94 Motivations for checkpointing include: concurrency control and atomicity[1,6,12] rollback and backtracking[2,6,12,15,18] failure recovery ....

[Article contains additional citation context not shown here]

FELDMAN, S., & BROWN, C., IGOR: A System for Program Debugging via Reversible Execution. ACM SIGPLAN 24,1 (January 1989) 112-123.

....or eliminate the latency of disk writes. Memory exclusion optimizations attempt to minimize the amount of memory that needs to be saved at each checkpoint. Until recently, the only memory exclusion optimization that has been successful in improving performance has been incremental checkpointing [FB89, WM89] which eliminates the need to save memory that is clean between checkpoints. However, another source of memory exclusion is memory that is dead at the time of checkpointing. There have been mechanisms implemented to exploit both clean and dead memory exclusion in checkpointing, but they ....

....file. Dead memory is defined to be memory that will be written before it is next read. It does not need to be saved as part of a checkpoint because the values of such memory will never be needed. The following are checkpointing optimizations based on memory exclusion. Incremental Checkpointing [FB89, WM89] With incremental checkpointing, page protection hardware is used to identify dirty pages that have been modified since the last checkpoint. Only the dirty pages are saved in each checkpoint file, thereby omitting all pages of clean memory. Upon recovery, the checkpointed state is rebuilt ....

[Article contains additional citation context not shown here]

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112--123, Jan 1989.

....or eliminate the latency of disk writes. Memory exclusion optimizations attempt to minimize the amount of memory that needs to be saved at each checkpoint. Until recently, the only memory exclusion optimization that has been successful in improving performance has been incremental checkpointing [FB89, WM89], which eliminates the need to save memory that is read only between checkpoints. However, another source of memory exclusion is memory that is dead at the time of checkpointing. There have been mechanisms implemented to exploit both read only and dead memory exclusion in checkpointing, but they ....

....Dead memory is defined to be memory that will be written before it is next read. It does not need to be saved as part of a checkpoint because the values of such memory will never be needed. The following are checkpointing optimizations based on memory exclusion. Incremental Checkpointing [FB89, WM89]: With incremental checkpointing, page protection hardware is used to identify dirty pages that have been modified since the last checkpoint. Only the dirty pages are saved in each checkpoint file, thereby omitting all pages of read only memory. Upon recovery, the checkpointed state is rebuilt ....

[Article contains additional citation context not shown here]

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112--123, Jan 1989.

....them. Making a snapshot of a program s state at a particular point in its execution is checkpointing; undoing execution by returning to a previous state is reverse execution. The utility of such a tool is nicely illustrated in Feldman and Brown s discussion of their IGOR reverse execution system [40]. They address the debugging problem of a programmer discovering that a supposedly acyclic list contains a cycle: one of the elements points to a previous element. To find the bug responsible, the programmer would like to ask the debugger the question, When did this tree first get an illegal ....

Stuart I. Feldman and Channing B. Brown. Igor: A system for program debugging via reversible execution. In Proceedings of the ACM SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging

....assumptions that do not hold in real checkpointing systems. First is that C; L, and R are constants for each program execution. Since L and R depend on the size of each checkpoint, they can only be constants if each checkpoint is the same size. When optimizations such as incremental checkpointing [FB89] or memory exclusion [PBKL95] are employed, it is common for multiple checkpoints of the same program to differ in size. The checkpoint overhead depends on additional factors, such as the memory usage patterns of the program, and again can vary from checkpoint to checkpoint. However, we assume ....

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112--123, January 1989.

....enables many new techniques such as a generic undo operation, a real time checkpoint, and fast backtracking. 1 Introduction Reverse execution provides access to old states of an executing process. It is a well established concept in computer science used in program development and debugging [2, 6, 20, 21, 27, 28, 30], in programming environments and human computer interaction [1, 10, 16, 18, 29] in fault tolerant computing [5, 7, 14, 15] and in speculative computation [9, 13] In computer architecture, techniques of reverse execution are used to provide precise interrupts [12, 23] Implementations of reverse ....

....by special instructions that turn the history off and on. Spatial selection can be implemented by a hardware filter in the history cache which would eliminate parts of the process state whose history is not necessary. 3 Applications A common application of reverse execution is debugging [2, 6, 20, 30]. When a program exhibits undesirable behavior we generally want to obtain previous states of the program execution to find the error. This can be easily provided using the history. Without reverse execution, the program must be restarted from the beginning which can be a time consuming and ....

[Article contains additional citation context not shown here]

S. I. Feldman and C. B. Brown. IGOR: A system for program debugging via reversible execution. In Proceedings SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging, pages 112--123. ACM, 1988.

....interaction and programming environments [11, 66, 99] Because it supports reverse execution, an introspective computer can return any program to a state in the past regardless of the programming language or the programming environment. A common application of reverse execution is debugging [15, 50, 121, 182]. When a program exhibits incorrect behavior we often want to see previous states of the program execution to find the error. This can be easily provided using the history. Without reverse execution, the program must be restarted from the beginning, which can be a time consuming and tedious ....

....defined as the time that the executor is interrupted during a checkpointing process. For real time systems, it is important that the latency is bounded and as small as possible. Some existing real time algorithms for checkpoints use a paging mechanism to achieve latency on the order of 0. 1 seconds [50, 100]. The ability of reverse execution in introspective computers provides a real time checkpoint with a minimal latency. The algorithm for a real time checkpoint consists of three phases: the copying of the internal processor state, the copying of the state in the main memory, and the application of ....

[Article contains additional citation context not shown here]

S. I. Feldman and C. B. Brown. IGOR: A system for program debugging via reversible execution. In Proceedings SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging, pages 112--123. ACM, 1988.

....transparent user level checkpointers, although most of the discussion applies to the other checkpointers as well. Name Functionality Computing platform Libckpt [PBKL95] Fault tolerance Uniprocessors Libckp [HKW95] Fault tolerance Uniprocessors Condor [TL95] Process migration Uniprocessors Igor [FB89] Debugging Uniprocessors Manetho [EZ92] Fault tolerance Message passing distributed systems MIST MPVM [CCK 95] Fault tolerance migration Message passing distributed systems CoCheck [Ste96] Fault tolerance migration Message passing distributed systems [CGS 96] Fault tolerance ....

....When an application modifies a fraction of its address space between checkpoints, incremental checkpointing can improve checkpointing performance. Incremental checkpointing Incremental checkpointing is a technique for automating read only memory exclusion using virtual memory primitives [FB89] With incremental checkpointing, following a checkpoint, all pages in memory are set to be read only. When the program attempts to write a read only page, an access violation occurs, and the checkpointer processes the resulting interrupt by storing the identity of the offending page in a list, ....

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112--123, January 1989.

....of checkpoint files. 4.5 Performance Optimizations One of the main strengths of libckpt as a checkpointing library is its implementation of performance optimizations. Since CLIP is built on top of libckpt, it too benefits from several performance optimizations. First is incremental checkpointing [9], which employs virtual memory primitives so that only pages that have been modified since the previous checkpoint are written to the checkpoint file. If a program contains a significant amount of read only data from checkpoint to checkpoint, incremental checkpointing can improve the performance ....

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112-- 123, January 1989.

....be lost, and three more days of non continuous failure free processor time will be needed to complete the job. Libckpt is a tool for transparent checkpointing on uniprocessors running Unix. It implements incremental and copy on write checkpointing, two optimizations well known in the literature [2, 3, 9, 10]. Libckpt is a user level library and uses only facilities which are commonly available under Unix. Libckpt has been ported to and tested on a variety of architectures and operating systems with no kernel modifications. Source code for libckpt can be obtained at no cost by anonymous FTP from ....

....section, we consider each of them in turn. 2.1 Incremental Checkpointing When a checkpoint is taken, only the portion of the checkpoint that has changed since the previous checkpoint need to be saved. The unchanged portion can be restored from previous checkpoints. Incremental checkpointing [2, 3, 18] uses page protection hardware to identify the unchanged portion of the checkpoint. Saving only the changed portion reduces the size of each checkpoint, and thus the overhead of checkpointing. incremental onjoff turns incremental checkpointing on or off. The default is off. In general, the size ....

[Article contains additional citation context not shown here]

S. I. Feldman and C. B. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112--123, Jan 1989.

No context found.

Stuart I. Feldman and Channing B. Brown, "IGOR: A System for Program Debugging via Reversible Execution," Proceedings of the SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging, pp112-123, Madison, WI, May 1988.

....including interactions with the operating system. Previous work on dynamic analysis for program tracing has focused on the idea of intermediate process checkpoints. The igor system uses the operating system virtual memory facilities to periodically checkpoint the execution of a user program [5]. Past program states can be recreated from the checkpoints, but this technique traces orders of magnitude more data than necessary. Many techniques for improving incremental checkpoints have been proposed, including recent work by Plank, Xu, and Netzer on compressed differences [17] Although ....

....machine from the address referenced by each memory access, and perform an appropriate transition on this state machine. Previous work with tracing at the granularity of virtual memory pages produced impractical amounts of trace data; orders of magnitude more data than necessary was traced [5]. The monitoring machines use a comparatively large amount of storage during program execution, but pay dividends by yielding extremely fast instrumentation code and smaller trace sizes. We now examine the design of monitoring machines for replay tracing, and then consider how storage for such ....

S. Feldman and C. Brown. IGOR: A system for program debugging via reversible execution. In Proceedings of the SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging, Madison, WI, April 1988.

No context found.

S.I. Feldman and C.B. Brown. IGOR: A system for program debugging via reversible execution. In Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and Distributed Debugging, pages 112--123, May 1988.

No context found.

S. Feldman and C. Brown. Igor: A system for program debugging via reversible execution. ACM SIGPLAN Notices, Workshop on Parallel and Distributed Debugging, 24(1):112{ 123, Jan. 1989.

No context found.

S. Feldman and C. B. Brown, "IGOR: A System for Program Debugging via Reversible Execution," In Proceedings of the ACM SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging, SIGPLAN Notices, pages 112-123, January 1989.

No context found.

Stuart I. Feldman and Channing B. Brown, `Igor: a system for program debugging via reversible execution', Proc. Workshop on Parallel and Distributed Debugging, Madison, Wisconsin, May 1988. ACM Press. SIGPLAN Notices, 24, (1), 112--123 (1989).

No context found.

S. I. Feldman and C. B. Brown, `IGOR: a system for program debugging via reversible execution', ACM SIGPLAN and SIGOPS: Workshop on Parallel and Distributed Debugging, 24, (1), 112--123 (1989).

First 50 documents

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