Methods and apparatuses for application checkpointing, and related products

Abstract

The present disclosure provides a method for application checkpointing. The method includes: obtaining an application for evaluating a hardware architecture of a hardware component; and obtaining, from a functional simulator on which the application is executed, a plurality of checkpoints of the application, where the plurality of checkpoints are executable and an interval between every two consecutive checkpoints is the same.

Description

METHODS AND APPARATUSES FOR APPLICATION CHECKPOINTING, AND RELATED PRODUCTSTECHNICAL FIELD “ 1

[0001] The present disclosure relates generally to the field of hardware-software co-design technologies, and more particularly to methods and apparatuses for application checkpointing, and related products.BACKGROUND

[0002] The process of designing a hardware architecture (e.g. a hardware architecture of a chip, processor, or system on chip (SoC)) may include several levels of models, each serving a specific purpose in the design cycle. Characteristics of the hardware architecture may be determined by executing corresponding real applications on these levels of models. Execution speeds of these applications may vary across these levels of models. An execution speed of an application on a model is measured in instructions per second (IPS) and is dependent on the model's granularity — the more detailed the model, the slower the execution speed.

[0003] One of the characteristics of the hardware architecture is its performance. The most detailed model, e.g. a register transfer leveL(RTL) model, serves as a performance model and is used to generate performance data for some real applications. However, the RTL model operates at a speed of several instructions per second and is costly to modify, which means it may take years to generate performance data for some real applications.

[0004] When making changes to the RTL model, it is reasonable to expect that these changes may significantly improve performance. To ensure such an improvement, it is beneficial to use a performance model with less granularity but faster speed. These models may operate at speeds of approximately 100 kilo instructions per second (KIPS). Nonetheless, obtaining performance data for some real applications using these models may still require a considerable amount of time, ranging from months to years.SUMMARY

[0005] The present disclosure provides methods and apparatuses for application checkpointing, and related products, to accelerate significantly the performance model of the hardware architecture.

[0006] According to a first aspect, a method for application checkpointing is provided. The method may be performed by a computing device or a module (such as a chip or a circuit) in the computing device. The method may include: obtaining an application for evaluating a hardware architecture of a hardware component; and obtaining, from a functional simulator on which the application is executed, a plurality of checkpoints of the application, where the plurality of checkpoints are executable and an interval between every two consecutive checkpoints is the same.

[0007] The hardware architecture of the hardware component may include several levels of models, each serving a specific purpose in the design cycle, such as a functional model and a performance model. The functional model and the performance model may sometimes be referred to as a functional simulator and a performance simulator, respectively. The functional model is used to emulate the functionality of the hardware architecture visible to a user such as a developer or a programmer and the performance model is used to obtain performance of the hardware architecture, where the performance is one key characteristic for the hardware architecture.

[0008] The hardware architecture may be either a newly developed hardware architecture or an enhancement of an existing hardware architecture of a hardware component. The hardware component may take the form of a chip, a processor, a system on chip (SoC), an integrated circuit, or other similar components. The form of the hardware component with this architecture is not restricted in this context.

[0009] Benchmarks or tests for evaluating the hardware architecture may be sourced from standard committees that specialize in developing such benchmarks or tests for various architectural types. The application used for these evaluations(i.e. the applications for evaluating the hardware architecture) may be either acquired from these standard committees directly or self-developed. The manner of obtaining the application and the content of the application are not restricted in this context.

[0010] According to the method for application checkpointing, the application for evaluating the hardware architecture is obtained, and the plurality of checkpoints of the application are obtained from the functional simulator on which the application is executed, where the plurality of checkpoints are executable and the interval between every two consecutive checkpoints is the same. The interval between every two consecutive checkpoints is the same, ensuring that the interval between each pair of consecutive checkpoints is uniform. The uniform intervals may eliminate longer intervals and waiting times for longer intervals, and thus a performance model of the hardware architecture may be accelerated significantly in a case where the plurality of checkpoints are executed by the performance model of the hardware architecture in parallel. Consequently, this may lead to a substantial acceleration in the design process for the hardware architecture. Additionally, the checkpoints obtained in this method for application checkpointing may be executable, and the executable checkpoints may be easy to load to any performance or other simulator, or to be executed natively on the current workstation. In addition, in this method for application checkpointing, due to the compatibility of executable checkpoints, when some execution environments need some formats on the checkpoints, there is no need for users to modify their own performance simulators and no need for further recompilation of the applications on the performance simulators.

[0011] In a possible design, the method further includes: obtaining a plurality of first performance results by executing in parallel the plurality of checkpoints on a performance simulator; and obtaining a second performance result of the hardware architecture according to the plurality of first performance results.

[0012] According to the method for application checkpointing, the plurality of first performance results are obtained by executing in parallel the plurality of checkpoints on the performance simulator, and the second performance result of the hardware architecture is obtained according to the plurality of first performance results. The plurality of checkpoints are executed by the performance model of the hardware architecture in parallel and the performance model of the hardware architecture may be accelerated significantly. Consequently, this may lead to a substantial acceleration in the design process for the hardware architecture. Furthermore, the performance simulation speedup is directly proportional to the computational power of the computing cluster for executing in parallel the plurality of checkpoints on the performance simulator.

[0013] Furthermore, in a case where the performance simulator is changed or updated, the plurality of third performance results are obtained by executing in parallel the plurality of checkpoints on the changed or updated performance simulator, and the fourth performance result of the hardware architecture is obtained according to the plurality of third performance results. The fourth performance result may be compared with the second performance result to determine which performance simulator is better.

[0014] In a possible design, the interval includes a preset number of instructions in the application, and the executing in parallel the plurality of checkpoints on a performance simulator includes: loading a checkpoint through the performance simulator; and executing the preset number of instructions following the checkpoint through the performance simulator.

[0015] According to the method for application checkpointing, the interval includes the preset number of instructions in the application, the checkpoint is loaded through the performance simulator, and the preset number of instructions following the checkpoint are executed through the performance simulator. The interval is calculated based on the number of instructions executed. Consequently, the first performance result, obtained by executing the preset number of instructions following the checkpoint through the performance simulator, is likely to be highly accurate. Furthermore, by setting a consistent preset number of instructions for each interval within the application, the overall performance simulation may be substantially accelerated.

[0016] In a possible design, the method further includes: reducing the plurality of checkpoints by a preset technology.

[0017] In some examples, the preset technology may be a clustering technology. Through the clustering analysis, intervals with similar characteristics are grouped (clustered) together, and the most representative interval is selected from each group (cluster) as a simulation point. This clustering manner may significantly reduce the number of checkpoints that need to be executed during simulation, thereby speeding up the simulation process.

[0018] In some examples, the preset technology may be a hotspot selection. A small number of representative checkpoints are selected to stand in for the simulation of all checkpoints, and these representative checkpoints are assigned corresponding weights during the simulation to accurately reflect the execution of the entire application. This approach may significantly reduce the time required for simulation while maintaining the accuracy of the results.

[0019] It is noted that other technologies that may reduce the plurality of checkpoints and speed up the simulation process may be applied to the present disclosure.

[0020] According to the method for application checkpointing, the plurality of checkpoints are reduced by a preset technology, significantly reducing the time required for simulation while maintaining the accuracy of the results.

[0021] In a possible design, the application includes a multi-thread application, or a single-thread application.

[0022] The multi-thread application is an application that may run multiple threads concurrently. A thread is the smallest unit of execution within the application, and the operating system of the computing device 100 may independently schedule and allocate a central processing unit (CPU) time slices to each thread. In the multi-thread application, each thread may perform different tasks or process different parts of the same task in parallel.

[0023] The single-thread application is an application that may run entirely within one thread, without any other threads executing in parallel.

[0024] According to the method for application checkpointing, the application includes the multi-thread application, or the single-thread application. Thus, this method for application checkpointing may have better compatibility and scalability.

[0025] In a possible design, the obtaining a plurality of checkpoints includes: stopping sequentially all active threads in the application except for a last active thread in a case where a global instruction counter of the application reaches a nth value, where n is a positive integer; and obtaining a nth checkpoint by dumping an execution state of the application through the last active thread.

[0026] According to the method for application checkpointing, when the plurality of checkpoints are obtained, all active threads in the application are stopped sequentially except for the last active thread in a case where the global instruction counter of the application reaches the nth value, where n is the positive integer; and the nth checkpoint is obtained by dumping the execution state of the application through the last active thread. Therefore, when the checkpoint is obtained, all active threads except the last active thread should be stopped, preventing any changes to the execution state of the application such as the states of memory and registers, but the last active thread is used to dump the execution state of the application, ensuring that the execution state of the application may be accurately dumped using the last active thread.

[0027] hi a possible design, the method further includes: awaking stopped threads through the last active thread. According to the method for application checkpointing, when the nth checkpoint is obtained by dumping the execution state of the application through the last active thread, the stopped threads are awaked through the last active thread, ensuring that all threads may be used for the following execution process.

[0028] In a possible design, the method further includes: updating the global instruction counter according to local instruction counters of all threads in a case where a difference between the nth value and the global instruction counter is greater or equal to a first synchronizing value; and incrementing the global instruction counter by one at an instruction execution in a case where the difference between the nth value and the global instruction counter is less than first synchronizing value until the global instruction counter reaches the nth value.

[0029] One instruction execution means a step of executing one instruction, and the instruction execution may ensure that the global instruction counter may not exceed the nth value. The first synchronizing value is preset or input by a user. Furthermore, there may be one updating or multiple updating, depending on the actual execution. The difference between the nth value and the global instruction counter is used to determine whether the global instruction counter approaches the nth value. That is, the difference between the nth value and the global instruction counter being greater or equal to the first synchronizing value means that the global instruction counter does not approach the nth value, and the difference between the nth value and the global instruction counter being less than the first synchronizing value means that the global instruction counter approaches the nth value.

[0030] According to the method for application checkpointing, the global instruction counter is updated according to local instruction counters of all threads in a case where the dilference between the nth value and the global instruction counter is greater or equal to the first synchronizing value, that is, when global instruction counter does not approach the nth value, the global instruction counter is not synchronized with every individual instruction execution but is synchronized according to the local instruction counters of all the threads. The global instruction counter is incremented by one at the instruction execution in a case where the difference between the nth value and the global instruction counter is less than first synchronizing value until the global instruction counter reaches the nth value, that is, when the global instruction counter approaches the nth value, the global instruction counter is synchronized with every individual instruction execution. Therefore, the method for application checkpointing may save the time when the global instruction counter is synchronized while ensuing the accuracy of synchronizing the global instruction counter.

[0031] In a possible design, the updating the global instruction counter according to local instruction counters of all the threads includes: determining that a local instruction counter of any thread reaches a second synchronizing value; and updating the global instruction counter according to the local instruction counters of all the threads.

[0032] According to the method for application checkpointing, it is determined that the local instruction counter of any thread reaches the second synchronizing value, and the global instruction counter is updated according to the local instruction counters of all the threads. For example, the global instruction counter is increased by the sum of local instruction counters of all the threads. This may ensure that the global instruction counter does not exceed the nth value.

[0033] In a possible design, the method further includes: resetting the local instruction counters of all the threads to 0. After the global instruction counter is updated according to the local instruction counters of all the threads, the local instruction counters of all the threads are set to 0 for the next updating of the global instruction counter.

[0034] In a possible design, the obtaining a nth checkpoint by dumping an execution state of the application includes: generating a startup code according to the execution state of the application; injecting the startup code into a memory image corresponding to the execution state; and obtaining the nth checkpoint by generating an executable file according to the memory image injected with the startup code.

[0035] According to the method for application checkpointing, the startup code is generated according to the execution state of the application; the startup code is injected into the memory image corresponding to the execution state; and the nth checkpoint is obtained by generating an executable file according to the memory image injected with the startup code. Therefore, through the startup code, the executable checkpoint is easy to load to any performance or other simulator, or to be executed natively on the current workstation.

[0036] In a possible design, the startup code includes a common startup code and a plurality of thread state restore codes for a plurality of threads in the application. According to the method for application checkpointing, the startup code includes the common startup code and the plurality of thread state restore codes for the plurality of threads in the application. The combination of the common startup code and the plurality of thread state restore codes for the plurality of threads in the application provides a robust framework for managing the multi-thread application, ensuring the threads start quickly, run smoothly, and recover gracefully from interruption.

[0037] In a possible design, the common startup code is generated according to a system call trace of the execution state. Thus, the system call trace of the execution state may ensure the same initial condition for threads.

[0038] In a possible design, a thread state restore code is generated according to a CPU state of the execution state for a corresponding thread. Thus, the CPU state may ensure that each thread is restored to the CPU state before interruptions.

[0039] hi a possible design, the injecting the startup code into a memory image corresponding to the execution state includes: inserting the thread state restore code into a hole that is located in the memory image corresponding to the execution state and has a target distance with a program counter of the corresponding thread.

[0040] According to the method for application checkpointing, the thread state restore code is inserted into the hole that is located in the memory image corresponding to the execution state and has the target distance with the PC of the correspondingPC17RU2024 / 000352 thread. Therefore, it may ensure that when the thread state restore code starts, it may jump to the PC of the corresponding thread accurately.

[0041] In a possible design, the method further includes: adding a heap pre-allocation into the startup code. When the executable checkpoint is loaded, the BRK position may differ from the original BRK position and the BRK position may not be moved to the original BRK position. Therefore, there is a need to add the heap pre-allocation into the startup code, to make the potential used space available to the application.

[0042] In a possible design, a checkpoint is loaded by: starting a parent thread in the plurality of threads; restoring system context through the parent thread according to the common startup code; starting one or more child threads in the plurality of threads through the parent thread; synchronizing the parent thread and the one or more child threads; and calling a thread state restore code corresponding to the patent thread through the parent thread and calling one or more thread state restore codes corresponding to the one or more child threads through the one or more child threads.

[0043] According to the method for application checkpointing, the parent thread in the plurality of threads is started first and the system context is restored through the parent thread according to the common startup code; one or more child threads in the plurality of threads are started through the parent thread; the parent thread and the one or more child threads are synchronized; and a thread state restore code corresponding to the patent thread is called through the parent thread and one or more thread state restore codes corresponding to the one or more child threads are called through the one or more child threads. The checkpoint is easy to load to any performance or other simulates-, or to be executed natively on the current workstation.

[0044] According to a second aspect, an apparatus for application checkpointing is provided. The apparatus includes units for performing the method or design in the first aspect. The apparatus may be configured as a computing device or a module (such as a chip or a circuit) in the computing device.

[0045] According to a third aspect, a computing device is provided. The computing device includes processing circuitry for performing the method or design in the first aspect.

[0046] According to a fourth aspect, a computing device is provided and includes a processor and a computer-readable storage medium coupled to the processor and storing instructions for execution by the processor. When the instructions are executed by the processor, the computing device is configured to perform the method or design in the first aspect.

[0047] According to a fifth aspect, a computer-readable storage medium is provided. The computer-readable storage medium carries a program code which, when executed by a computer device, causes the computer device to perform the method or design in the first aspect

[0048] According to a sixth aspect, a computer program product. The computer program product is for storing a program code for performing the method or design in the first aspect.

[0049] This disclosure encompasses various embodiments, including not only method embodiments, but also other embodiments such as apparatus embodiments and embodiments related to non-transitory computer readable storage media. Embodiments may incorporate, individually or in combinations, the features disclosed herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0050] For a better understanding of the present disclosure, as well as other aspects and further features thereof, reference is made to the following description which is to be used in conjunction with the accompanying drawings, where:

[0051] FIG. 1 illustrates a diagram of an example computing device that may be used to implement any of methods described herein, in accordance with at least some non-limiting embodiments of the present disclosure;

[0052] FIG. 2 illustrates a diagram of example points where threads in an application process are spawn or joined, in accordance with at least some non-limiting embodiments of the present disclosure;

[0053] FIG. 3 illustrates a flowchart diagram of a method for application checkpointing in accordance with at least some non-limiting embodiments of the present disclosure;

[0054] FIG. 4 illustrates a diagram of an example implementation of a method for application checkpointing in accordance with at least some non-limiting embodiments of the present disclosure;

[0055] FIG. 5 illustrates a diagram of a state dump point synchronization where a checkpoint is obtained in accordance with at least some non-limiting embodiments of the present disclosure;

[0056] FIG. 6 illustrates a diagram of instruction counting where a checkpoint is determined in accordance with at least some non-limiting embodiments of the present disclosure;

[0057] FIG. 7 illustrates a diagram of a virtual address space of a memory image in accordance with at least some nonlimiting embodiments of the present disclosure;

[0058] FIG. 8 illustrates a diagram of a work sequence of a startup code in accordance with at least some non-limiting embodiments of the present disclosure;

[0059] FIG. 9 illustrates a diagram of a process of building an executable and linkable format (ELF) checkpoint in accordance with at least some non-limiting embodiments of the present disclosure;

[0060] FIG. 10 illustrates a block diagram of an apparatus for application checkpointing in accordance with at least some non-limiting embodiments of the present disclosure.DETAILED DESCRIPTION

[0061] In the following description, reference is made to the accompanying drawings, which form part of the present disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and include structural or logical changes not depicted in the drawings.

[0062] The embodiments set forth herein represent information sufficient to practice the claimed subject matter and illustrate ways of practicing such subject matter. Upon reading the following description in light of the accompanying drawings, a person skilled in the art will understand the concepts of the claimed subject matter and will recognize applications of these concepts not particularly addressed herein. It is understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0063] The examples and conditional language recited herein are principally intended to aid the reader in understanding the principles of the present disclosure and not io limit its scope to such specifically recited examples and conditions. It will be appreciated that a person skilled in the art may devise various arrangements which, although not explicitly described or illustrated herein, nonetheless embody the principles of the present disclosure and are included within its spirit and scope.

[0064] Moreover, all statements herein reciting principles, aspects, and implementations of the present disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof, whether they are currently known or developed in the future. Thus, for example, it will be appreciated by a person skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the present disclosure. Similarly, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudo-code, and the like represent various processes which may be substantially represented in computer-readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly illustrated.

[0065] The functions of the various elements illustrated in the figures, including any functional block labeled as a "processor", may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. In some embodiments of the present disclosure, the processor may be a general-purpose processor, such as a central processing unit (CPU) or a processor dedicated to a specific purpose, such as a digital signal processor (DSP). Moreover, explicit use of the term a "processor" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and / or custom, may also be included.

[0066] Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process steps and / or textual description. Such modules may be executed by hardware that is expressly or implicitly illustrated. Moreover, it should be understood that module may include for example, but without being limitative, computer program logic, computer program instructions, software, stack, firmware, hardware circuitry or a combination thereof which provides the required capabilities.

[0067] With these fundamentals in place, a computing device that may be used to implement embodiments of the present disclosure will be first introduced.

[0068] FIG. 1 illustrates a diagram of an example computing device that may be used to implement any of methods described herein, in accordance with at least some non-limiting embodiments of the present disclosure.

[0069] In some embodiments, the computing device 100 may be implemented by any of a conventional personal computer, a computer dedicated to operating and / or monitoring systems related to a data center, a controller and / or an electronic device (such as, but not limited to, a mobile device, a tablet device, a server, a controller unit, a control device, a monitoring device etc.) and / or any combination thereof appropriate to the relevant task at hand.

[0070] As illustrated in FIG. 1, the computing device 100 includes various hardware components including one or more single or multi-core processors collectively represented by a processor 110, a solid-state drive 120, a random-access memory 130 and an input / output interface 150.

[0071] The computing device 100 may be an “off the shelf’ generic computer system. The computing device 100 may also be dedicated to the implementation of the present disclosure. In some embodiments, the computing device 100 may also be distributed amongst multiple systems. A person skilled in the art of the present disclosure may appreciate, multiple variations as to how the computing device 100 is implemented may be envisioned without departing from the scope of the present disclosure.

[0072] Communication between the various components of the computing device 100 may be enabled by one or more internal and / or external buses 160 (e.g. a peripheral component interconnect (PCI) bus, universal serial bus, institute of electrical and electronics engineers (IEEE) 1394 “Firewire” bus, small computer system interface (SCSI) bus, serial advanced technology attachment (Serial-ATA) bus, aeronautical radio incorporated (ARINC) bus, etc.), to which the various hardware components are electronically coupled.

[0073] The input / output interface 150 may allow enabling networking capabilities such as wire or wireless access. As an example, the input / output interface 150 may include a networking interface such as, but not limited to, a network port, a network socket, a network interface controller and the like. Multiple examples of how the networking interface may be implemented will become apparent to the person skilled in the art of the present disclosure. For example, but without being limitative, the networking interface may implement specific physical layer and data link layer standard such as Ethernet, Fibre Channel, Wi-Fi or Token Ring. The specific physical layer and the data link layer may provide a base for a full network protocol stack, allowing communication among small groups of computers on the same local area network (LAN) and large- scale network communications through routable protocols, such as Internet Protocol (IP).

[0074] In some embodiments, the solid-state drive 120 stores program instructions suitable for being loaded into the random-access memory 130 and executed by the processor 110 for operating data centers based on a generated machine learning pipeline. For example, the program instructions may be part of a library or an application.

[0075] In some embodiments, the computing device 100 may be implemented as part of a cloud computing device. Broadly, a cloud computing device is a type of computing that relies on a network of remote servers hosted on the Internet, for example, to store, manage, and process data, rather than a local server or personal computer. This type of computing may allow users to access data and applications from remote locations, and provide a scalable, flexible, and cost-effective solution for data storage and computing. Cloud computing devices can be divided into three main categories: Infrastructure as a Service (laaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In an laaS environment, users can rent virtual servers, storage, and other computing resources from a third-party provider, for example. In a PaaS environment, users have access to a platform for developing, running, and managing applications without having to manage the underlying infrastructure. In a SaaSenvironment, users can access pre-built software applications that are hosted by a third-party provider, for example. In summary, cloud computing devices may offer a range of benefits, including cost savings, scalability, increased agility, and the ability to quickly deploy and manage applications.

[0076] The present disclosure relates to hardware design technologies where when a hardware architecture of a hardware component is designed, the hardware architecture' characteristics such as performance need to be determined. The computing device 100 may be used to determine the hardware architecture' characteristics such as performance.

[0077] A hardware component, which may also be referred to as a computational component, may be a chip, a processor, a system on chip (SoC), an integrated circuit, or similar components. When the hardware architecture of the hardware component is designed, a new hardware architecture of the hardware component may be developed or a hardware architecture of the hardware component may be enhanced. When the hardware architecture of the hardware component is designed, it is possible to obtain several levels of models for the new or improved hardware architecture. These levels of models may execute real applications (e.g. applications for benchmarks or tests) to obtain characteristics of the new or improved hardware architecture. The benchmarks or tests may be obtained from some standard committees that are responsible for writing benchmarks or tests for different types of architecture. Execution speeds of these applications may vary across these levels of models. An execution speed of an application on a model is measured in instructions per second (IPS) and is dependent on the model's granularity — the more detailed the model, the slower the execution speed.

[0078] These levels of models may include two types of models, i.e. a functional model and a performance model. When developing the new hardware architecture or enhancing the hardware architecture, both the functional model and the performance model may be obtained for the hardware architecture. The functional model and the performance model may sometimes be referred to as a functional simulator and a performance simulator, respectively. The functional model is used to emulate the functionality of the hardware architecture visible to a user such as a developer or a programmer and the performance model is used to obtain performance of the hardware architecture, where the performance is one key characteristic for the hardware architecture.

[0079] It is understood that the functional model and the performance model may be implemented in the computing device 100. For example, the functional model and the performance model may be stored in the solid-state drive 120 and loaded into the random-access memory 130 and executed by the processor 110. Furthermore, the application may also be implemented in the computing device 100. For example, the application may be stored in the solid-state drive 120 and loaded into the randomaccess memory 130 and executed by the corresponding model while the corresponding model is executed by the processor 110.

[0080] The functional model may be an instruction set architecture (ISA) level functional model for the hardware architecture. This type of model has less granularity, no microarchitecture details, and checks for ISA compliance and correspondence to the hardware architecture. The functional model represents the hardware architecture from a software or program perspective and it is the fastest type of model. In case of the functional model, the execution speed depends on the implementation of the model. The slowdown in the execution speed may range from a couple of times in case of partial virtualization of hardware (e.g. CPU virtualization) or using binary translation, up to hundreds of times when simulating a complex system (e.g. GPU) or dealing with unoptimized components.

[0081] The performance model may be a cycle-accurate model that covers a microarchitecture level of the hardware architecture. This type of model simulates internal microarchitectures for the hardware architecture, e.g. buffers, caches, execution units, and includes all hardware architecture details. However, this type of model has a very slow execution speed in real time. The most detailed performance model is a register transfer level (RTL) model, which may operate at a speed of several instructions per second and be costly to modify, so that it may take years to generate performance data for some real applications.

[0082] When making changes to the RTL model, it is reasonable to expect that these changes may significantly improve performance. To ensure such an improvement, it is beneficial to use a performance model with less granularity but faster speed. These models may operate at speeds of approximately 100 kilo instructions per second (KIPS). Nonetheless, obtainingperformance data for some real applications using these models may still require a considerable amount of time, ranging from months to years.

[0083] For example, a performance model obtained for a real physical processor may operate real applications at a speed of 50 kilo instructions per second. In comparison, the real physical processor may operate real applications at a speed of 2.6 giga instructions per second (GIPS). Thus, the performance model is several thousands of times slower than the real physical processor. When the real physical processor has multiple (sometimes hundreds) cores working in parallel, the performance model is tens of thousands of times slower than the real physical processor. To achieve a real benchmark, it may take a significant amount of time. For example, the benchmark may be executed on the real physical processor, and the execution speed may be approximately 2.6 giga instructions per second, taking about 5 or 6 hours. The same benchmark may be executed on the performance simulator, it may take several thousands of times or tens of thousands of times longer, so that it is clear why obtaining performance data may take months or even years.

[0084] Therefore, there is a need of significantly accelerating the design process of the hardware architecture.

[0085] An approach of accelerating the design process of the hardware architecture may include slicing the application (e.g. application for benchmarks or tests) into several parts on a faster functional simulator and executing these parts in parallel on slower performance simulators. The ISA level functional simulator may operate at a speed close to the native execution speed of the hardware component with this architecture, for example, approximately giga instructions per second. Slicing the application into several parts on the functional simulator may also be referred to as application process slicing (APS), which may include obtaining the application’s checkpoints during executing the application on the functional simulator, where a checkpoint may include all needed information about an application execution context for the checkpoint to restore the application execution or the application process from the checkpoint. Slicing the application into several parts on the functional simulator may also be referred to as application checkpointing, which may further include dropping execution states of the application at several time points (each of which may be any time point) during executing the application on the functional simulator so that the several parts are obtained, where each dropped state may include all needed information for restoring the application process to continue the execution exactly from a corresponding point where the execution state of the application was dropped. For example, the dropped state may include a memory image, CPU state (register state), system call trace. The dropped state has the same meaning with the checkpoint. A part of the several parts may be referred to as a checkpoint interval or an interval between two adjacent checkpoints. Therefore, when executing these parts in parallel on slower performance simulators, the execution speed may be accelerated and thus the design process may be accelerated.

[0086] The above approach may be applied to single-thread applications (STAs) and some limited versions of multi-thread applications (MTAs). In a case where the above approach is applied to STAs, there may not be any issues to drop and restore the execution state of the application at any point during executing the application. In a case where the above approach is applied to MTAs, the above approach may not drop, at any point, the execution state of the application. There are two ways for dropping and restoring the execution state of the application for implementing the above approach for MTAs.

[0087] The first way is dropping and restoring the execution state of the application at points where threads in the application process are spawn or joined, as illustrated in FIG. 2. To achieve the maximum acceleration when implementing the above approach, it may need to split the application into equal parts with an equal number of instructions, because the parallel execution time is equal to the execution time of the longest interval. If a part is longer than other ones, the whole process waits the longer part. In a case where the above approach is applied to MTAs, the checkpoints where threads are spawn and joined may be used for dropping and restoring the execution state of the applications, so that the length of the interval in most cases differs significantly from interval to interval. Therefore, this first way is very limited in terms of potential acceleration.

[0088] The second way aims to use special libraries and modify the execution state of the application source code. For example, some code and libraries may be inserted into the execution state of the application source code to slicing the application. This second way may be limited due to three points: (1) it requires the presence of the execution state of the application source code, which is not always possible; (2) the number of instructions in each interval is still different, and (3) it may significantly affect the number of instructions in the original application due to the addition of extra code.

[0089] Therefore, at least some non-limiting embodiments of the present disclosure provide a method for application checkpointing. This method for application checkpointing may allow to make checkpoints of the application at precise application execution moments, ensuring that an interval between each pair of consecutive checkpoints is uniform. The uniform intervals may eliminate longer intervals and waiting times for longer intervals, and thus the performance model may be accelerated significantly. Consequently, this may lead to a substantial acceleration in the design process. Furthermore, this method for application checkpointing may be applicable to environments with concurrent execution such as multiprocessor systems with application process scheduling (e.g. the MTA) as well as to environments with single execution (e.g. the STA). Additionally, the checkpoints obtained in this method for application checkpointing may be executable, and the executable checkpoints are easy to load to any performance or other simulator, or to be executed natively on the current workstation such as one or more processors 110 in one or more computing devices 100 as described above. In addition, in this method for application checkpointing, due to the compatibility of executable checkpoints, when some execution environments need some formats on the checkpoints, there is no need for users to modify their own performance simulators and no need for further recompilation of the applications on the performance simulators.

[0090] The method for application checkpointing in accordance with at least some non-limiting embodiments of the present disclosure is described below with reference to FIG. 3. FIG. 3 illustrates a flowchart diagram of a method 300 for application checkpointing in accordance with at least some non-limiting embodiments of the present disclosure. The method 300 may be performed by one or more processors 110 in one or more the computing devices 100. That is, the method 300 maybe performed by a processor 110 in the computing devices 100, multiple processors 110 in the computing device 100, a processor 110 distributed over multiple computing devices 110, or multiple processors in multiple computing devices 100. For example, the one or more processors 110 include a multi-core processor, and the method 300 is performed by the multi-core processor. For another example, the one or more processors 110 include multiple processors, and each step of the method 300 is performed by one or more of the multiple processors. As illustrated in FIG. 3, the method 300 may include steps 310 and 320.

[0091] In step 310, an application for evaluating a hardware architecture is obtained.

[0092] According to certain non-limiting embodiments of the present disclosure, the method 300 commences at step 310 with one or more processors 110 being configured to obtain the application for evaluating the hardware architecture.

[0093] As mentioned above, the hardware architecture may be either a newly developed hardware architecture or an enhancement of an existing hardware architecture of a hardware component. The hardware component may take the form of a chip, a processor, a system on chip (SoC), an integrated circuit, or other similar components. The form of the hardware component with this architecture is not restricted in this context.

[0094] As mentioned above, benchmarks or tests for evaluating the hardware architecture may be sourced from standard committees that specialize in developing such benchmarks or tests for various architectural types. The application used for these evaluations (i.e. the applications for evaluating the hardware architecture) may be either acquired from these standard committees directly or self-developed. The manner of obtaining the application and the content of the application are not restricted in this context.

[0095] In some examples, the one or more processors 110 may be configured to obtain the application for evaluating the hardware architecture. Regardless of whether this application is acquired directly from standard committees or is selfdeveloped, it may be stored in the solid-state drive 120. The one or more processors 110 load the application for evaluating the hardware architecture into the random-access memory 130. Subsequently, the one or more processors 110 may retrieve the application for evaluating the hardware architecture from the random-access memory 130.

[0096] In step 320, a plurality of checkpoints of the application are obtained from a functional simulator on which the application is executed, where the plurality of checkpoints are executable and an interval between every two consecutive checkpoints is the same.

[0097] According to certain non-limiting embodiments of the present disclosure, the method 300 continues at step 320 with the one or more processors 110 being configured to obtain, from the functional simulator on which the application is executed, the plurality of checkpoints of the application.

[0098] As mentioned above, several levels of models for the hardware architecture may be obtained, including the functional model and the performance model. These models, once obtained, may be stored in the solid-state drive 120. The one or more processors 110 may loads these models into the random-access memory 130. The one or more processors 110 may retrieve these models from the random-access memory 130 for further processing.

[0099] In some examples, the one or more processors 110 may be configured to retrieve both the functional model and the application for evaluating the hardware architecture, and execute the application for evaluating the hardware architecture within the functional model, to generate the plurality of checkpoints of the application. That is, the application for evaluating the hardware architecture may be executed on the functional model. The one or more processors 110 may obtain these checkpoints either incrementally, one by one, as the one or more processors 110 execute the application for evaluating the hardware architecture within the functional model, or all at once, after the application for evaluating the hardware architecture has been fully executed within the functional model.

[0100] In some examples, the plurality of checkpoints are designed to be executable by various systems. These systems include the functional simulator itself, the performance simulator, the processor 110, or any other processing system.

[0101] In some examples, the interval between every two consecutive checkpoints is the same. However, there is a margin of error associated with these intervals, which is typically negligible and thus ignored in practice.

[0102] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the application for evaluating the hardware architecture is obtained, and the plurality of checkpoints of the application are obtained from the functional simulator on which the application is executed, where the plurality of checkpoints are executable and the interval between every two consecutive checkpoints is the same. The interval between every two consecutive checkpoints is the same, ensuring that the interval between each pair of consecutive checkpoints is uniform. The uniform intervals may eliminate longer intervals and waiting times for longer intervals, and thus the performance model of the hardware architecture may be accelerated significantly in a case where the plurality of checkpoints are executed by the performance model of the hardware architecture in parallel. Consequently, this may lead to a substantial acceleration in the design process for the hardware architecture. Additionally, the checkpoints obtained in this method for application checkpointing may be executable, and the executable checkpoints may be easy to load to any performance or other simulator, or to be executed natively on the current workstation. In addition, in this method for application checkpointing, due to the compatibility of executable checkpoints, when some execution environments need some formats on the checkpoints, there is no need for users to modify their own performance simulators and no need for further recompilation of the applications on the performance simulators.

[0103] Furthermore, according to the experiments, acceleration of performance models in hundreds of times maybe realized.

[0104] In at least some non-limiting embodiments of the present disclosure, as illustrated in FIG. 3, the method 300 further includes steps 330 and 340.

[0105] In step 330, a plurality of first performance results are obtained by executing in parallel the plurality of checkpoints on a performance simulator.

[0106] According to certain non-limiting embodiments of the present disclosure, the method 300 continues at step 330 with the one or more processors 110 being configured to obtain the plurality of first performance results by executing in parallel the plurality of checkpoints on the performance simulator.

[0107] In some examples, the one or more processors 110 may include a multi-core processor or multiple processors. Each core within the multi-core processor may execute the performance simulator. When the multiple processors are used, the multiple processors may constitute a computing cluster, with each computing unit (e.g. one core or one processor) within the cluster executing the performance simulator. The performance simulator in each core or each computing unit may handle an equal number of checkpoints.

[0108] The one or more processors 110 distribute an equal number of checkpoints to each core or each computing unit and, in turn, receive an equal number of first performance results.

[0109] Consequently, the execution history or the entire execution of the application may be divided into several parts separated by the plurality of checkpoints. These checkpoints are executed in parallel by the performance simulator on the computing grid formed by the computing cluster. In the case of a large benchmark application, there may be thousands of checkpoints. Each core or each computing unit may correspond to multiple checkpoints. It is noted that to ensure the simulation speed, the number of the checkpoints for each core or each computing unit may be as equal as possible. The simulation speedup is directly proportional to the computational power of the computing cluster.

[0110] In step 340, a second performance result of the hardware architecture is obtained according to the plurality of first performance results.

[0111] According to certain non-limiting embodiments of the present disclosure, the method 300 continues at step 340 with the one or more processors 110 being configured to obtain the second performance result of the hardware architecture according to the plurality of first performance results.

[0112] The plurality of first performance results may include evaluation results of various aspects of the hardware architecture, such as processing speed, power consumption, and thermal management. These individual first performance results may be analyzed and combined to generate the second performance result that offers a broader view of capabilities for the hardware architecture. By considering the aggregate data from the plurality of first performance results of the plurality of checkpoints, the second performance result may provide a more reliable and nuanced understanding of the hardware architecture's performance, which may be used for making informed design decisions and optimizations.

[0113] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the plurality of first performance results are obtained by executing in parallel the plurality of checkpoints on the performance simulator, and the second performance result of the hardware architecture is obtained according to the plurality of first performance results. The plurality of checkpoints are executed by the performance model of the hardware architecture in parallel and the performance model of the hardware architecture may be accelerated significantly. Consequently, this may lead to a substantial acceleration in the design process for the hardware architecture. Furthermore, the performance simulation speedup is directly proportional to the computational power of the computing cluster for executing in parallel the plurality of checkpoints on the performance simulator.

[0114] Furthermore, in a case where the performance simulator is changed or updated, the plurality of third performance results are obtained by executing in parallel the plurality of checkpoints on the changed or updated performance simulator, and the fourth performance result of the hardware architecture is obtained according to the plurality of third performance results. The fourth performance result may be compared with the second performance result to determine which performance simulator is better.

[0115] In at least some non-limiting embodiments of the present disclosure, the interval includes a preset number of instructions in the application, and the executing in parallel the plurality of checkpoints on a performance simulator, i.e. step 310 may include: loading a checkpoint through the performance simulator; and executing the preset number of instructions following the checkpoint through the corresponding simulator.

[0116] In some examples, the processor 110 may load the checkpoint through the performance simulator; and execute the preset number of instructions following the checkpoint through the performance simulator. This may allow for the evaluation of the hardware architecture's performance at specific points during execution.

[0117] It is noted that one or more checkpoints may be loaded sequentially through the performance simulator. The number of checkpoints loaded sequentially in this manner may depend on the computational power of the computing cluster, which determines the computing cluster's ability to execute the plurality of checkpoints in parallel in the performance simulator. A cluster with greater computational power may handle a larger number of checkpoints in parallel, which may significantly speed up the evaluation process. Furthermore, the number of checkpoints loaded sequentially in this manner may depend on the size of the application. This parallel execution capability is helpful for handling complex hardware architectures or when dealing with large-scale simulations, as it allows for a more comprehensive analysis in a shorter amount of time.

[0118] The preset number of the instructions may be set by the computing device 100 or a user.

[0119] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the interval includes the preset number of instructions in the application, the checkpoint is loaded through the performance simulator, and the preset number of instructions following the checkpoint are executed through the performance simulator. The interval is calculated based on the number of instructions executed. Consequently, the first performance result, obtained by executing the preset number of instructions following the checkpoint through the associated performance simulator, is likely to be highly accurate. Furthermore, by setting a consistent preset number of instructions for each interval within the application, the overall performance simulation may be substantially accelerated.

[0120] According to certain non-limiting embodiments of the present disclosure, the method 300 continues with the processor 110 being configured to reduce the plurality of checkpoints by a preset technology.

[0121] In some examples, the preset technology may be a clustering technology. Through the clustering analysis, intervals with similar characteristics are grouped (clustered) together, and the most representative interval is selected from each group (cluster) as a simulation point. This clustering manner may significantly reduce the number of checkpoints that need to be executed during simulation, thereby speeding up the simulation process.

[0122] In some examples, the preset technology may be a hotspot selection. A small number of representative checkpoints are selected to stand in for the simulation of all checkpoints, and these representative checkpoints are assigned corresponding weights during the simulation to accurately reflect the execution of the entire application. This approach may significantly reduce the time required for simulation while maintaining the accuracy of the results.

[0123] It is noted that other technologies that may reduce the plurality of checkpoints and speed up the simulation process may be applied to the present disclosure.

[0124] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the plurality of checkpoints are reduced by a preset technology, significantly reducing the time required for simulation while maintaining the accuracy of the results.

[0125] According to certain non-limiting embodiments of the present disclosure, the application includes a multi-thread application, or a single-thread application.

[0126] The multi-thread application is an application that may run multiple threads concurrently. A thread is the smallest unit of execution within the application, and the operating system of the computing device 100 may independently schedule and allocate CPU time slices to each thread. In the multi-thread application, each thread may perform different tasks or process different parts of the same task in parallel.

[0127] The single-thread application is an application that may run entirely within one thread, without any other threads executing in parallel.

[0128] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the application includes the multi-thread application, or the single-thread application. Thus, this method for application checkpointing may have better compatibility and scalability.

[0129] The method for application checkpointing according to at least some non-limiting embodiments of the present disclosure as illustrated in FIG. 3 may be illustrated more intuitively in FIG. 4. With reference to FIG. 4, the performance simulation acceleration approach is illustrated. The workload such as the application mentioned above may be executed in the faster functional simulator. During the workload execution on the fast functional simulator, the equal checkpointing intervals may be obtained. Thus, the workload may be divided into a plurality of workload parts (each workload part may correspond to one or more checkpointing intervals). Each of checkpoints at ends of checkpointing intervals may be stored into a storage device. The stored checkpoints may be allocated into the performance simulator respectively. The plurality of workload parts (each workload part may include one or more checkpoints and instructions between the first one of the one or more checkpoints and the last one of the one or more checkpoints) may be executed in parallel on the performance simulator. Furthermore, the number of the checkpoints may be reduced by the hotspot selection. The performance results obtained from the performance simulator may be performed with the performance summary calculation to obtain the final and entire performance result. It is noted that these processes in FIG. 4 may be implemented by the computing device 100, and for example, the Storage in FIG.4 may be the solid-state drive 120, and functional simulator, Performance simulator, Performance summary calculation, and SimPoint tool in FIG. 4 may be stored in the solid-state drive 120 and loaded from the solid-state drive 120 to the randomaccess memory 130 by the processor 110 and called by the processor 110 from the random-access memory 130 to perform the processes in FIG. 4.

[0130] The following introduces how to obtain the plurality of checkpoints.

[0131] According to certain non-limiting embodiments of the present disclosure, the plurality of checkpoints may be obtained by: stopping sequentially all active threads in the application except for a last active thread in a case where a global instruction counter of the application reaches a nth value, where n is a positive integer; and obtaining a nth checkpoint by dumping an execution state of the application through the last active thread.

[0132] During the application execution, a global instruction counter (or a total instruction counter) of the application is tracked. When the global instruction counter reaches a given value such as the nth value, a corresponding checkpoint may be obtained. For example, in a case where the total number of instructions in the application is 2 billion, when the global instruction counter reaches 999 million (first value), the first checkpoint is obtained; when the global instruction counter reaches 1999 million (second value), the second checkpoint is obtained; when the global instruction counter reaches 2999 million (third value), the third checkpoint is obtained; and so on. Different n corresponds to a different checkpoint.

[0133] When the global instruction counter reaches the given value, all active threads in the application except for a last active thread are stopped sequentially, and the memory image, CPU state (register state), system call trace, and other execution state of the application may be saved by the last thread as the checkpoint

[0134] When simulating the multi-threaded application on the functional simulator, it is important to note that emulated threads are not synchronized and their behavior is non-deterministic. Additionally, the functional simulator's instruction callbacks are executed before executing the specified instructions. Consequently, when dumping the memory image and CPU state (register state), it is expected that all threads should be stopped, preventing any changes to the states of memoiy and registers. This may ensure that the execution state of the application may be accurately dumped using the last active thread.

[0135] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, when the plurality of checkpoints are obtained, all active threads in the application are stopped sequentially except for the last active thread in a case where the global instruction counter of the application reaches the nth value, where n is the positive integer; and the nth checkpoint is obtained by dumping the execution state of the application through the last active thread. Therefore, when the checkpoint is obtained, all active threads except the last active thread should be stopped, preventing any changes to the execution state of the application such as the states of memory and registers, but the last active thread is used to dump the execution state of the application, ensuring that the execution state of the application may be accurately dumped using the last active thread.

[0136] According to certain non-limiting embodiments of the present disclosure, after obtaining the nth checkpoint by dumping the execution state of the application through the last active thread, the method 300 for application checkpointing may further includes: awaking stopped threads through the last active thread.

[0137] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, when the nth checkpoint is obtained by dumping the execution state of the application through the last active thread, the stopped threads are awaked through the last active thread, ensuring that all threads may be used for the following execution process.

[0138] The above process of obtaining the plurality of checkpoints and awaking stopped threads through the last active thread may be illustrated in FIG. 5.

[0139] In FIG. 5, a state dump point synchronization 500 starts at step 501. In step 501, there are three threads, such as Thread 1, Thread 2, and Thread 3.

[0140] The synchronization 500 continues at step 502. In step 502, it is determined whether a global instruction counter reaches a nth value. When it is determined that the global instruction counter does not reach the nth value, the synchronization 500 continues at step 508. In step 508, there is no change for the three threads such as Thread 1, Thread 2, and Thread 3.

[0141] When it is determined that the global instruction counter reaches the nth value, the synchronization 500 continues at step 503. In step 503, the number of active threads is decreased by one, and it is checked whether this decreased number is equal to 0.

[0142] When it is checked that the decreased number is not equal to 0, the synchronization 500 continues at step 504. In step 504, a current active thread is stopped. For example, if the number of the active threads is 2 and decreased by one to become 1, which is not equal to 0, the current active thread is stopped. Then, the synchronization 500 continues at step 503, the number of active threads is decreased by one again and becomes 0, the synchronization 500 continues at step 505. It is noted that when the number of active threads is decreased by one to become 0, there is only one active thread, that is, the last active thread.

[0143] In step 505, an execution state of the application is dumped through the last active thread.

[0144] The synchronization 500 continues at step 506. In step 506, sleeping threads (that is, the stopped threads) are awaked through the last active thread.

[0145] The synchronization 500 continues at step 507. In step 507, the number of active threads is increased by one.

[0146] The synchronization 500 continues at step 508. In step 508, there is no change for the three threads such as Thread1, Thread 2, and Thread 3.

[0147] The following introduces the instruction counting.

[0148] According to certain non-limiting embodiments of the present disclosure, the method 300 for application checkpointing may further include: updating the global instruction counter according to local instruction counters of all threads in a case where a difference between the nth value and the global instruction counter is greater or equal to a first synchronizing value; and incrementing the global instruction counter by one at an instruction execution in a case where the difference between the nth value and the global instruction counter is less than first synchronizing value until the global instruction counter reaches the nth value. One instruction execution means a step of executing one instruction, and the instruction execution may ensure that the global instruction counter may not exceed the nth value. The first synchronizing value is preset or input by a user. Furthermore, there may be one updating or multiple updating, depending on the actual execution. -The difference between the nth value and the global instruction counter is used to determine whether the global instruction counter approaches the nth value. That is, the difference between the nth value and the global instruction counter being greater or equal to the first synchronizing value means that the global instruction counter does not approach the nth value, and the difference between the nth value and the global instruction counter being less than the first synchronizing value means that the global instruction counter approaches the nth value.

[0149] Determining the global instruction counter at any time may be time-consuming. Thus, it is not necessary to pinpoint the exact number of instructions, or the global instruction counter, at any time. Instead, it is determined when the target number of instructions is nearly reached, that is, when the global instruction counter approaches the nth value. To achieve this, the global instruction counter does not need to be synchronized with every instruction execution, that is, the global instruction counter does not need to be synchronized after any instruction is executed. Instead, local instruction counters for all threads may be initiated independently, and the global instruction counter may be synchronized only when the local instruction counters meet a condition, such as when one local instruction counter reaches a predefined value, the global instruction counter may be synchronized according to local instruction counters for all threads. Once the global instruction counter is sufficiently close to the nth value, it switches to a mode where the global instruction counter is synchronized with every instruction execution to ensure accuracy.

[0150] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the global instruction counter is updated according to local instruction counters of all threads in a case where the difference between the nth value and the global instruction counter is greater or equal to the first synchronizing value, that is, when global instruction counter does not approach the nth value, the global instruction counter is not synchronized with every individual instruction execution but is synchronized according to the local instruction counters of all the threads. The global instruction counter is incremented by one at the instruction execution in a case where the difference between the nth value andthe global instruction counter is less than first synchronizing value until the global instruction counter reaches the wth value, that is, when the global instruction counter approaches the nth value, the global instruction counter is synchronized with every individual instruction execution. Therefore, the method for application checkpointing may save the time when the global instruction counter is synchronized while ensuing the accuracy of synchronizing the global instruction counter.

[0151] According to certain non-limiting embodiments of the present disclosure, the step of updating the global instruction counter according to local instruction counters of all the threads, includes: determining that a local instruction counter of any thread reaches a second synchronizing value; and updating the global instruction counter according to the local instruction counters of all the threads. The second synchronizing value is preset or input by a user.

[0152] Since threads are not synchronized and exhibit non-deterministic behavior, it is impractical if the local instruction counters of all the threads reach the same value. Therefore, it is practical if any local instruction counter reaches the preset value, the global instruction counter is synchronized.

[0153] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, it is determined that the local instruction counter of any thread reaches the second synchronizing value, and the global instruction counter is updated according to the local instruction counters of all the threads. For example, the global instruction counter is increased by the sum of local instruction counters of all the threads. This may ensure that the global instruction counter does not exceed the nth value.

[0154] According to certain non-limiting embodiments of the present disclosure, the method 300 further includes: resetting the local instruction counters of all the threads to 0. After the global instruction counter is updated according to the local instruction counters of all the threads, the local instruction counters of all the threads are set to 0 for the next updating of the global instruction counter.

[0155] The instruction counting described above may be visualized in FIG. 6. As illustrated in FIG. 6, once checkpoint (n- 1 ) has been obtained, the process for accurately counting the instructions needed to reach checkpoint n is depicted. The process of updating the global instruction counter involves two distinct phases: a fast phase and a slow closing phase. During the fast phase, the difference between the nth value and the global instruction counter is greater or equal to the first synchronizing value, and the global instruction counter is synchronized five times, where at each time, the global instruction counter is synchronized according to local instruction counters of all threads and local instruction counters of all threads are set to 0 for the next synchronization. After the fourth synchronization, which is denoted as 601, it is determined that the difference between the nth value and the global instruction counter is greater or equal to the first synchronizing value, the fifth synchronization is performed. After the fifth synchronization, it is determined that the difference between the nth value and the global instruction counter is less than first synchronizing value, and the slow closing phase starts. During the slow closing phase, the global instruction counter is incremented by one at every instruction execution, such as three instruction executions, to reach checkpoint n accurately. It is understood that using this instruction counting, the checkpointing may be performed at any point of the application. Furthermore, this instruction counting is used to accurately position the point, thus the implementation of stopping active threads is very accurate, and the difference among checkpointing intervals in terms of number of instructions is no more than number of threads.

[0156] According to certain non-limiting embodiments of the present disclosure, a nth checkpoint is obtained by dumping an execution state of the application, which may include: generating a startup code according to the execution state of the application; injecting the startup code into a memory image corresponding to the execution state; and obtaining the nth checkpoint by generating an executable file according to the memory image injected with the startup code.

[0157] To create the executable checkpoint, the special assembler-based startup code, i. e. the startup code mentioned above, is generated and inserted to the original memory image. This code restores the state of the application process, i. e. the execution state of the application, allowing the application to continue executing as it was at the time the checkpoint was made.

[0158] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the startup code is generated according to the execution state of the application; the startup code is injected into the memory image corresponding to the execution state; and the nth checkpoint is obtained by generating an executable fileaccording to the memory image injected with the startup code. Therefore, through the startup code, the executable checkpoint is easy to load to any performance or other simulator, or to be executed natively on the current workstation.

[0159] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the startup code includes a common startup code and a plurality of thread state restore codes for a plurality of threads in the application.

[0160] The common startup code is configured to restore the system context of the application process, such as open files, seek offsets for files, and restore break (BRK). The process of opening files and seeking offsets for files is to ensure that when the system context of the application process is restored, all the files previously opened by the application process are returned to their correct positions. Each file opened by the application process has a file offset, which specifies the starting point for the next read or write operation within the file. By restoring the system context, the application may ensure that each file is positioned at the point where the last operation was performed, allowing the application process to continue seamlessly from where it left off. The BRK is a system call, available in Linux or similar operating systems, which is used to control the size of the data segment, or heap, for the application process. During the restoration of the system context of the application process, it is often to revert the BRK to its pre-suspension or pre-dump state. This action allows the application to resume using the memory that had been allocated before the interruption, ensuring a seamless continuation of operations of the application.

[0161] The common startup code is further configured to start child threads which immediately start waiting on special futex (fast userspace mutex). The futex is a synchronization mechanism in Linux or similar operating systems.

[0162] The common startup code is further configured to wake all the threads, so that every thread branches to its individual so called thread state restore code which restores the CPU state for the corresponding thread.

[0163] The thread state restore code of the thread is configured to branch the thread to address from which execution may continue. At this moment, every CPU state may hold values identical to those at the moment of the original execution. The thread state restore code allows the thread to pick up from the precise moment of interruption, maintaining the integrity of the application.

[0164] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the startup code includes the common startup code and the plurality of thread state restore codes for the plurality of threads in the application. The combination of the common startup code and the plurality of thread state restore codes for the plurality of threads in the application provides a robust framework for managing the multi-thread application, ensuring the threads start quickly, run smoothly, and recover gracefully from interruptions.

[0165] In some examples, the execution state of the application may include a memory image, a CPU state (register state), or a system call trace.

[0166] In some examples, the common startup code is generated according to a system call trace of the execution state. Thus, the system call trace of the execution state may ensure the same initial condition for threads.

[0167] In some examples, a thread state restore code is generated according to a CPU state of the execution state for a corresponding thread. Thus, the CPU state may ensure that each thread is restored to the CPU state before interruptions.

[0168] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the startup code is injected into the memory image corresponding to the execution state by: inserting the thread state restore code into a hole that is located in the memory image corresponding to the execution state and has a target distance with a program counter (PC) of the corresponding thread.

[0169] When the thread state restore code starts, it may restore system registers states, restore vector registers states, and restore general purpose registers states, so that the CPU state is ready to continue the execution of the original application, and then it may jump to original PC (this address may not be written to registers because all registers contain value that original program needs, so it may use direct jump). That is, the indirect branch "br x..." to jump to the corresponding PC is not used, because the indirect branch is used only with writing address to register but the address may be clear after the branch. Therefore, the direct branch "b <offset>" is used. The direct branch is limited in length + / -128MB from the corresponding PC. Consequently, the thread state restore code may be placed as close as possible to its corresponding PC. Therefore, the hole thatis an unused region in the address space of the memory image corresponding to the execution state, may has the target distance (e.g. + / -128MB) with the PC of the corresponding thread.

[0170] For example, as illustrated in FIG. 7, boxes in dash-dotted lines are segments added as startup, i.e. the startup code, where Thread 1 start means the thread state restore code corresponding to Thread 1, and Thread 0 start means the thread state restore code corresponding to Thread 0. Furthermore, boxes in solid lines are original memory image. There are two thread state restore codes and the common startup code in FIG. 7. Thread 1 start is inserted into the hole near to the corresponding PC in the box denoted as ".text", and when Thread 1 starts, it may accurately jump to the corresponding PC; and Thread 0 start is inserted into the hole near to the corresponding PC in the box denoted as ".so mappings".

[0171] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the method 300 may further include: adding a heap pre-allocation into the startup code.

[0172] When the executable checkpoint is loaded, the BRK position may differ from the original BRK position and the BRK position may not be moved to the original BRK position. Therefore, there is a need to add the heap pre-allocation into the startup code, to make the potential used space available to the application.

[0173] For example, as illustrated in FIG. 7, the box denoted as "Heap pre-allocation" is added before the box denoted as "Heap", and the box denoted as "Heap" represents the original BRK position.

[0174] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, a checkpoint is loaded by: starting a parent thread in the plurality of threads; restoring system context through the parent thread according to the common startup code; starting one or more child threads in the plurality of threads through the parent thread; synchronizing the parent thread and the one or more child threads; and calling a thread state restore code corresponding to the patent thread through the parent thread and calling one or more thread state restore codes corresponding to the one or more child threads through the one or more child threads.

[0175] FIG. 8 illustrates a diagram of a work sequence of a startup code in accordance with at least some non-limiting embodiments of the present disclosure. The following may describe the process of loading the checkpoint with reference to FIG. 8, where the process of loading the checkpoint may be referred to as the work sequence of the startup code of the corresponding checkpoint. When entering the checkpoint (i.e. Checkpoint entry), the parent thread such as Thread 0 works. Thread 0 executes the common startup code to restore the system context, such as open files, seek offsets for files, and restore the BRK Furthermore, Thread 0 executes the common startup code to start one or more child threads, such as start Thread 1 and Thread 2. In addition, Thread 0 executes the common startup code to synchronize the parent thread and the one or more child threads; for example, Thread 0 enters Futex wake state, Thread 1 enters Futex wait state, and Thread 2 enters Futex wait state. Thread 0 calls the thread state restore code corresponding to Thread 0, Thread 1 calls the thread state restore code corresponding to Thread 1, and Thread 2 calls the thread state restore code corresponding to Thread 2. Therefore, loading the checkpoint is realized

[0176] Alternatively, Thread 2 may include HINT instruction for region of interest (ROI) start. Using the HINT instruction informs profiling hardware or application about ROI starting or ending.

[0177] According to the method for application checkpointing in the at least some non-limiting embodiments of the present disclosure, the parent thread in the plurality of threads is started first and the system context is restored through the parent thread according to the common startup code; one or more child threads in the plurality of threads are started through the parent thread; the parent thread and the one or more child threads are synchronized; and a thread state restore code corresponding to the patent thread is called through the parent thread and one or more thread state restore codes corresponding to the one or more child threads are called through the one or more child threads. The checkpoint is easy to load to any performance or other simulator, or to be executed natively on the current workstation.

[0178] The common startup code and the thread state restore codes may form the synthetic assembler-based startup code for each thread initialization and starting all threads by the earliest initialized thread; and the assembler-based startup code is easy to analyze.PCI7RU2024 / 000352

[0179] The checkpoint is executable and is saved as an executable and linkable format (ELF) fde. When the memory image of the application process, and the CPU state for each thread, as well as the system call trace of counter-synchronized instructions are obtained, the executable checkpoint is obtained. FIG. 9 illustrates a diagram of a process of building an ELF checkpoint in accordance with at least some non-limiting embodiments of the present disclosure.

[0180] Referring to FIG. 9, the memory image may be saved as a file of memdump. elf, the system call trace may be saved as a file of strace.txt, and the CPU state for each thread may be saved as a file of cpustate.txt. The input files, i. e. memdump.elf strace.txt, and cpustate.txt, may be read. For memdump.elf, all segments from the memory image may be read from memdump.elf to output a file of output, elf; for strace.txt, the system call trace may be parsed from strace.txt to output system, ctx; and for cpustate.txt, the CPU state may be parsed from cpustate.txt to output cpustate.ctx.

[0181] For each CPU state in CPU states, the corresponding thread state restore code may be generated. For each CPU state in CPU states, outputelf may be read to find the hole, and cpustate.ctx may be read to generate the thread state restore code, and the thread state restore code may be inserted into output.elf where outputelf is updated. It is noted that during processes in FIG. 9, outputelf is updated and its updated version is used for the next process.

[0182] After the thread state restore codes of the CPU states are generated, the common startup code is generated. The hole is found from outputelf, and system. ctx may be read to generate the common startup code, and the common startup code may be inserted into output.elf.

[0183] After the common startup code is generated, symbol tables are added to the startup code to update output.elf. Furthermore, the heap pre-allocation is added to the startup code to update outputelf. In addition, outputelf may be written to checkpoint, elf.

[0184] There is a microarchitecture warmup mechanism when the executable checkpoint is obtained. The microarchitecture warmup is a process of executing a preset number of instructions in order to bring the state closer to the state that it was at the time of checkpointing. For example, when making the performance simulation of the application execution interval from 100M to 200M instructions. Without the microarchitecture warmup, it may make the checkpoint on 100M executed instructions. This checkpoint may be loaded to the performance simulator and next 100M instructions collecting the performance information may be executed. When the same interval from 100M to 200M but with 50M warmup interval (50M instructions for example) is needed, it may make the checkpoint at 50M executed instructions. When this checkpoint is loaded to the performance simulator, 50M instructions may be executed first and the performance simulator with warm microarchitecture may be obtained. Then the performance counters (number of CPU clocks for example) of the performance simulator may be reset, and the performance simulator may execute another 1 OOM of instructions and more precise performance data are obtained, because in the beginning of this data collection microarchitecture was warm It is noted that the warmup interval may be adaptive according to the actual environments.

[0185] The above introduces the method embodiments of the present disclosure. In various embodiments of the present disclosure, without special instructions and logical conflicts, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0186] The following introduces apparatus embodiments or device embodiments of the present disclosure.

[0187] FIG. 10 illustrates a block diagram of an apparatus for application checkpointing in accordance with at least some non-limiting embodiments of the present disclosure. As illustrated in FIG. 10, the apparatus 1000 for application checkpointing may include: an obtaining module 1100 and a processing module 1200.

[0188] The apparatus 1000 may be applied to the computing device 100 to realize any of the above method embodiments. The apparatus 1000 may be configured as the computing device 100 or configured as corresponding hardware and / or software in the computing device 100. For example, the apparatus 1000 may be configured as the processor 110 or configured as corresponding hardware and / or software in the processor 110.

[0189] In some embodiments, the obtaining module 1100 is configured to obtain an application for evaluating a hardware architecture of a hardware component. The processing module 1200 is configured to obtain, from a functional simulator onwhich the application is executed, a plurality of checkpoints of the application, where the plurality of checkpoints are executable and an interval between every two consecutive checkpoints is the same

[0190] In some embodiments, the processing module 1200 is further configured to: obtain a plurality of first performance results by executing in parallel the plurality of checkpoints on a performance simulator; and obtain a second performance result of the hardware architecture according to the plurality of first performance results.

[0191] In some embodiments, the interval includes a preset number of instructions in the application and the processing module 1200 is further configured to execute in parallel the plurality of checkpoints on a performance simulator by: loading a checkpoint through the performance simulator; and executing the preset number of instructions following the checkpoint through the performance simulator.

[0192] In some embodiments, the processing module 1200 is further configured to reduce the plurality of checkpoints by a preset technology.

[0193] In some embodiments, the processing module 1200 is further configured to obtain a plurality of checkpoints by: stopping sequentially all active threads in the application except for a last active thread in a case where a global instruction counter of the application reaches a nth value, where n is a positive integer; and obtaining a nth checkpoint by dumping an execution state of the application through the last active thread.

[0194] In some embodiments, the processing module 1200 is further configured to awake stopped threads through the last active thread.

[0195] In some embodiments, the processing module 1200 is further configured to update the global instruction counter according to local instruction counters of all threads in a case where a difference between the nth value and the global instruction counter is greater or equal to a first synchronizing value; and increment the global instruction counter by one at an instruction execution in a case where the difference between the nth value and the global instruction counter is less than first synchronizing value until the global instruction counter reaches the nth value.

[0196] In some embodiments, the processing module 1200 is further configured to update the global instruction counter according to local instruction counters of all the threads by: determining that a local instruction counter of any thread reaches a second synchronizing value; and updating the global instruction counter according to the local instruction counters of all the threads.

[0197] In some embodiments, the processing module 1200 is further configured to reset the local instruction counters of all the threads to 0.

[0198] In some embodiments, the processing module 1200 is further configured to obtain a nth checkpoint by dumping an execution state of the application by: generating a startup code according to the execution state of the application; injecting the startup code into a memoiy image corresponding to the execution state; and obtaining the nth checkpoint by generating an executable file according to the memory image injected with the startup code.

[0199] In some embodiments, the startup code includes a common startup code and a plurality of thread state restore codes for a plurality of threads in the application.

[0200] In some embodiments, the common startup code is generated according to a system call trace of the execution state

[0201] In some embodiments, a thread state restore code is generated according to a CPU state of the execution state for a corresponding thread.

[0202] In some embodiments, the processing module 1200 is further configured to inject the startup code into a memory image corresponding to the execution state by: inserting the thread state restore code into a hole that is located in the memory image corresponding to the execution state and has a target distance with a program counter of the corresponding thread.

[0203] In some embodiments, the processing module 1200 is further configured to add a heap pre-allocation into the startup code.

[0204] In some embodiments, the processing module 1200 is further configured to load a checkpoint by: starting a parent thread in the plurality of threads; restoring system context through the parent thread according to the common startup code; starting one or more child threads in the plurality of threads through the parent thread; synchronizing the parent thread and theone or more child threads; and calling a thread state restore code corresponding to the patent thread through the parent thread and calling one or more thread state restore codes corresponding to the one or more child threads through the one or more child threads.

[0205] Some embodiments of the present disclosure a computing device including processing circuitry for executing any of the above methods. It should be understood that the device may execute the steps in the above method embodiments, which will not be repeated herein.

[0206] Some embodiments of the present disclosure further provide a computing device. The computing device may be referred to as the above computing device, where the processor 110 may realize any of the above method embodiments, which will not be repeated herein.

[0207] For instance, it is understood that a disclosure in connection with a described method may also hold true for a corresponding apparatus, device, or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding apparatus, device, or system may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the drawings. On the other hand, for example, if a specific apparatus, device, or system is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the drawings. Further, it is understood that the features of the various embodiments and / or aspects described herein may be combined with each other, unless specifically noted otherwise.

[0208] Some embodiments of the present disclosure provide a computer-readable storage medium (e.g. a non-transitory computer-readable storage medium). The computer-readable storage medium has stored thereon program instructions that, when run on a computing device, cause the computing device to execute one or more steps of the above methods.

[0209] For example, the computer-readable storage medium includes, but is not limited to, a magnetic storage device (e.g. a hard disk, a floppy disk or a magnetic tape), an optical disk (e.g. a compact disk (CD), or a DVD), a smart card, and a flash memory device (e.g. an erasable programmable read-only memory (EPROM), a card, a stick or a key driver). Various computer-readable storage media described in the embodiments of the present disclosure may represent one or more devices and / or other machine-readable storage media, which are used for storing information. The term "computer-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing and / or carrying instructions and / or data.

[0210] Some embodiments of the present disclosure further provide a computer program product. The computer program product includes program instructions carried on a non-transitory computer-readable storage medium. When executed on a computing device, the computer program instructions cause the computing device to perform one or more steps of the above methods.

[0211] Beneficial effects of the computer-readable storage medium and the computer program product are the same as the beneficial effects of the method for application checkpointing as described in some of the above embodiments, and details will not be repeated here.

[0212] In the present disclosure, the terms “a” or “an” are defined to mean “at least one”, that is, these terms do not exclude a plural number of items, unless stated otherwise.

[0213] In the present disclosure, unless stated otherwise, the terms “connected” and “coupled”, and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements. For example, connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

[0214] In the present disclosure, the expression “based on” is intended to mean “based at least partly on”, that is, this expression can mean “based solely on” or “based partially on”, and so should not be interpreted in a limited manner. Moreparticularly, the expression “based on” could also be understood as meaning “depending on”, “representative of’, “indicative of’, “associated with” or similar expressions.

[0215] In the present disclosure, the terms “system” and “network” may be used interchangeably in different embodiments of this disclosure. “At least one” means one or more, and “a plurality of’ means two or more. The term “and / or” describes an association relationship of associated objects, and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character “ / ” indicates an “or” relationship between associated objects. “At least one of the following items (pieces)” or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces). For example, “at least one of A, B, or C” includes: only A only B; only C; A and B; A and C; B and C; or A B, and C, and “at least one of B, and C” may also be understood as including: only A only B; only C; A and B; A and C; B and C; or A B, and C. In addition, unless otherwise specified, ordinal numbers such as “first” and “second” in embodiments of this disclosure are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0016] A person skilled in the art should understand that embodiments of this disclosure may be provided as a method, an apparatus (or system), a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium), or a computer program product. Therefore, this disclosure may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this disclosure may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

[0217] This disclosure is described with reference to the flowcharts and / or block diagrams of the method, the device (system), and the computer program product according to this disclosure. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or the block diagrams and a combination of a process and / or a block in the flowcharts and / or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device and enable a machine to execute the instructions. When executed by any computer or the processor of a programmable data processing device, the instructions cause the apparatus to implement specific functions as described in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams. The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0218] The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or on another programmable device provide steps for implementing specific functions as described in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0219] Modifications and improvements to the above-described implementations of the present disclosure may become apparent to a person skilled in the art. The foregoing description is intended to be exemplary rather than limiting. The scope of the present disclosure is therefore intended to be limited solely by the scope of the appended claims.

Claims

CLAIMS1. A method for application checkpointing, comprising: obtaining an application for evaluating a hardware architecture of a hardware component; and obtaining, from a functional simulator on which the application is executed, a plurality of checkpoints of the application, wherein the plurality of checkpoints are executable and an interval between every two consecutive checkpoints is the same.

2. The method of claim 1, further comprising: obtaining a plurality of first performance results by executing in parallel the plurality of checkpoints on a performance simulator; and obtaining a second performance result of the hardware architecture according to the plurality of first performance results.

3. The method of claim 2, wherein the interval comprises a preset number of instructions in the application, and the executing in parallel the plurality of checkpoints on a performance simulator comprises: loading a checkpoint through the performance simulator; and executing the preset number of instructions following the checkpoint through the performance simulator.

4. The method of any one of claims 1 to 3, further comprising: reducing the plurality of checkpoints by a preset technology.

5. The method of any one of claims 1 to 4, wherein the application comprises a multi-thread application.

6. The method of any one of claims 1 to 5, wherein the obtaining a plurality of checkpoints comprises: stopping sequentially all active threads in the application except for a last active thread in a case where a global instruction counter of the application reaches a nth value, where n is a positive integer; and obtaining a nth checkpoint by dumping an execution state of the application through the last active thread.

7. The method of claim 6, further comprising: awaking stopped threads through the last active thread.

8. The method of claim 6 or 7, further comprising: updating the global instruction counter according to local instruction counters of all threads in a case where a difference between the nth value and the global instruction counter is greater or equal to a first synchronizing value; and incrementing the global instruction counter by one at an instruction execution in a case where the difference between the nth value and the global instruction counter is less them first synchronizing value until the global instruction counter reaches the nth value.

9. The method of claim 8, wherein the updating the global instruction counter according to local instruction counters of all the threads comprises: determining that a local instruction counter of any thread reaches a second synchronizing value; and updating the global instruction counter according to the local instruction counters of all the threads.

10. The method of claim 9, further comprising: resetting the local instruction counters of all the threads to 0.

11. The method of any one of claims 6 to 10, wherein the obtaining a nth checkpoint by dumping an execution state of the application comprises: generating a startup code according to the execution state of the application; injecting the startup code into a memory image corresponding to the execution state; and obtaining the nth checkpoint by generating an executable file according to the memory image injected with the startup code.

12. The method of claim 11, wherein the startup code comprises a common startup code and a plurality of thread state restore codes for a plurality of threads in the application.

13. The method of claim 12, wherein the common startup code is generated according to a system call trace of the execution state.

14. The method of claim 12, wherein a thread state restore code is generated according to a central processing unit (CPU) state of the execution state for a corresponding thread.

15. The method of claim 14, wherein the injecting the startup code into a memory image corresponding to the execution state comprises: inserting the thread state restore code into a hole that is located in the memory image corresponding to the execution state and has a target distance with a program counter of the corresponding thread.

16. The method of any one of claims 11 to 15, further comprising: adding a heap pre-allocation into the startup code.

17. The method of any one of claims 12 to 16, wherein a checkpoint is loaded by: starting a parent thread in the plurality of threads; restoring system context through the parent thread according to the common startup code; starting one or more child threads in the plurality of threads through the parent thread; synchronizing the parent thread and the one or more child threads; and calling a thread state restore code corresponding to the patent thread through the parent thread and calling one or more thread state restore codes corresponding to the one or more child threads through the one or more child threads.

18. An apparatus comprising units for performing the method according to any one of claims 1 to 17.

19. A computing device comprising processing circuitry for performing the method according to any one of claims 1 to 17.

20. A computing device, comprising: a processor; and a computer-readable storage medium coupled to the processor and storing instructions for execution by the processor, wherein the instructions, when executed by the processor, configure the computing device to perform the method according to any one of claims 1 to 17.

21. A computer-readable medium canying a program code which, when executed by a computer device, causes the computer device to perform the method according to any one of claims 1 to 17.

22. A computer program product comprising a program code for performing the method according to any one of claims 1 to 17 when executed on a computer or a processor.

Images