US6421739B1 - Fault-tolerant java virtual machine - Google Patents

Abstract

A method for providing a first JVM with support for fault tolerance by using information maintained by the first JVM to checkpoint objects that are created, modified, and/or deleted during the process of responding to an event of a transaction. The checkpointed objects are sent to and stored in a second JVM such that the second JVM is fully capable of continuing the processing of the transaction in the event of the failure of the first JVM.

Description

TECHNICAL FIELD

The invention relates generally to Java virtual machines and, more particularly, to a Java virtual machine with built-in support for fault-tolerant operation.

BACKGROUND OF THE INVENTION

Large-scale, complex computer systems are brought into use through integration of software programs with a hardware platform. It is important that such systems be reliable and, because many such systems are “servers,” they are expected to run continuously for long periods of time without failure or interruption. As a result, various techniques, such as the use of special-purpose redundant hardware, are employed to ensure continuous service. Such techniques provide what is often collectively referred to as “fault tolerance” because they enable such systems to mask, i.e., recover, from a fault, such as the failure of a hardware component.

Fault-tolerance may also be obtained through software technology that utilizes commodity hardware that is less expensive. Frequently, such techniques utilize “checkpoints” wherein system status from one instance of an application is copied to a backup instance, such that the backup instance can take over processing using the copied system status as a starting point.

A telecommunication network is an example of a complex system that must be reliable. Telecommunication networks facilitate communications between a large number of public and private communications systems by providing numerous functions such as switching, accounting, time management, and the like. A telecommunications network provides such functions through network switches, or nodes, interconnected by links, or channels, of transmission media such as wire, fiber-optic cable, or radio waves. Some of the nodes are connected to one or more users.

Modern telecommunication networks require complex, automated switching and, to that end, software programs are written to provide reliable, dependable performance and efficient use of resources, as well as service features and functions, such as Call Waiting, Caller ID, and the like. Such systems may be configured in a number of different ways depending on what types of transmission media are used, what types of users are served, and what mix of features are purchased. As a result of such complexities and the large number of different configurations, it is difficult to operate such systems reliably and dependably. Software programs that operate such systems must, thus, be extremely reliable and achieve very a high fault-tolerance.

A programming language adapted for implementing software for such systems is “Java” which was introduced by Sun Microsystems, Inc., of Palo Alto, Calif. Java has been described as an object-oriented, distributed, interpreted, robust, secure, portable, architecture-neutral, multithreaded, and dynamic computer language.

To obtain fault-tolerance for software systems using Java, application software may be written such that all fault-tolerance capabilities, include the derivation of checkpoints, is built into the application program by its developer. However, experience has shown that this may not be an optimal solution. In many cases, changes to application programs are made without correctly changing the portions of the programs which effect the checkpointing, such that the checkpoints are not accurate and the system state copied to the backup is corrupt. In addition, mechanisms developed in application software may also be intrusive to the software source code (since additional code is added in ways that obfuscate understanding of the working of the system under normal conditions), or introduce additional inefficiencies into the software program.

Accordingly, a continuing search has been directed to the development of methods for mechanisms within the JVM which allow the JVM to support checkpointing in ways that are less intrusive, more efficient, and more likely to compute accurate checkpoint data.

SUMMARY OF THE INVENTION

According to the present invention, a method is disclosed for reliably and efficiently supporting fault-tolerance mechanisms within a Java virtual machine (JVM) by modifying the JVM itself. Such modifications to a first JVM permit the first JVM to use internal information maintained by the first JVM to checkpoint objects that are created, modified, and/or deleted during the process of responding to an event of a transaction. The checkpointed objects are sent to and stored in a second JVM such that the second JVM may take over the responsibilities of the first JVM should the first JVM fail. The application-level programmer is thus relieved of the burden of incorporating checkpointing into the source code and/or object code of an application program.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic diagram illustrating an arrangement of Java Virtual Machines (“JVMs”) interconnected to a network;

FIG. 2 is a flow chart illustrating steps for implementing the present invention; and

FIGS. 3-18 are a series of schematic diagrams illustrating the creation, modification, deletion, and movement of objects during the processing of events comprising a network transaction in accordance with the present invention.

DETAILED DESCRIPTION

Referring to FIG. 1 of the drawings, thereference numeral10 generally designates a system comprising anetwork20 connected to a first Java Virtual Machines (“JVMs”)30 and to asecond JVM40 embodying features of the present invention. Thenetwork10 may comprise, for example, a telecommunications network, such as a Public Land Mobile Network (PLMN, not shown) comprising, for example, a conventional telephone, a private branch exchange (PBX), an access tandem, a personal computer (PC) modem, access to the Internec, or the like.

The JVMs30 and40 may be implemented on the same or different computer platforms (not shown), which platforms may be selected from any of a number of different computer platforms, such as a personal computer (“PC”), a Macintosh computer, a Unix workstation, or the like, running any one of a number of different operating systems, such as Unix, Linux, Windows, MacOS, or the like. Such computer platforms and operating systems are considered to be well-known and will, therefore, not be described in further detail.

As described further below, theJVMs30 and40 include aheap memory32 and42, respectively, acheckpoint environment function34 and44, respectively, and agarbage collection function36 and46, respectively.

Theheap memories32 and42 are partitioned into aportion32aand aportion42a, respectively, for storage of a suitable application program effective for processing transactions transmitted from thenetwork20 to theJVMs30 and40. It is not necessary that such application program include any function configured for checkpointing, described further below.

Thegarbage collection functions36 and46 are responsible for managing heap memory and freeing up heap memory occupied by data objects that are no longer referenced by the running application. Any of a number of different types of garbage collection functions are available and may be implemented for use within theJVMs30 and40; for example, generation-copying garbage collection functions which promote “live” objects (i.e., root object and objects referenced, or pointed to, by another object) from a “new” portion of memory to an “old” portion of memory may be used. For the sake of illustration and preference, the present invention will be described using such a generation-copying garbage collection function. To that end, theheap memories32 and42 are further partitioned into “NEW”memories32band42b, respectively, and “OLD”memories32cand42c, respectively, for use by the respectivegarbage collection functions36 and46.

Such generation-copyinggarbage collection functions36 and46 preferably utilize a “write barrier” (not shown), well-known in the art, by which all changes to data in heaps that are managed by a respective garbage collection function are tracked. When possible, the present invention reuses the write barrier of thegarbage collection functions36 and46, to thereby enhance the efficiency of thesystem10. Alternatively, theJVMs30 and40 may utilize a garbage collection function which does not provide for a write barrier, and a write barrier may be added, in a manner well-known in the art, to the checkpointing function described below.

The software application program residing in thememories32aand42apreferably uses event-driven “run-to-completion” models of processing, wherein, once an event is received, it is processed to completion without interruption from other threads or processes in the JVM, and a response is generated as appropriate. The point of receipt of such an event and the point of completion of processing of such an event define two points in time between which points the application program adds, modifies, and/or discards data objects stored in theheap memories32 and42, and thereby changes the state of the program. In accordance with the present invention, such added, modified, and discarded data objects are tracked by the write barrier of the garbage collection function, as discussed further below. The collection of a copy of the data objects which are added, modified, and discarded during an event represents the change in state of the program, and is referred to herein as a checkpoint. The checkpoint, as used herein, thus represents the difference, that occurs during the execution of a software application program between two points in time, to the state of that program, such state being represented by the data objects in theheap memory32 and42 of therespective JVMs30 and40. The checkpoint may thus be used to update the state of the program in another JVM. Because the application program is considered herein to run each event to completion, the state of the application program which is required to process the next event is captured by objects on the heap, thereby rendering it unnecessary to copy the processor stack, machine registers, and the like to the checkpoint.

To facilitate the production of the checkpoint, thecheckpoint environment34 is partitioned into three memory portions, namely an “ADD”portion34a, a “MODIFY”portion34b, and a “DISCARD”portion34c. Similarly, thecheckpoint environment44 is partitioned into three memory portions, namely an “ADD”portion44a, a “MODIFY”portion44b, and a “DISCARD”portion44c. While not shown as such, the memory portions of thecheckpoint environments34 and44 may be integrated with theheap memories32 and42 within therespective JVMs30 and40, and may use various data structures well-known in the art to track collections of objects in each portion. For the sake of illustration, it is assumed herein that aseparate checkpoint environment34 and44 exists for each transaction, though such is not necessary. Also for the sake of illustration, the example discussed below does not show interleaved processing of events for multiple transactions, though, such would normally be the case; instead, as depicted herein, one transaction is processed before thesystem10 accepts a next transaction.

While not shown, theJVMs30 and40 also include a system interface, an execution engine (for executing instructions contained in methods of loaded classes), threads, and the like. Still further, theJVMs30 and40 include a facility which maintains knowledge of the internal structure of all data objects of the application program in thememory32aand42a. These facilities are defined by the architecture of the respective JVM according to well-known specifications that a JVM must abide by in order to run Java software.

In accordance with the present invention, the software defining theJVMs30 and40 is modified to use many features conventionally provided by the respective JVMs to provide the JVMs with the capability to checkpoint transactions. To that end, FIG. 2 is a flowchart showing steps implemented by theJVMs30 and40, as modified in accordance with the present invention, for checkpointing. For the sake of conciseness, operation of the present invention will be exemplified using a transaction “T” comprising three events (i.e., messages) such as, for example, a simple telephone call with an “off-hook event”, an “answer message”, and “hang-up”, it being understood that a transaction may comprise more or less that three events. For the sake of illustration, the interconnections between thenetwork20 and theJVMs30 and40 will henceforth not be shown unless a message is being transmitted between them.

Referring to FIG. 2, instep202, execution begins and proceeds to step204 in which conventional protocols are used to determine which of theJVMs30 or40 will process the next event of a transaction received from thenetwork20. Such a determination may be based, for example, on the availability of a JVM or may be made to avoid using a JVM which is unreliable or which has failed. Techniques to make such a determination, such as the “process group” model, are well-known in the art and will not be discussed in detail herein. In the present example, it is assumed that, initially, thefirst JVM30 will process the next transaction and is thus designated as a primary JVM, and that thesecond JVM40 is designated as a backup JVM.

Instep206, theJVMs30 and40 await receipt of a first event of a next transaction from thenetwork20. Upon transmission from thenetwork20 of a first event of a next transaction, as depicted in FIG. 3, bothJVMs30 and40 receive and record the event in therespective heap memories32 and42.

Instep208, a determination is made by thefirst JVM30 whether the event received instep206 is the first event of a new network transaction T. If it is determined that the received event is a first event of a new transaction T, then execution proceeds to step210; otherwise execution proceeds to step212. Instep210, space is allocated in theNEW memories32band42bfor storing objects created as events of the transaction T are processed, as discussed further below. Upon allocation ofNEW memories32band42binstep208, execution proceeds to step212.

Instep212, the write barrier begins tracking the creation, modification, and deletion of data objects associated with the transaction T, as the current event is processed, to thereby continually updating thecheckpoint environment34. All new objects are added to theADD portion34a, all modified objects are added to the MODIFYportion34b, and the identity of all deleted objects is recorded in the DISCARDportion34c.

Instep214, the current event, as the first event in the sequence of the present example, is processed, in a manner well-known in the art, by a suitable application program stored in thememory portion32aof theJVM30. The processing of the event instep214 is preferably run to completion. As the event is so processed, data objects, exemplified herein asobjects1,2, and3, are created for the transaction T, as depicted in FIG. 4, wherein theobject1 “points” toobject2, and theobject2 “points” to theobject3. The creation of data objects and pointers between data objects is considered to be well-known in the art and will therefore not be discussed further.Object1 itself may be pointed to by data maintained in the processor's stack or register set, such that a garbage collection algorithm could locate it as a “live” object. Instep216, upon completion of the processing of the first event instep214, an appropriate response is generated and transmitted to thenetwork20, as depicted in FIG.5.

Instep218, theJVM30 makes a determination whether the current event is the last event of the transaction T being processed. If it is determined that the current event is not the last event, then execution proceeds to step204; otherwise, execution proceeds to step220. Atstep220, processing of the transaction T is complete and all data objects associated with the transaction T are discarded from bothJVMs30 and40, and execution returns to step204. For the present example, the event last processed (i.e., the first event) does not constitute the last event of the transaction T and execution will proceed fromstep218 to step222.

Instep222, thegarbage collection function36 is executed to eliminate any “dead” objects (i.e., objects not pointed to by another object) from theNEW memory32bbefore the checkpoint is calculated. Thisstep222 avoids the case where objects that are no longer part of the transaction's state are copied to the backup JVM, and thus improves the overall efficiency of the checkpointing process. Accordingly, the data objects1,2, and3 are “promoted” (i.e., moved) from theNEW memory32bto theOLD memory32c, as shown in FIG.6. The use here for the purpose of illustration of a generation-copying garbage collection function does not rule out the use of other techniques. However, the use of such a collector, with collections tied to the cycle of event processing, can improve both the efficiency of collection and that of the checkpointing function described in this invention. Garbage collection is considered to be well-known in the art and will, therefore, not be described in further detail herein.

Instep224, the content of the checkpoint is calculated, and the write barrier discontinues tracking changes to the heap space (for the purpose of checkpointing). Calculation of the checkpoint utilizes data in the ADD (34a), MODIFY (34b) and DISCARD (34c) portions of thecheckpoint environment34 to identify changes to the program state so that, as discussed below, objects in the ADD and MODIFY portions may be copied to thebackup JVM40, and objects identified in the DISCARD portion may be deleted from thebackup JVM40. FIG. 7 illustrates the state of the checkpoint environment atstep224 after processing the first event.

Instep226, the objects identified in the checkpoint calculation ofstep224 are “marshaled”. Accordingly, each identified object is encoded to ensure that it can be successfully transmitted from one JVM to the other, even if the JVMs run on heterogeneous computer platforms. Any suitable encoding technique, such as serialization which is currently employed in Java for remote method invocation (RMI), may be used to encode the identified objects. In the process of encoding, pointers between objects are converted to object identifiers or “tags” that are not dependent on machine addresses (i.e., addresses to memory spaces in a particular machine), such that a JVM receiving the objects can recreate the pointer-based associations between objects. Techniques for encoding objects and representing pointers are well-known in the art and will not be discussed further. Objects are preferably marshaled within theJVM30 using the JVM's internal knowledge about object structures and the efficiency of its internal software code. The checkpoint is formed from the encoded objects to be copied (from the ADD and MODIFYmemory portions34aand34b) and the record identifying objects to be discarded (from thememory portion34c), together with any administrative data necessary for managing the at least a portion of a checkpoint.

Instep228, the checkpoint generated instep224, comprising all objects stored- in the ADD and MODIFYmemory portions34aand34band identified in the DISCARDmemory portion34cof thecheckpoint environment34, is delivered to therespective memory portions44a,44b, and44cof thecheckpoint environment44 of thesecond JVM40, for storage and recordation therein, as shown in FIG.8. Various communication protocols well-known in the art are available for delivering the checkpoint message. The ADD (34a), MODIFY (34c), and DISCARD (34c) portions of thecheckpoint environment34 are cleared of data associated with the current (i.e., first) event of the transaction T.

Instep230, the checkpoint stored in thecheckpoint environment44 is moved to theOLD memory42cof thesecond JVM40, as shown in FIG.9. Additionally, the pointers are modified so that tags identifying objects pointed to are replaced with location addresses in theOLD memory42c, so that pointers used by thefirst JVM30 are correctly converted to point to the same objects in thesecond JVM40.

Execution of the foregoingsteps228 and230 is preferably performed immediately followingstep226 so that the transaction state of memory in theJVMs30 and40 are at substantially all times virtually identical. Upon completion ofstep230, execution returns to step204.

It can be appreciated that the state of the transaction T inold memories32cand42cof theJVMs30 and40, respectively, as depicted in FIG. 9, are virtually identical. Therefore, either of theJVMs30 or40 may process the next event of the transaction T. This is particularly advantageous if theJVM30 should fail or otherwise become unavailable to process the next event of the transaction T transmitted from thenetwork20.

In the event that thefirst JVM30 fails prior to completely processing the event and generating output and a checkpoint, then that event must be processed by thebackup JVM40. The coordination function described above instep204, using, for example, the “process group” model of software fault-tolerance, is responsible for handling such a failure. If (as shown in the present example) the event is the first event of the transaction, then thebackup JVM40 is effectively made the primary JVM and processes the transaction as if none of the steps described above had transpired.

Instep204, theJVMs30 and40 await the next event of the transaction T from thenetwork20. Upon receipt of the next event, i.e., the second event in the sequence of the present example, conventional protocols are implemented to determine which of theJVMs30 or40 will process the next event of the transaction T received from thenetwork20. In the present example, it is assumed that theJVM30 has not failed and is available and will therefore continue to process the transaction T. Therefore, theJVM30 will be designated to process the next event of the transaction T and continue as the primary JVM, and thesecond JVM40 will continue as a backup JVM.

Instep206, theJVMs30 and40 await receipt of the second event of the transaction T from thenetwork20. Upon transmission from thenetwork20 of the second event of the transaction T, as depicted in FIG. 10, bothJVMs30 and40 receive and record the event in therespective heap memories32 and42.

Instep208, a determination is made by thefirst JVM30 whether the event received instep206 is the first event of a new network transaction T. Since in the present example, the current event is a second event and not a first event, execution proceeds to step212. Instep212, the write barrier of thefirst JVM30 begins tracking the creation, modification, and deletion of data objects associated with the transaction T, as the current second event is processed.

Instep214, the current event, as the second event in the sequence of the present example, is processed, in a manner well-known in the art, by the application program stored in thememory portion32aof thefirst JVM30. As the second event is so processed, the data object2 is changed todata object2′, and the pointer from data object2′ is redirected to anew data object4 which is created in theNEW h memory32bfor the transaction T, as depicted in FIG.11. The data (root)object1 remains unmodified. Instep216, upon completion of the processing of the second event instep214, an appropriate response is generated and transmitted to thenetwork20, as depicted in FIG.12. During the processing of the event, thecheckpoint environment34 is updated; accordingly, theobject4 is added to the ADD portion.34a, and the data object2′ is added to the MODIFYportion34b.

Instep218, thefirst JVM30 makes a determination, as discussed above with respect to the first event, whether the current (i.e., second) event is the last event of the transaction T being processed. In the present example, the event last processed (i.e., the second event) does not constitute the last event of the transaction T and execution will proceed fromstep218 to step222.

Instep222, the data objects are garbage collected by thegarbage collection function36. Accordingly, because no object is pointing to thedata object3, that data object is discarded, and its identity recorded in the DISCARDportion34cof thecheckpoint environment34. The new created data object4 is “promoted” from theNEW memory32bto theOLD memory32c, as shown in FIG.13.

Instep224, the content of the checkpoint is calculated. At this point, changes to the heap space (for the purpose of checkpointing) are no longer tracked by the write barrier. The checkpointing function uses data in the ADD (34a), MODIFY (34b) and DISCARD (34c) portions of thecheckpoint environment34, to determine the changes to the program state which must be communicated to thebackup JVM40.

Instep226, the objects to be copied to thebackup JVM40 are “marshaled”. The objects to be copied and the list of objects to be discarded, together with any necessary administrative data, is formed into a checkpoint message which can be sent between JVMs.

Instep228, the checkpoint generated instep226, comprising all objects stored in thecheckpoint environment34, is delivered to thecheckpoint environment44 of thesecond JVM40, as shown in FIG.14. The ADD (34a), MODIFY (34c), and DISCARD (34c) portions of thecheckpoint environment34 are cleared of data associated with the current (i.e., second) event of the transaction T.

Instep230, the checkpoint stored in thecheckpoint environment44 is moved to theOLD memory42cof thesecond JVM40, as shown in FIG.15. Additionally, the pointers are modified so that tags identifying objects pointed to are replaced with location addresses in theOLD memory42c, so that pointers used by thefirst JVM30 are correctly converted to point to the same objects in thesecond JVM40.

Execution of the foregoingsteps228 and230 is preferably performed immediately followingstep226 so that the transaction state of memory in theJVMs30 and40 are at substantially all times virtually identical. Upon completion ofstep230, execution returns to step204.

As discussed above with respect to completion of the first event, it can be appreciated that, upon completion of the second event, the state of the transaction T inold memories32cand42cof theJVMs30 and40, respectively, as depicted in FIG. 15, are virtually identical. Therefore, either of theJVMs30 or40 may process a next (third) event of the transaction T.

Instep204, theJVMs30 and40 await the next event of the transaction T from thenetwork20. Upon receipt of the next event, i.e., the third event in the sequence of the present example, conventional protocols are implemented as discussed above to determine which of theJVMs30 or40 will process the next event of the transaction T received from thenetwork20. In the present example, it is assumed that thefirst JVM30 has not failed and is available and will therefore continue to process the transaction. Therefore, thefirst JVM30 will be designated to process the next event of the transaction T and continue as the primary JVM, and thesecond JVM40 will continue as a backup JVM.

Instep206, theJVMs30 and40 await receipt of the third event of the transaction T from thenetwork20. Upon transmission from thenetwork20 of the third event of the transaction T, as depicted in FIG. 16, bothJVMs30 and40 receive and record the event in therespective heap memories32 and42.

Instep208, a determination is made by thefirst JVM30 whether the event received instep206 is the first event of a new network transaction T. Since in the present example, the current event is a third event and not a first event, execution proceeds to thestep212. Instep212, the write barrier of thefirst JVM30 begins tracking the creation, modification, and deletion of data objects associated with the transaction T, as the current third event is: processed.

Instep214, the current event, as the third event in the sequence of the present example, is processed, in a manner well-known in the art, by the application program stored in thememory portion32aof thefirst JVM30. The processing of the event instep214 is preferably run to completion. As the third event is so processed, the root data object1 is modified to be data object1′, the data object4 is modified to be data object4′, and the pointer from data object1′ is redirected to the modifieddata object4′, as depicted in FIG.17. Additionally, anew data object5 is created in theNEW memory32b, and the pointer from theobject4 is directed to theobject5. Instep216, upon completion of the processing of the third event instep214, an appropriate response is generated and transmitted to thenetwork20, as depicted in FIG.18. During the processing of the event, thecheckpoint environment34 is updated. Accordingly, theobject5 is added to theADD portion34a, and the data objects1′ and4′ are added to the MODIFYportion34b.

Instep218, thefirst JVM30 makes a determination, as discussed above with respect to the first event, whether the current (i.e., third) event is the last event of the transaction T being processed. In the present example, the third event constitutes the last event. Therefore, execution proceeds to step220 wherein processing of the transaction T is complete and all data objects associated with the transaction T are discarded from bothJVMs30 and40. In the present case, the identity of all objects associated with transaction T is effectively added to the DISCARDportion34cof thecheckpoint environment34. A (final) checkpoint message is sent from theprimary JVM30 to thebackup JVM40 indicating that the transaction is complete and that all saved state objects may be discarded. Theprimary JVM30 then clears itscheckpoint environment34 of all data associated with the transaction T and, upon receipt of the message sent from theJVM30 to theJVM40, thebackup JVM40 similarly discards the contents of itscheckpoint environment42.

The configuration of theJVMs30 and40 then returns to that shown in FIG. 1, and execution returns to step204.

By the use of the present invention, existing JVM functions such as garbage collection facilities, are enhanced so that application programs running on the JVM may be automatically checkpointed to one or more backup JVMs. Key internal functions of the JVM, such as its garbage collection function with a write barrier, as well as its internal knowledge of object structures, are reused and expanded upon to offer maximum efficiency to automatically determine checkpoint content and encode the checkpoint for transmission to one or more backups JVMs. In this manner, construction of a fault-tolerant system10 is facilitated, thereby enabling transactions to be continually processed, and preventing the failure of an individual JVM (for example, due to hardware failure) to cause an entire individual transaction to fail. Such checkpointing may be achieved without requiring any additions to or modifications of the source code or object code of the application, thereby simplifying both the development and testing of such software programs without undue burden. Checkpointing is also synchronized with garbage collection so that data that is to be checkpointed between JVMs is minimized. Such checkpointing may also be faster and more reliable than conventional checkpointing.

It is understood that the present invention can take many forms and embodiments. Accordingly, several variations may be made in the foregoing without departing from the spirit or the scope of the invention; for example, more than one application program may be loaded into asingle JVM30 or40, and the primary JVM may deliver the checkpoint to more than one backup JVM.

In another variation, any one of a number of different types of garbage collection algorithms may be implemented.

In still another variation, determination of the checkpoint contents may be refined so that only changed portions of objects are transferred between machines, rather than complete objects as shown in the description above.

In still another variation, the objects that are to be discarded, rather than just the identity of such objects, may be stored in the DISCARDmemory portion34c.

In yet another variation, thestep230 may be bypassed and the checkpoint maintained in thecheckpoint environment44, or stored in other memory, such as a hard disk, until theJVM30 fails, at which time the checkpoint is moved to theOLD memory42cof theheap memory42, and pointers are modified as discussed above. In addition to the advantages discussed above, such a variation would conserve theheap memory42 and require less overall processor time from theJVM40.

In yet another variation, thesteps228 and230 may be combined, and a checkpoint from thefirst JVM30 may be delivered directly to thememory42cof theJVM40 without being intermediately stored in thecheckpoint environment44. In addition to the advantages discussed above, such a variation would be more efficient and would permit theJVM40 to be configured without thecheckpoint environment44, thereby also conserving memory resources.

Having thus described the present invention by reference to certain of its preferred embodiments, it is noted that the embodiments disclosed are illustrative rather than limiting in nature and that a wide range of variations, modifications, changes, and substitutions are contemplated in the foregoing disclosure and, in some instances, some features of the present invention may be employed without a corresponding use of the other features. Many such variations and modifications may be considered obvious and desirable by those skilled in the art based upon a review of the foregoing description of preferred embodiments. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention.

Claims (33)

What is claimed is:

1. A method for providing a first Java Virtual Machine (“JVM”) with mechanisms to support fault-tolerant operation, comprising the steps of:

(a) modifying the first JVM to use information maintained by the first JVM to identify objects that are created, modified, and/or discarded during a process of responding to an event of a transaction, such objects that are created, modified, and/or discarded during a process of responding to an event of a transaction defining at least a portion of a checkpoint;

(b) delivering to at least one second JVM the at least a portion of a checkpoint; and

(c) storing in the at least one second JVM the at least a portion of a checkpoint for use by the at least one second JVM in the processing of subsequent events of the transaction.

2. The method ofclaim 1 further comprising providing the first JVM with a garbage collection function having a write barrier, and wherein the step of modifying further comprises using the write barrier to track objects that are created, modified, and/or discarded during a process of responding to an event of a transaction.

3. The method ofclaim 1 further comprising providing the first JVM with a write barrier, and wherein the step of modifying further comprises using the write barrier to track objects that are created, modified, and/or discarded during a process of responding to an event of a transaction.

4. The method ofclaim 1 further comprising the steps of:

(a) garbage collecting objects stored on the first JVM prior to the step of delivering; and

(b) modifying the first JVM to use information maintained by the first JVM to identify objects that are created, modified, and/or discarded during the step of garbage collection.

5. The method ofclaim 1 wherein the first JVM comprises a first checkpoint environment, the at least one second JVM comprises at least one second checkpoint environment, and the step of modifying further comprises storing the at least a portion of a checkpoint in the first checkpoint environment, and the step of delivering further comprises delivering the at least a portion of a checkpoint to the at least one second checkpoint environment of the at least one second JVM, and the step of storing further comprises the step of transferring the at least a portion of a checkpoint from the at least one second checkpoint environment to a memory of the at least one second JVM.

6. The method ofclaim 1 further comprising, substantially immediately subsequent to the step of storing, the step of processing the at least a portion of a checkpoint so that substantially the same transaction state is maintained in the memories of the first JVM and the at least one second JVM at substantially all times.

7. The method ofclaim 1 further comprising, subsequent to the step of delivering, storing the at least a portion of a checkpoint into a checkpoint environment of the at least a second JVM and, upon a failure of the first JVM, transferring the at least a portion of a checkpoint into memory of the at least one second JVM and replicating in the memory of the at least one second JVM the transaction state of the first JVM prior to failure of the first JVM so that the at least one second JVM is enabled to process subsequent events of the transaction.

8. The method ofclaim 1 wherein the at least a portion of a checkpoint further comprises administrative data for managing the at least a portion of a checkpoint.

9. The method ofclaim 1 wherein the step of delivering further comprises encoding and decoding objects and/or portions of objects.

10. The method ofclaim 1 wherein the step of delivering further comprises encoding and decoding objects and/or portions of objects, and the steps of encoding and decoding further comprises the steps of tracking pointers in the first JVM and adjusting pointers within the at least one second JVM to replicate in the at least one second JVM the relationships created between objects in the memory of the first JVM.

11. The method ofclaim 1 wherein the step of modifying further comprises determining within the first JVM the necessary content of the at least a portion of a checkpoint to permit replication in the at least one second JVM of the transaction state in the first JVM subsequent to the processing of an event of a transaction.

12. A method for providing a first Java Virtual Machine (“JVM”) with mechanisms to support fault-tolerant operation, comprising the steps of:

(a) modifying the first JVM to use information maintained by the first JVM to identify objects that are created, modifications that are made to objects, and/or objects that are discarded during a process of responding to an event of a transaction, such objects that are created, modifications that are made to objects, and/or objects that are discarded during a process of responding to an event of a transaction defining at least a portion of a checkpoint;

(b) delivering to at least one second JVM the at least a portion of a checkpoint; and

(c) storing in the at least one second JVM the at least a portion of a checkpoint for use by the at least one second JVM for processing subsequent events of the transaction.

13. The method ofclaim 12 further comprising providing the first JVM with a garbage collection function having a write barrier, and wherein the step of modifying further comprises using the write barrier to track objects that are created, modifications that are made to objects, and/or objects that are discarded during a process of responding to an event of a transaction.

14. The method ofclaim 12 further comprising providing the first JVM with a write barrier, and wherein the step of modifying further comprises using the write barrier to track objects that are created, modifications that are made to objects, and/or objects that are discarded during a process of responding to an event of a transaction.

15. The method ofclaim 12 further comprising the steps of:

(a) garbage collecting objects stored on the first JVM prior to the step of delivering; and

(b) modifying the first JVM to use information maintained by the first JVM to identify objects that are created, modifications that are made to objects, and/or objects that are discarded during the step of garbage collection.

16. The method ofclaim 12 wherein the first JVM comprises a first checkpoint environment, the at least one second JVM comprises at least one second checkpoint environment, and the step of modifying further comprises storing the at least a portion of a checkpoint in the first checkpoint environment, and the step of delivering further comprises delivering the at least a portion of a checkpoint to the at least one second checkpoint environment of the at least one second JVM, and the step of storing further comprises the step of transferring the at least a portion of a checkpoint from the at least one second checkpoint environment to a memory of the at least one second JVM.

17. The method ofclaim 12 further comprising, substantially immediately subsequent to the step of storing, the step of processing the at least a portion of a checkpoint so that substantially the same transaction state is maintained in the memories of the first JVM and the at least one second JVM at substantially all times.

18. The method ofclaim 12 further comprising, subsequent to the step of delivering, storing the at least a portion of a checkpoint into a checkpoint environment of the at least a second JVM and, upon a failure of the first JVM, transferring the at least a portion of a checkpoint into memory of the at least one second JVM and replicating in the memory of the at least one second JVM the transaction state of the first JVM prior to failure of the first JVM so that the at least one second JVM is enabled to process subsequent events of the transaction.

19. The method ofclaim 12 wherein the at least a portion of a checkpoint further comprises administrative data for managing the at least a portion of a checkpoint.

20. The method ofclaim 12 wherein the step of delivering further comprises encoding and decoding objects and/or portions of objects.

21. The method ofclaim 12 wherein the step of delivering further comprises encoding and decoding objects and/or portions of objects, and the steps of encoding and decoding further comprises the steps of tracking pointers in the first JVM and adjusting pointers within the at least one second JVM to replicate in the at least one second JVM the relationships created between objects in the memory of the first JVM.

22. The method ofclaim 12 wherein the step of modifying further comprises determining within the first JVM the necessary content of the at least a portion of a checkpoint to permit replication in the at least one second JVM of the transaction state in the first JVM subsequent to the processing of an event of a transaction.

23. A method for providing a first Java Virtual Machine (“JVM”) with mechanisms to support fault-tolerant operation, comprising the steps of:

(a) modifying the first JVM to use information maintained by the first JVM to identify objects that are created, modified, and/or discarded during a process of responding to an event of a transaction, such objects that are created, modified, and/or discarded during a process of responding to an event of a transaction defining at least a portion of a checkpoint; and

(b) storing the at least a portion of a checkpoint in a checkpoint memory accessible by the at least one second JVM for use by the at least one second JVM in the processing of subsequent events of the transaction.

24. The method ofclaim 23 further comprising providing the first JVM with a garbage collection function having a write barrier, and wherein the step of modifying further comprises using the write barrier to track objects that are created, modified, and/or discarded during a process of responding to an event of a transaction.

25. The method ofclaim 23 further comprising providing the first JVM with a write barrier, and wherein the step of modifying further comprises using the write barrier to track objects that are created, modified, and/or discarded during a process of responding to an event of a transaction.

26. The method ofclaim 23 further comprising the steps of:

(a) garbage collecting objects stored on the first JVM prior to the step of delivering; and

(b) modifying the first JVM to use information maintained by the first JVM to identify objects that are created, modified, and/or discarded during the step of garbage collection.

27. The method ofclaim 23 wherein the first JVM comprises a first checkpoint environment, the at least one second JVM comprises at least one second checkpoint environment, and the step of modifying further comprises saving the at least a portion of a checkpoint in the first checkpoint environment, and the step of storing further comprises storing the at least a portion of a checkpoint to the at least one second checkpoint environment of the at least one second JVM, and transferring the at least a portion of a checkpoint from the at least one second checkpoint environment to a memory of the at least one second JVM.

28. The method ofclaim 23 further comprising, substantially immediately subsequent to the step of storing, the step of processing the at least a portion of a checkpoint so that substantially the same transaction state is maintained in the memories of the first JVM and the at least one second JVM at substantially all times.

29. The method ofclaim 23 further comprising, subsequent to the step of storing, saving the at least a portion of a checkpoint into a checkpoint environment of the at least a second JVM and, upon a failure of the first JVM, transferring the at least a portion of a checkpoint into memory of the at least one second JVM and replicating in the memory of the at least one second JVM the transaction state of the first JVM prior to failure of the first JVM so that the at least one second JVM is enabled to process subsequent events of the transaction.

30. The method ofclaim 23 wherein the at least a portion of a checkpoint further comprises administrative data for managing the at least a portion of a checkpoint.

31. The method ofclaim 23 wherein the step of delivering further comprises encoding and decoding objects and/or portions of objects.

32. The method ofclaim 23 wherein the step of delivering further comprises encoding and decoding objects and/or portions of objects, and the steps of encoding and decoding further comprises the steps of tracking pointers in the first JVM and adjusting pointers within the at least one second JVM to replicate in the at least one second JVM the relationships created between objects in the memory of the first JVM.

33. The method ofclaim 23 wherein the step of modifying further comprises determining within the first JVM the necessary content of the at least a portion of a checkpoint to permit replication in the at least one second JVM of the transaction state in the first JVM subsequent to the processing of an event of a transaction.

Images