Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
2000-08-31
2004-04-06
Chaki, Kakali (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
Reexamination Certificate
active
06718538
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to process checkpointing, and in particular to a method and apparatus for performing hybrid checkpointing.
2. Background Art
Computing environments use a technique known as “checkpointing” which involves saving the state of a program, usually to stable storage, so that it may be reconstructed later in time. Checkpointing is useful for long running computer programs, recovering from a system crash, playback debugging, process migration and job swapping, for example. A checkpoint is like a snapshot in time of the computing environment in which the program is executing. Current problems with checkpointing procedures include latency, the time it takes to store the state of the computing environment on stable storage (such as a disk drive), and the amount of storage space required for the checkpoint.
In some prior art checkpointing the data volume of a checkpoint is roughly proportional to the occupied main memory space of the respective checkpointed process. Due to the volume, such checkpointing operations have an undesirably high latency. Parallelization can improve responsiveness. For instance, UNIX™ based operating system environments provide a “fork” command. When a fork instruction is executed, the process concerned splits into a parent and child process. Both the parent and child process continue to execute independently from after the fork intruction. Using such functionality, one can simultaneously checkpoint both the parent and child processes. This type of parallelization, however, does not reduce overall resource consumption.
Internal Checkpointing
Internal checkpointing can be used to implement persistent programming languages. Persistent programming languages are languages that are extended to handle persistent data. Persistent data is data that continues to exist even after the process that created it has stopped executing. Existing persistent programming language implementations include: Napier, Tycoon, and PJama, for instance.
Persistent programming languages utilize object caches. Caches are implemented under the assumption that it is very likely that some piece of data will be repeatedly accessed. Access delays are minimized by keeping popular data close to the entity which needs it. Object caches allow for efficient internal checkpointing on a per object basis. Large amounts of memory may be checkpointed with few writes to disk. In addition, persistent programming languages can update the cache automatically. Thus, persistent programming languages implementing object caches produce relatively low data volume per checkpoint and have a short latency. In addition, persistent programming languages implementing object caches can operate when the size of the data exceeds the size of virtual memory.
Persistent programming languages with an external programming interface, however, cannot capture the entire execution state of a program. The internal execution state resides in an object heap. An object heap is an area of memory reserved for objects that are created at runtime—that is, when the program actually executes. Taking the object heap and checkpointing the objects in that heap does not allow one to checkpoint native states, such as execution threads, native functions, or memory allocation regions that are not on the object heap, but reside on other general purpose heaps. Thus, data that is outside the direct control of the given runtime system (native data) is lost. Some native data can be integrated by dedicated explicit programming in the persistent language and external languages, but this is generally not possible.
Native Checkpointing
Native checkpointing records the native state of a process to a secondary storage medium. The native state of a process comprises, for example, memory regions that have been allocated and memory mapped, the contents of those regions, (i.e., copies of the random access memory that contains those regions), active thread stacks, registers for the active threads, and kernel state, such as signal handlers and file handles and other entities that allow the operating system to support the program. Compression reduces the data volume associated with checkpointing by compressing the data that is stored.
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 usually may be implemented through the use of 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. Old checkpoint files, however, cannot be deleted when incremental checkpointing is employed, because the program's data state is spread out over many checkpoint files. Thus, the cumulative size of incremental checkpoint files will increase at a steady rate over time, since many updated values may be saved for the same page.
Native checkpointing in a Java™ environment have been described in connection with the “icee system”. The icee system is based entirely on a paging system implemented by the Solari™ version 2.5.1 operating system. (John Howell, Straightforward Java Persistence Through Checkpointing, in Advances in Persistent Object Systems, Ron Morrison, Mick Jordan, and Malcolm Atkinson, editors, pages 322-334, Morgan Kaufman, 1999. (Presented at the Third International Workshop on Persistence and Java, Sep. 1-3, 1998.) Compression and incremental techniques can take place in an infinite number of computing environments. An example of a Java technology environment where these techniques can be implemented is described below.
Java Technology Environment Example
A program which utilizes Java technology is composed of a number of classes and interfaces. Unlike many programming languages, in which a program is compiled into machine-dependent, executable program code, programs which utilize Java technology are compiled into machine independent bytecode class files. Each class contains code and data in a platform-independent format called the class file format. The computer system acting as the execution vehicle contains a program called a virtual machine, which is responsible for executing the code in classes. The virtual machine provides a level of abstraction between the machine independence of the bytecode classes and the machine-dependent instruction set of the underlying computer hardware. A “class loader” within the virtual machine is responsible for loading the bytecode class files as needed, and either an interpreter executes the bytecodes directly, or a “just-in-time” (JIT) compiler transforms the bytecodes into machine code, so that they can be executed by the processor.
FIG. 1
is a block diagram illustrating a sample network application environment, for instance a Java network application environment, comprising a client platform
102
coupled over a network
101
to a server
100
for the purpose of accessing class files for execution of an application or applet.
Sample Network Application Environment
In
FIG. 1
, server
100
comprises development environment
104
for use in creating the class files for a given application. The development environment
104
provides a mechanism, such as an editor and an applet viewer, for generating class files and previewing applets. A set of core classes
103
comprise a library of classes that can be referenced by source files containing other
ew classes. From development environment
104
, one or more source files
105
are generated. Source files
105
contain the programmer readable class definitions, including data structures, method implementations and references to other classes. Source files
105
are provided to compiler
106
, which compiles source files
105
into compiled “.class” files
107
that contain bytecodes executable by a virtual machine. Bytecode class files
107
are stored (e.g., in temporary or permanent storage) on server
100
, a
Chaki Kakali
Park Vaughan & Fleming LLP
Sun Microsystems Inc.
Vu Tuan Anh
LandOfFree
Method and apparatus for hybrid checkpointing does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for hybrid checkpointing, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for hybrid checkpointing will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3269084