Indexing and replaying time travel traces using difference graphs

Abstract

Tracking indexes and replays are performed using difference graphs. A subset of instructions of a trace beginning at a first instruction and ending at a second instruction is replayed to obtain a state of one or more named resources. Based on the replayed subset of instructions, a difference graph is generated that is structured such that an addition of the difference graph at the first instruction brings the one or more named resources to a second state, and a subtraction of the difference graph at the second instruction brings the one or more named resources to a first state. Upon reaching a target instruction, the difference graph is later added at the first instruction to restore the second state at the second instruction, or the difference graph is subtracted at the second instruction to restore the first state of the first instruction.

Description

Background Technology

[0001] Tracking down and correcting unintended software behavior is a core activity in software development. Unintended software behavior can include many things, such as execution crashes, runtime exceptions, slow performance, incorrect data results, and data corruption. Unintended software behavior can be triggered by a variety of factors, such as data input, user input, race conditions (e.g., when accessing shared resources), etc. Given the diversity of triggers, unintended software behavior can be rare and seemingly random, and extremely difficult to reproduce. Thus, identifying a given, unintended software behavior can be very time-consuming and difficult for developers. Once the unintended software behavior is identified, determining its (multiple) root causes can also be time-consuming and difficult.

[0002] Developers typically use a variety of methods to identify unwanted software behavior and then pinpoint multiple locations within the application's code that cause it. For example, a developer might test different parts of the application's code against different inputs (e.g., unit tests). As another example, a developer might infer the execution of the application's code in a debugger (e.g., during code execution, by setting breakpoints / watchpoints, by stepping through lines of code, etc.). As yet another example, a developer might observe code execution behavior in a profiler (e.g., timing, coverage). As yet another example, a developer might insert diagnostic code (e.g., tracing statements) into the application's code.

[0003] While conventional diagnostic tools (e.g., debuggers, profilers, etc.) are used for “real-time” forward execution of code, an emerging form of diagnostic tool enables “historical” debugging (also known as “time travel” or “reverse” debugging), in which the execution of at least a portion of the program’s (multiple) threads is recorded in one or more trace files (i.e., the recorded execution). Using some tracing techniques, the recorded execution can contain “bit-precise” historical trace data, which allows the (multiple) recorded portions of (multiple) traced threads to be virtually “replayed” (e.g., via emulation) down to the granularity of individual instructions (e.g., machine code instructions, intermediate language code instructions, etc.). Therefore, using “bit-precise” trace data, diagnostic tools allow developers to infer the previous execution of the subject code from the recorded previous execution, rather than the “real-time” forward execution of that code. For example, a historical debugger might provide a user experience that enables both forward and reverse breakpoints / watchpoints, allowing code to be stepped forward and backward, etc. On the other hand, a historical profiler might be able to derive code execution behavior (e.g., timing, coverage) from previously executed code.

[0004] To provide a user experience that enables reverse breakpoints / watchpoints, reverse stepping, etc., the debugger replays the trace backward from a point (such as a keyframe containing a snapshot of register and memory values) that precedes the "current" execution time presented in the debugger. For example, suppose the debugger presents the last instruction of a function as the current execution time. It is also assumed that the debugger has been instructed (e.g., via user input or another software component) to perform reverse execution up to the first instruction of the function (e.g., stepping back). To do this, the debugger might identify a keyframe in the trace preceding the first instruction of the function. The debugger can then reconstruct the initial program state (e.g., processor register values, memory values, etc.) from that keyframe and continue replaying all traced instructions between the keyframe and the first instruction of the function to reconstruct the program state at the first instruction. The debugger can then present the first instruction of the function as the current execution time, including any of the reconstructed program states presented. Thus, by replaying backward from the keyframe to reconstruct the state of the first instruction, the debugger has provided the illusion of execution backward from the second instruction to the first instruction.

[0005] Depending on the tracing implementation and other factors (e.g., available memory during tracing, acceptable overhead imposed by tracing, etc.), there can be a large number of tracing instructions between keyframes. For example, in some implementations, it may be normal for there to be between ten million and ten million tracing instructions between keyframes. In these implementations, even reversing a single instruction can result in the replay of millions of instructions. Summary of the Invention

[0006] At least some of the embodiments described herein improve the performance and efficiency of reverse debugging functionality by enhancing tracing with difference graphs and by leveraging these difference graphs to quickly restore program state to the target instruction. Unlike keyframes (which store a single-point-in-time snapshot of register and / or memory values ​​sufficient to initiate replay from a keyframe for the entire thread or process), difference graphs store transformation data that can be used to finely transition a subset of states between two execution points. The scope of this transformation data can be limited to changes to named resources (e.g., memory locations, registers, etc.) that occur between a first and a second execution point. Therefore, the size of a difference graph can be much smaller than that of a keyframe, and thus, difference graphs may occur more frequently than keyframes. Furthermore, unlike keyframes, difference graph transformation data can be bidirectional. Thus, for bidirectional transformation data, a difference graph can be “added” to a first state at a first instruction to transform the first state to a second state at a subsequent second instruction, and the same difference graph can be “subtracted” at a second instruction to transform the second state back to the first state.

[0007] In embodiments, the difference maps may be based on keyframes or other difference maps and are composable. For example, a first difference map (e.g., it may be based on a keyframe) may define the transformation from a first state at a first instruction (e.g., obtained from the keyframe) to a second state at a later second instruction. A second difference map (e.g., it may be based on the first difference map) may define the transformation from the second state at a second instruction to a third state at a later third instruction. In embodiments, the first and second difference maps may be added to the first state to recover the third state, or they may be subtracted from the third state to recover the first state.

[0008] Using difference maps, tools that leverage tracing (e.g., debuggers, analyzers, cloud services, etc.) can quickly jump to a target instruction in the trace without replaying all instructions between the keyframe and the target instruction. For example, the tool can jump to any target instruction by restoring the state from the previous keyframe and then adding any intermediate difference maps between the keyframe and the target instruction. If the target instruction falls on a difference map boundary, its state can be restored without replaying any instructions. If the target instruction is between difference map boundaries, the tool can restore the state to the difference map boundary before the target instruction and then only replay those instructions between that boundary and the target instruction. If the tool has already restored the state at a "current" instruction, and if that current instruction falls on a difference map boundary, the tool can jump back to the target previous instruction by subtracting one or more difference maps from the state at the current instruction to reach the target previous instruction (i.e., if it falls on a difference map boundary), or by reaching the difference map boundary before the target previous instruction (i.e., if it falls between difference map boundaries).

[0009] Some embodiments intelligently create difference maps with boundaries falling on locations of "interest" for debugging, such as applied binary interface (ABI) boundaries (e.g., function boundaries, kernel call boundaries, etc.) and thread transitions, to increase the likelihood of jumping to (or between) instructions falling on the difference map boundaries. In embodiments, difference maps can be created during trace recording, during subsequent trace indexing, and / or during trace replay. For example, one embodiment may create keyframes during trace recording, add difference maps to the trace at a first granularity during the indexing step, and create difference maps in memory at one or more second granularities during trace replay. In a particular example, an embodiment may create keyframes in approximately every three million instructions traced during tracing, insert difference maps in approximately every ten thousand instructions traced during indexing (possibly for both ABI boundaries and thread transitions), and create in-memory difference maps during approximately every hundred instructions replay. Embodiments may even create instruction-level difference maps during trace replay (e.g., for the one hundred most recently replayed instructions).

[0010] Some embodiments involve indexing a trace with a difference graph (e.g., during an indexing phase and / or during trace replay). These embodiments access a replayable trace that records previous executions of one or more threads of an entity, and identifies a subset of sequences of multiple instructions of a first thread within the one or more threads, the trace segment recording the previous execution of the sequence of instructions. The subset of instructions begins with a first instruction and ends with a second instruction. The subset of instructions is replayed to obtain the state of one or more named resources. The one or more named resources have a first state at the first instruction and a different second state at the second instruction. Based on the subset of replayed instructions, a difference graph is generated for the subset of instructions. The difference graph is structured such that adding to the difference graph at the first instruction brings one or more named resources to the second state, and subtracting from the difference graph at the second instruction brings one or more named resources to the first state. The difference graph is stored in conjunction with the trace (e.g., in memory and / or persistent storage).

[0011] Other embodiments composable with the first embodiment utilize difference graphs to replay traces. These embodiments access replayable traces that record previous executions of one or more threads of an entity, and identify specific instructions within trace segments that record previous executions of a sequence of multiple instructions from a first thread of one or more threads within the replayable trace. The multiple instructions include the specific instruction. A set of one or more difference graphs is identified for reconstructing a previous state of one or more named resources required to simulate the previous execution of the specific instruction. The set of one or more difference graphs is applied to reconstruct the previous state of the one or more named resources. After applying the set of one or more difference graphs, the previous execution of the specific instruction is simulated based on the reconstructed previous state of the one or more named resources.

[0012] This summary is provided to introduce the selection of concepts in a simplified form, which are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to help determine the scope of the claimed subject matter. Attached Figure Description

[0013] To describe how the above and other advantages and features of the invention can be obtained, the invention, which has been briefly described above, will be described in more detail with reference to specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only exemplary embodiments of the invention and are therefore not intended to be considered as limiting its scope. The invention will be described and explained with additional specificity and detail using the drawings, in which:

[0014] Figure 1AAn example computing environment is shown that facilitates enhanced tracking with difference graphs and / or leverages these difference graphs to quickly recover program state to reach target instructions;

[0015] Figure 1B Example debugging components for creating and / or utilizing difference graphs are shown;

[0016] Figure 2 An example computing environment is shown, in which Figure 1A The computer system is connected to one or more other computer systems through one or more networks;

[0017] Figure 3 An example of the recorded execution of an executable entity is shown;

[0018] Figure 4A This shows a representation of data that can be included in a recorded execution that has been enhanced with a difference graph;

[0019] Figure 4B A tree representation of the difference graph dependency is shown;

[0020] Figure 5 A flowchart is shown as an example method for indexing traces using a difference graph;

[0021] Figure 6 A flowchart of an example method for replaying tracing using difference maps is shown; and

[0022] Figure 7 A flowchart is shown for an example method for generating and utilizing difference maps during tracking replay. Detailed Implementation

[0023] At least some of the embodiments described herein improve the performance and efficiency of reverse debugging functionality by enhancing tracing with difference maps and by leveraging these difference maps to quickly restore program state to the target instruction. Unlike keyframes, which store a single-point-in-time snapshot of register and / or memory values ​​sufficient to initiate replay from the keyframe for the entire thread or process, difference maps store transformation data that can be used to finely transition a subset of states between two execution points. This transformation data may be limited to changes to named resources (e.g., memory locations, registers, etc.) that occur between a first and a second execution point. Therefore, the size of a difference map can be much smaller than that of a keyframe, and thus, difference maps may occur more frequently than keyframes. Furthermore, unlike keyframes, difference map transformation data can be bidirectional. Thus, for bidirectional transformation data, a difference map can be “added” to a first state at a first instruction to transform the first state to a second state at a subsequent second instruction, and the same difference map can be “subtracted” at a second instruction to transform the second state back to the first state.

[0024] In embodiments, the difference maps may be based on keyframes or other difference maps and are composable. For example, a first difference map (e.g., it may be based on a keyframe) may define the transformation from a first state at a first instruction (e.g., obtained from the keyframe) to a second state at a later second instruction. A second difference map (e.g., it may be based on the first difference map) may define the transformation from the second state at a second instruction to a third state at a later third instruction. In embodiments, the first and second difference maps may be added to the first state to recover the third state, or they may be subtracted from the third state to recover the first state.

[0025] Using difference maps, tools that leverage tracing (e.g., debuggers, analyzers, cloud services, etc.) can quickly jump to a target instruction in the tracing without replaying all instructions between the keyframe and the target instruction. For example, the tool can jump to any target instruction by restoring the state from the previous keyframe and then adding any intermediate difference maps between the keyframe and the target instruction. If the target instruction falls on a difference map boundary, its state can be restored without replaying any instructions. If the target instruction is between difference map boundaries, the tool can restore the state to the difference map boundary before the target instruction and then only replay those instructions between that boundary and the target instruction. If the tool has already restored the state at a certain "current" instruction, and if that current instruction falls on a difference map boundary, the tool can jump back to the previous target instruction by subtracting one or more difference maps from the state at the current instruction to reach either the previous target instruction (i.e., if it falls on a difference map boundary) or the difference map boundary before the previous target instruction (i.e., if it falls between difference map boundaries).

[0026] Some embodiments intelligently create difference maps with boundaries falling on locations of "interest" for debugging, such as applied binary interface (ABI) boundaries (e.g., function boundaries, kernel call boundaries, etc.) and thread transitions, to increase the likelihood of jumping to (or between) instructions falling on the difference map boundaries. In embodiments, difference maps can be created during trace recording, during subsequent trace indexing, and / or during trace replay. For example, one embodiment may create keyframes during trace recording, add difference maps to the trace at a first granularity during the indexing step, and create difference maps in memory at one or more second granularities during trace replay. In a particular example, an embodiment may create keyframes in approximately every 3 million instructions traced during tracing, insert difference maps in approximately every 10,000 instructions traced during indexing (possibly for both ABI boundaries and thread transitions), and create in-memory difference maps during approximately every 100 instructions replay. Embodiments may even create instruction-level difference maps during trace replay (e.g., for the 100 most recently replayed instructions).

[0027] The recorded executions used in the embodiments described herein can be generated by various historical debugging techniques. Typically, historical debugging techniques record or reconstruct the execution state of an entity at different times so that the entity's execution can be simulated at least partially from that execution state later. The fidelity of this virtual execution depends on the available recorded execution states.

[0028] For example, a class of historical debugging techniques (referred to herein as time travel debugging) continuously records a bit-precise trace of an entity's execution. This bit-precise trace can then be used later to faithfully replay previous executions of the entity, up to the fidelity of individual code instructions. For instance, a bit-precise trace might record enough information to reproduce the initial processor state at at least one point in a thread's previous execution (e.g., by recording a snapshot of processor registers), as well as data values ​​read by the thread's instructions after that point in time (e.g., memory reads). Based on the reads that provide the recorded information to the instructions, this bit-precise trace can then be used to replay the execution of the thread's code instructions (starting from the initial processor state).

[0029] Another class of history debugging techniques (referred to herein as branch tracing debugging) relies on reconstructing at least a portion of an entity's execution state by working backward from a dump or snapshot (e.g., a thread crash dump), including processor branch tracing (i.e., including a record of whether a branch was taken). These techniques begin with values ​​(e.g., memory and registers) in the dump or snapshot and, using branch tracing to at least partially determine the code execution flow, iteratively replay the entity's code instructions backward and forward to reconstruct intermediate data values ​​(e.g., registers and memory) used by the code until these values ​​reach a stable state. These techniques may be limited in how far back they can reconstruct data values ​​and how many data values ​​can be reconstructed. Nevertheless, the reconstructed historical execution data can be used for history debugging.

[0030] Another type of history debugging technique (referred to in this paper as replay and snapshot debugging) periodically records a complete snapshot of the entity's memory space and processor registers during entity execution. These techniques may also record such data along with the snapshots if the entity relies on data from sources outside its own memory or from non-deterministic sources. These techniques then use the data from the snapshots to replay the execution of the entity's code between snapshots.

[0031] Figure 1A An example computing environment 100a is illustrated, which facilitates enhanced tracing using difference maps and / or leverages these difference maps to quickly restore program state to reach target instructions. As shown, computing environment 100a may include or utilize a dedicated or general-purpose computer system 101, which includes computer hardware such as one or more processors 102, system memory 103, persistent storage device 104, and / or / multiple network devices 105, which are communicatively coupled using one or more communication buses 106.

[0032] Embodiments within the scope of this invention may include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available medium accessible by a general-purpose or special-purpose computer system. A computer-readable medium storing computer-executable instructions and / or data structures is a computer storage medium. A computer-readable medium carrying computer-executable instructions and / or data structures is a transmission medium. Therefore, by way of example and not limitation, embodiments of the invention may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0033] Computer storage media are physical storage media (e.g., system memory 103 and / or persistent storage device 104) that store computer-executable instructions and / or data structures. Physical storage media include computer hardware such as RAM, ROM, EEPROM, solid-state drives (“SSDs”), flash memory, phase-change memory (“PCM”), optical disc storage, magnetic disk storage, or other magnetic storage devices, or any other hardware storage device(s) that can be used to store program code in the form of computer-executable instructions or data structures and can be accessed and executed by a general-purpose or special-purpose computer system to implement the functions disclosed in this invention.

[0034] Transmission media may include networks and / or data links that can be used to carry program code in the form of computer-executable instructions or data structures and that can be accessed by general-purpose or special-purpose computer systems. A “network” is defined as one or more data links that enable the transmission of electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer system via a network or other communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computer system may consider that connection as a transmission medium. Combinations of the foregoing should also be included within the scope of computer-readable media.

[0035] Furthermore, upon arrival at various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the computer storage medium (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be cached in RAM within a network interface module (e.g., network device 105) and then ultimately transferred to the computer system RAM (e.g., system memory 103) and / or a weakly volatile computer storage medium (e.g., persistent storage device 104) at the computer system. Therefore, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize the transmission medium.

[0036] For example, computer-executable instructions include instructions and data that, when executed on one or more processors, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a particular function or a set of functions. For example, computer-executable instructions can be machine code instructions (e.g., binary files), intermediate format instructions (such as assembly language), or even source code.

[0037] Those skilled in the art will understand that this invention can be practiced in network computing environments with various types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. This invention can also be practiced in distributed system environments, where local and remote computer systems connected via network links (via hardwired data links, wireless data links, or a combination of hardwired and wireless data links) perform tasks. Thus, in a distributed system environment, the computer system can include multiple constituent computer systems. In a distributed system environment, program modules can reside in local and remote memory storage devices.

[0038] Those skilled in the art will also understand that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, but this is not required. When distributed, a cloud computing environment can be internationally distributed within an organization and / or have components owned across multiple organizations. In this description and the appended claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the many other advantages that can be obtained from such a model when properly deployed.

[0039] Cloud computing models can be composed of various features, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measurable services. Cloud computing models can also appear in various service models, such as Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). Cloud computing models can also be deployed using different deployment models, such as private clouds, community clouds, public clouds, and hybrid clouds.

[0040] Some embodiments (such as cloud computing environments) may include a system comprising one or more hosts, each capable of running one or more virtual machines. During operation, the virtual machines emulate an operational computing system to support an operating system, and perhaps one or more other applications. In some embodiments, each host includes a hypervisor that emulates the virtual resources of the virtual machines using physical resources abstracted from a view of the virtual machines. The hypervisor also provides appropriate isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides an illusion about the interface between the virtual machine and physical resources, even if the virtual machine only interfaces with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0041] like Figure 1A As shown, each processor 102 may include, among other things, one or more processing units 107 (e.g., processor cores) and one or more caches 108. Each processing unit 107 loads and executes machine code instructions via cache 108. During the execution of these machine code instructions at one or more execution units 107b, the instructions may use internal processor registers 107a as temporary storage locations and may be read from and written to various locations in system memory 103 via cache 108. Typically, cache 108 temporarily caches portions of system memory 103; for example, cache 108 may include a “code” portion of cache system memory 103 that stores application code and a “data” portion of cache system memory 103 that stores application runtime data. If processing unit 107 needs data (e.g., code or application runtime data) that is not already stored in cache 108, processing unit 107 may initiate a “cache miss,” resulting in the required data being retrieved from system memory 103—potentially “evicting” some other data from cache 108 back to system memory 103.

[0042] As shown, persistent storage device 104 can store computer-executable instructions and / or data structures representing executable software components; correspondingly, during the execution of the software at processor(s) 102, one or more portions of these computer-executable instructions and / or data structures can be loaded into system memory 103. For example, persistent storage device 104 is shown as potentially storing computer-executable instructions and / or data structures corresponding to debug component 109, tracker component 110, emulation component 111, and one or more applications 112. Persistent storage device 104 can also store data, such as one or more recorded executions 113 (e.g., generated using one or more of the aforementioned historical debugging techniques).

[0043] Typically, the debugging component 109 utilizes the simulation component 111 to simulate the execution of the code of an executable entity (such as, multiple, applications 112) based on execution state data obtained from one or more of the recorded executions 113. Therefore, Figure 1A This illustrates that debug component 109 and simulation component 111 are loaded into system memory 103 (i.e., debug component 109' and simulation component 111'), and applications(multiple)112 are being simulated within simulation component 111' (i.e., applications(multiple)112'). As will be combined... Figure 1BTo explain in more detail, debug component 109 can provide functionality for indexing the recorded executions 113 of application 112 using a difference graph and / or for replaying previous executions of application 112 from the recorded executions 113 while relying on the difference graph. Debug component 109 can correspond to any type of tool that uses the recorded executions 113 as part of analyzing previous executions of application 112. For example, debug component 109 can be a debugger, profiler, cloud service, etc.

[0044] Typically, tracer component 110 records or "tracks" the execution of one or more of the applications 112 to the recorded executions 113 (e.g., using one or more of the aforementioned history debugging techniques). Tracer component 110 can record the execution of the applications 112 regardless of whether the execution is a "real-time" execution directly on the processors 102, a "real-time" execution on the processors 102 via a managed runtime, and / or an execution emulated via emulation component 111. Therefore, Figure 1A It is also shown that the tracker component 110 is also loaded into the system memory 103 (i.e., the tracker component 110'). The arrow between the tracker component 110' and the recorded executions 113' indicates that the tracker component 110' can record tracking data into the recorded executions 113' (which can then be stored as persistent storage of the recorded executions 113' in persistent storage 104).

[0045] Computer system 101 may additionally or alternatively receive one or more of the recorded executions 113 from another computer system (e.g., using network devices 105). For example, Figure 2 Example computing environment 200 is shown, in which Figure 1A Computer system 101 is connected to one or more other computer systems 202 (i.e., computer systems 202a-202n) via one or more networks 201. As shown in Example 200, each computer system 202 includes a tracker component 110 and multiple applications 112. Thus, computer system 101 can receive one or more previously executed or recorded executions 113 from one or more of the multiple applications 112 at these multiple computer systems 202 via the multiple networks 201.

[0046] Note that while each of the debug component 109, tracker component 110, and / or emulation component 111 may be a separate component or application, they may alternatively be integrated into the same application (such as a debug suite) or into another software component—such as an operating system component, hypervisor, cloud infrastructure, etc. Thus, those skilled in the art will understand that the present invention can be practiced in a cloud computing environment, with computer system 101 as part of that environment. For example, while these components 109-111 may take the form of one or more software applications executing on a user's local computer, they may also take the form of services provided by a cloud computing environment.

[0047] As previously mentioned, debug component 109 can provide functionality for indexing the recorded execution 113 of application 112 using a difference graph and / or for replaying previous executions of application 112 from the recorded execution 113 while depending on the difference graph. To demonstrate how debug component 109 accomplishes the foregoing, Figure 1B It shows the provision Figure 1A Example 100b of additional details for the debugging component 109. Figure 1B The debug component 109 depicted herein includes various components (e.g., data access 114, indexing 115, emulation 116, output 117, etc.) representing various functions that the debug component 109 can implement according to the various embodiments described herein. It should be understood that the depicted components—including their identities, subcomponents, and arrangements—are presented only to aid in describing the various embodiments of the debug component 109 described herein, and these components are not limited to various embodiments of how software and / or hardware implement the debug component 109 or its specific functions as described herein.

[0048] As shown in the figure, the data access component 114 includes a trace access component 114a and a code access component 114b. The trace access component 114a accesses one or more of the recorded executions 113, such as the recorded executions 113 of a previous execution of application 112. Figure 3 An example of recorded execution 300 of an executable entity (e.g., application 112) that can be accessed by the trace access component 114a is shown, wherein the recorded execution 300 may have been generated using time travel debugging techniques.

[0049] exist Figure 3In the example, the recorded execution 300 includes multiple data streams 301 (i.e., data streams 301a-301n). In the embodiment, each data stream 301 records the execution of a different thread from the code of application 112. For example, data stream 301a may record the execution of the first thread of application 112, while data stream 301n records the nth thread of application 112. As shown, data stream 301a includes multiple data packets 302. Because the specific data recorded in each data packet 302 can be different, they are shown as having different sizes. Typically, when using time travel debugging techniques, data packets 302 can record input (e.g., register values, memory values, etc.) to one or more executable instructions executed as part of the first thread of application 112. As shown in the figure, data stream 301a may also include one or more keyframes 303 (e.g., keyframes 303a and 303b), each keyframe recording sufficient information, such as snapshots of register and / or memory values, to enable the simulation component 116 to replay the previous execution of the thread forward from the point of the keyframe.

[0050] In an embodiment, the recorded execution 113 may also include actual code executed as part of application 112. Therefore, in Figure 3 In this embodiment, each data packet 302 is shown as including a non-shaded data input portion 304 and a shaded code portion 305. In one embodiment, the code portion 305 of each data packet 302 (if present) may include executable instructions executed based on the corresponding data input. However, in other embodiments, the recorded execution 113 may omit the actual executed code, rather than relying on a separate access to the code of application 112 (e.g., from persistent storage device 104). In these other embodiments, each data packet may, for example, specify the address or offset of appropriate executable instructions(s) in the application binary image. Although not shown, the recorded execution 300 may also include a data stream 301 storing one or more outputs from the code execution.

[0051] If multiple data streams 301 exist, each recording the execution of a different thread, these data streams can include sorting events. Each sorting event records the occurrence of a thread-sequenceable event. For example, a sorting event can correspond to an interaction between threads, such as an access to memory shared by the threads. Thus, for example, if a first thread traced to a first data stream (e.g., 301a) writes to a synchronization variable, a first sorting event can be recorded in that data stream (e.g., 301a). Later, if a second thread traced to a second data stream (e.g., 301b) reads from that synchronization variable, a second sorting event can be recorded in that data stream (e.g., 301b). These sorting events can be inherently ordered. For example, each sorting event can be associated with a monotonically increasing value, where the monotonically increasing value defines the overall order among the sorting events. For example, a first sorting event recorded in the first data stream can be assigned the value "1", a second sorting event recorded in the second data stream can be assigned the value "2", and so on.

[0052] Return to Figure 1B The code access component 114b can obtain the code of application 112. If the recorded executions 114(s) obtained by the tracing access component 114a include tracing code (e.g., code portion 305), the code access component 114b can extract that code from the recorded executions 113. Alternatively, the code access component 114b can obtain the code of application 112 from persistent storage device 104 (e.g., from the application binary image).

[0053] To provide context for further description of index component 115 and simulation component 116, and as an introduction to the structure and use of the difference plot, Figure 4A A representation 400 of the data that can be included in the recorded execution 113, enhanced with a difference graph, is shown. Representation 400 includes a timeline representation of portions of two trace data streams 401a and 401b (collectively referred to as trace data stream 401). Each trace data stream 401 may correspond to a different previously executed thread of an application in application 112, with execution time proceeding from left to right.

[0054] Each of these tracing data streams 401 includes multiple keyframes 402a-402f (collectively referred to as keyframes 402). For example, keyframe 402a may correspond to the start of execution of the thread traced by data stream 401a (or, the start of thread tracing), while keyframes 402b and 402c are additional keyframes along the execution of the thread tracing. On the other hand, keyframe 402d may correspond to the start of execution of the thread traced by data stream 401b (or, the start of thread tracing), while keyframes 402e and 402f are additional keyframes along the execution of the thread tracing. These keyframes may have been created during tracing (e.g., by tracer 110) and / or during subsequent indexing (e.g., by indexing component 115). These keyframes 402 create segments of executable instructions that can be replayed independently of other segments (in the same thread and in different threads). For example, the graphical portion of the tracing data stream 401a includes two instruction segments—a first segment between keyframes 402a and 402b, and a second segment between keyframes 402b and 402c. The graphical portion of the tracing data stream 401b also includes two instruction segments—a first segment between keyframes 402d and 402e, and a second segment between keyframes 402e and 402f.

[0055] Figure 400 also shows multiple difference maps 403a-403o (collectively referred to as difference maps 403) along data stream 401. For example, data stream 401a is shown as including difference maps 403a-403j, while data stream 401b is shown as including difference maps 403k-403o. Each difference map 403 has an arrow pointing to the difference map 403 or keyframe 402 it depends on (i.e., the difference map 403 or keyframe 402 it uses as its baseline). To further visualize these dependencies, Figure 4B Tree representations 405a and 405b showing the difference graph dependencies along data stream 401a are shown, and tree representation 405c showing the difference graph dependencies along data stream 401b is also shown. In representations 405a-405b, elliptical nodes represent keyframe 402, and rectangular nodes represent difference graph 403.

[0056] As shown along data stream 401a and through tree representation 405a, difference map 403a depends on keyframe 402a and has difference map 403b that depends on it. As shown along data stream 401a and through tree representation 405b, difference map 403c depends on keyframe 402b and has difference maps 403d and 403f that depend on it; furthermore, difference map 403d has difference map 403e that depends on it, while difference map 403f has difference maps 403g and 403i that depend on it; difference map 403g has difference map 403h that depends on it, while difference map 403i has difference map 403j that depends on it. As shown along data stream 401b and through tree representation 405c, difference maps 403k and 403l depend on keyframe 402d; furthermore, difference map 403l has difference map 403m that depends on it, difference map 403m has difference map 403n that depends on it, and difference map 403n has difference map 403o that depends on it.

[0057] Although Figure 4A The diagram shows each difference map 403 appearing at a specific point in the corresponding data stream 401, but this is for illustrative purposes only. The difference map defines the transition between the program state at the start (first) boundary instruction and the program state at the subsequent end (second) boundary instruction (which may be the same instruction), and there may be a sequence of zero or more additional instructions between these boundary instructions. Figure 4A In this context, the row corresponding to difference diagram 403 can be considered as representing the end boundary instruction of each of these transformations. Thus, for example, difference diagram 403a represents the transformation between a first boundary instruction immediately following keyframe 402a and a second boundary instruction at the row representing difference diagram 403a. On the other hand, difference diagram 403b represents the transformation between a first boundary instruction at the row representing difference diagram 403a (or immediately following it) and a second boundary instruction at the row representing difference diagram 403b. Depending on the implementation, the second boundary instruction of difference diagram 403a may be the same as the first boundary instruction of difference diagram 403b, or they may be different adjacent instructions.

[0058] If the difference graph is stored within the recorded execution 113 (e.g., via index component 115), it can be stored within a trace data stream 301, which contains data packets 302 that record the execution of instructions of the threads to which the difference graph is applied (e.g., a trace data stream recording the execution of instructions of a first thread traced by data stream 401a, a trace data stream recording the execution of instructions of a second thread traced by data stream 401b, etc.), or the difference graph can be stored together in another trace data stream 301 (e.g., a data stream dedicated to index data). If the difference graph is stored within a trace data stream 301 that records the execution of instructions of the threads to which the difference graph is applied, it can be stored anywhere within that data stream 301. For example, the data structure representing difference map 403a can be stored within the tracking data stream 301 at the row representing difference map 403a (e.g., at or near the data packet 302 recording the execution of the second boundary instruction), and it can be stored at the beginning of the sequence of instructions covered by difference map 403a (e.g., at or near the data packet 302 recording the execution of the first boundary instruction). Alternatively or additionally, the data structure representing difference map 403a can be stored at the beginning or end (or near) the data stream 301 (e.g., as part of a portion of the data stream 301 dedicated to indexing data). Alternatively or additionally, the data structure representing difference map 403a can be stored at (or near) the keyframe on which it is based (directly or indirectly). Other storage locations are also possible. Therefore, Figure 4A The position of the row representing difference graph 403 should not be interpreted as indicating a specific location where the data structure representing the difference graph is stored.

[0059] Difference diagrams record reversible and composable transformations between the program state at a start boundary instruction and the program state at a subsequent end boundary instruction. In embodiments, these transformations apply to named resources, such as memory locations (e.g., named by address) and processor registers (e.g., named by register specification). These named resources may also include less common named resources, such as temporary memory available in some processors. Thus, for example, difference diagram 403a may record transformations of any named resource whose set of instructions changes from the start boundary instruction of difference diagram 403a to the end boundary instruction of difference diagram 403a, difference diagram 403b may record transformations of any named resource whose set of instructions changes from the start boundary instruction of difference diagram 403b to the end boundary instruction of difference diagram 403b, and so on. Depending on the implementation, these transformations may include transformations performed by one or both boundary instructions, or may exclude transformations performed by one or both boundary instructions.

[0060] The specific format of the transformation data can vary widely based on the implementation, as long as it has the property of being reversible within a given difference graph and can be combined with transformation data from other difference graphs. For example, suppose keyframe 402a records the value of register A for a specific named resource as 0xFFFFFFF0. Since difference graph 403a is based on this keyframe 402a, register A is in the state of 0xFFFFFFF0 at the start boundary instruction of difference graph 403a. Now, suppose that between the start and end boundary instructions of difference graph 403a, the value of register A changes to 0xFFFFFFFA. Further suppose that between the start and end boundary instructions of difference graph 403b, the value of register A changes to 0xFFFFFF0A. The transformation data for this named resource can contain anything that indicates or can be used to calculate the correct value of register A at either end of difference graphs 403a and 403b.

[0061] For example, each difference map could simply record the value of register A at its start and end instructions. However, space can be saved by recording the transformation in other ways. For example, difference map 403a could record a first reversible mathematical operation (e.g., "A:+0xA") to be applied to data stored or obtained from the baseline of difference map 403a (i.e., keyframe 402a), while difference map 403b could record a second reversible mathematical operation (e.g., "A:-0xF0") to be applied to data stored or obtained from the baseline of difference map 403b (i.e., difference map 403a). Thus, "adding" difference map 403a at the start instruction of difference map 403a could mean obtaining the value 0xFFFFFFF0 of register A from keyframe 402a, and then adding 0xA to obtain 0xFFFFFFFA. Furthermore, "adding" difference map 403b at the start instruction of difference map 403b (which could also correspond to the end instruction of difference map 403a) could mean subtracting 0xF0 from that calculated value to obtain 0xFFFFFF0A. Alternatively, the value of register A at the end instruction of difference diagram 403b can be known (e.g., due to previous application of difference diagrams 403a and 403b, or due to previous replay of that point in the trace). Now, “subtracting” difference diagram 403b at the end instruction of difference diagram 403b can represent reversing the “A:-0xF0” operation by adding 0xF0 to 0xFFFDFF0A to obtain 0xFFFFFFFA. Furthermore, “subtracting” difference diagram 403a at the end instruction of difference diagram 403a (which may also correspond to the start instruction of difference diagram 403b) can represent reversing the “A:+0xA” operation by subtracting 0xA from that calculated value to obtain 0xFFFFFFF0. While simple addition and subtraction operations have been provided as examples, it is understood that any type of reversible and composable transformation, such as bitwise operations, bit rotations, etc., can be used.

[0062] It is worth noting that the validity of some named resources (such as memory) can change between difference maps. For example, code between boundary instructions of a difference map may have requested the operating system to make certain addresses or address ranges valid or invalid. In this embodiment, the difference map captures these state changes.

[0063] The reversible and composable difference map allows the debug component 109 to quickly jump to any point in the trace, rapidly jumping forward from one instruction to a later instruction, and / or rapidly jumping backward from one instruction to a previous instruction, while reducing (or, in many cases, eliminating) the need for forward replay compared to using keyframes alone. To demonstrate these concepts, Figure 4A Three points of interest (POIs) are shown: POI 404a, represented by a square; POI 404b, represented by a circle; and POI 404c, represented by a triangle. As an example of using difference maps to jump to any position in the thread data stream 401a, if debug component 109 needs to jump to the instruction at POI 404a, the debug component can simply resume its state from keyframe 402b and then add difference maps 403c and 403f without replaying any instructions. Similarly, if debug component 109 needs to jump to the instruction at POI 404c, the debug component can also apply difference map 403i. If the debug component needs to jump to the instruction at POI 404b, the debug component can resume its state from keyframe 402b and then add difference maps 403c, 403f, and 403g (without replaying any instructions), then only replay the instructions between the end instruction and the main instruction in difference map 403g.

[0064] As an example of using a difference map to jump forward in data stream 401a, if debug component 109 has recovered the state at POI 404a (e.g., by applying a difference map and / or by replaying the trace at that point), debug component 109 can jump forward to POI 404b by adding difference map 403g and then replaying the instructions between the end instruction of difference map 403g and POI 404b. Alternatively, if debug component 109 has recovered the state at POI 404a, debug component 109 can jump forward to POI 404c by simply adding difference map 403i. As an example of using a difference map to jump backward in data stream 401a, if debug component 109 has recovered the state at POI 404c, debug component 109 can jump backward to POI 404a by simply subtracting difference map 403i. Alternatively, if the debug component 109 has restored the state at POI 404c, the debug component 109 can jump backward to POI 404b by subtracting the difference map 403i, by adding the difference map 403g, and by replaying the instructions between the end instruction of the difference map 403g and POI 404b.

[0065] In embodiments, different difference map types can be used to capture different ranges of changes to named resources. For example, embodiments may include “full” and “partial” difference maps. In embodiments, a “full” difference map may contain transformations from a base difference map or base keyframe to the named resource across all threads, while a “partial” difference map may contain only transformations made by a single thread since its base difference map or base keyframe. In embodiments, a full difference map may use a keyframe or another full difference map as its baseline, while a partial difference map may use a keyframe or any type of difference map as its baseline. Figure 4A and 4B Examples of complete and partial difference plots are provided—the complete difference plots (i.e., difference plots 403a-403c and 403f on data stream 401a and difference plots 403l and 403m on data stream 401b) are shown using solid lines, and the partial difference plots (i.e., difference plots 403d, 403e, 403g-403j on data stream 401a and difference plots 403k and 403n on data stream 401b) are shown using dashed lines.

[0066] The use of full and partial difference maps provides the ability to limit the number of transformations stored in the difference map when focusing the difference map on a local region of interest on a thread. For example, suppose POI 404a corresponds to the first instruction of the subject function on data stream 401a, and POI 404c corresponds to the last instruction of the subject function. Here, partial difference maps 403g-403i (which occur between / at these two POIs) can contain only the transformations performed by the subject function. Users are often interested in analyzing the behavior of a given function on a single thread, while at least temporarily ignoring what happens on concurrently executing threads. Partial difference maps 403g-403i allow users to quickly jump to instructions inside and at the end of the subject function without incurring the additional overhead of storing and tracking what happens on the thread tracked by data stream 401b during the time frame in which the subject function is executing. For example, if the subject function on data stream 401a runs at memory location X, and if the thread traced by data stream 401b runs at memory location Y during the same execution time frame, one or more of the partial difference graphs 403g-403i may store the transformation of memory location X, but ignore any transformation of memory location Y.

[0067] In addition to (or alternatively) having both full and partial difference maps, embodiments can apply a variety of other techniques to optimize the storage and use of difference maps. Some of these embodiments may omit certain types of information from some difference maps. For example, a function's ABI defines how the stack frame prologue and conclusion are set, which typically uses predictable patterns for reading and writing certain registers and / or memory locations. Because the identities of these named resources are predictable, and because the patterns of reading and writing to these named resources are predictable, embodiments may be able to reconstruct the state of these named resources without actually storing their transformations in the difference map. Furthermore, partial difference maps may omit any transformations to named resources modified by a function but having no real effect outside the function's context, such as volatile or non-volatile registers not used outside the function. Other embodiments may use different difference maps for different types of named resources (e.g., memory locations versus registers, volatile versus non-volatile registers, stack memory versus heap memory, code memory versus runtime memory, etc.).

[0068] It is worth noting that a difference map can be used to identify named resources (multiple) that have values ​​at the end of the difference map that differ from their values ​​at the beginning of the difference map. Therefore, a difference map can be used as a reverse lookup index to at least quickly identify a subset of code segments (e.g., segments to consider when searching for instructions that trigger breakpoints) that have written to a given named resource. However, obtaining information about named resources (multiple) with different values ​​at the end of the difference map compared to their values ​​at the beginning of the difference map may not capture all writes. For example, in instructions covered by the difference map, one instruction might add the value 1 to register A, and a subsequent instruction might subtract the value 1 from register A. Here, the value of the register does not change from the beginning and end instructions, so the difference map may not contain any transformations of register A. Some embodiments may add more information to the difference map to identify all named resources (multiple) that are written to (or even read by) all instructions covered by the difference map. With this additional information, the difference map can be used as a reverse lookup index to quickly identify all code segments (multiple) that are written to (or touched, if including, written to) a given named resource. It's worth noting that if the tracking lacks a difference graph or other reverse lookup index, locating which instruction(s) in a given segment touches a specific named resource is a linear search (e.g., replaying every instruction in the segment). Using a difference graph, this can be transformed into a binary search (e.g., traversing...). Figure 4B The tree representation in the diagram identifies (multiple) nodes that access a given named resource.

[0069] Return to Figure 1B Indexing component 115 can perform one or more types of indexing operations on the recorded execution 113. As shown in the inclusion of difference map generation component 115a, the indexing can include generating difference maps for one or more of the recorded executions 113. In embodiments, indexing component 115 can operate as a standalone task (e.g., an “offline” index delivery of the recorded execution 113, which augments the recorded execution 113 with index data including difference maps), or it can operate in conjunction with a replay of the recorded execution 113 as part of a debug session (e.g., an “on-the-spot” index of a trace portion replayed as part of a debug session). Regardless of the type of indexing being performed, the indexing component can utilize emulation component 116 to replay portions of the recorded execution 113 (e.g., generating runtime state data for indexing data). Because indexing component 115 can utilize emulation component 116, and because indexing can occur as part of a debug session, there is a double-ended arrow between indexing component 115 and emulation component 116 to indicate that any component can utilize another component as part of its operation.

[0070] To illustrate the use of offline and real-time indexing, Figure 4A In this process, difference maps 403a, 403b, 403c, 403f, 403i, and 403j on data stream 401a, and difference maps 402d-402f on data stream 401b, can be created during the “offline” indexing process and retained in the trace itself. Difference maps 403d, 403e, 403g, and 403h can also be created “on the fly” during a debug session focusing on segments on data stream 401a between keyframes 402b and 402c. These on-the-fly difference maps can be temporarily stored in system memory 103 and / or can be persistently saved to the trace. As will be understood, creating these on-the-fly difference maps during replay may result in minimal processing overhead (i.e., since these trace segments are replayed anyway), while allowing debug components 109 to move quickly within the code segment after the initial replay (which may be of particular interest). Although Figure 4A The instantaneous difference plots in the data stream are shown as partial difference plots, but they may also include (or only include) the full difference plot; however, as will be understood, creating a full difference plot on the fly may require replaying a portion of the data stream 401b.

[0071] Figure 1B The difference map generation component 115a is shown as including a boundary identification component 115a-1, a baseline identification component 115a-2, a transformation generation component 115a-3, and a difference map storage component 115a-4. Regardless of whether the indexing is performed offline or on-the-fly, the boundary identification component 115a-1 can identify the set of instructions for which a difference map will be created. This includes a set of instructions for identifying the boundaries of the difference map, including start boundary instructions and end boundary instructions, with zero or more instructions in between.

[0072] While boundary identification component 115a-1 can simply identify boundaries at regular intervals, in embodiments, boundary identification component 115a-1 can also identify boundaries at code locations that may be of particular interest during debugging. For example, these may include ABI boundaries (e.g., before and after function calls, before and after kernel calls, etc.), boundaries at thread transitions, boundaries at calls to specific functions or modules of interest, etc. In embodiments, the amount of processing used to identify boundary locations of "interest" may depend on the type of indexing being performed (e.g., offline vs. real-time), available processing resources during indexing, user preferences, etc.

[0073] When identifying boundaries, the boundary identification component 115a-1 can also balance the cost of including a specific set of difference maps for the boundary. For example, this balancing can include balancing the processing cost of applying the difference maps with the processing cost of the instructions for that set of instructions for simulating the boundary. The balancing can additionally or alternatively include considering the memory / storage cost of storing the difference maps for the set used for the boundary. The balancing also considers multiple sets of boundary / difference maps at once. For example, the average number of transformations in a given difference map may increase as the difference map frequency decreases. Furthermore, due to the storage overhead of each difference map, a single difference map covering 100 instructions may generally be smaller than 100 difference maps covering one instruction (i.e., where the start boundary instruction and the end boundary instruction are the same instruction, and the difference map captures the changes made to the naming resource by that single instruction), while 100 difference maps covering 100 instructions may generally be larger than a single difference map covering 10,000 instructions. Therefore, a trade-off can be made between the average difference map frequency and the average size of the data structure storing the transformations of these difference maps.

[0074] The baseline identification component 115a-2 can determine the baseline of a difference map for a given set, using what as its boundary. As previously mentioned, a difference map can use a keyframe or another difference map as its baseline. The choice of which keyframe or difference map to use can be based on considerations such as the number of named resources that have changed compared to the given baseline, the type of difference map being created (e.g., partial vs. complete), how the baseline and the current difference map are positioned relative to the location of interest, such as functions, etc. It is worth noting that it may be meaningful for the baseline identification component 115a-2 to select a baseline (keyframe or difference map) located in a tracking segment different from the tracking segment containing the boundary of the current set. For example, in Figure 4A In the tracking segment between keyframes 402e and 402f, difference map 403m is based on difference map 403l, which is located in the previous tracking segment between keyframes 402d and 402e (and is also based on keyframe 402d). As an example of why this might make sense, suppose function A calls another function B, keyframe 402d corresponds to the entry point of function A and the row corresponding to difference map 403m corresponds to the exit point of function A, and keyframe 402e falls somewhere in function B. It might make sense to create difference maps (or a set of difference maps) covering all calls to A (i.e., difference maps 403l and 403m) because one often jumps between calls to A in both directions; in this case, it makes sense to jump to keyframe 402e in function B when creating the difference map.

[0075] Based on the boundaries identified by boundary identification component 115a-1 and the baseline structure (keyframes or difference maps) identified by baseline identification component 115a-2, transform generation component 115a-3 determines which named resource(s) changes its value at the end boundary instruction rather than the baseline, and what transformation(s) will transform the baseline(s) to the changed values(s). Identifying these changes may include performing a replay from the start boundary instruction to the end boundary instruction using simulation component 116. As previously described, in embodiments, these transformations are reversible, such that transformations can be applied (i.e., added to) the state of the named resource at its start boundary instruction to obtain the appropriate state of the named resource at its end boundary instruction, and transformations can be applied (i.e., subtracted from) the state of the named resource at its end boundary instruction to obtain the appropriate state of the named resource at its start boundary instruction. Furthermore, in embodiments, these transformations are composable, allowing them to be added to and subtracted together from the difference map chain.

[0076] The difference graph storage component 115a-4 stores one or more data structures representing the transformations(s) created by the transformation generation component 115a-3 in appropriate locations, such as in system memory 103 (e.g., as part of runtime data associated with the replay tracking at the debugging component 109) and / or in persistent storage device 104 (e.g., as part of the index data of the recorded execution 113).

[0077] Simulation component 116 simulates code accessed by code access component 114b based on one or more of the recorded executions 113 accessed by trace access component 114a. For example, simulation component 116 may include or utilize Figure 1A Simulation component 111 is used to simulate the accessed code. Using simulation component 116, debugging component 109 can replay the accessed code while controlling the execution of that code using trace data values ​​from the recorded execution 113. Therefore, simulation component 116 is shown as including simulation control component 116a, which, as needed, can provide code of any simulation code instructions with trace data values ​​to guide the simulation of those instructions to reproduce their traced execution.

[0078] The simulation component is also shown as including a difference map component 116b, which may include a difference map identification component 116b-1 and a difference map application component 116b-2. Based on a request for a replay / simulation-specific instruction (or, a set of instructions), the difference map identification component 116b-1 identifies a set of one or more difference maps that can be applied to reach that instruction (or, the set of instructions). For example, this may include identifying one or more difference maps to be added to a keyframe, identifying one or more difference maps to be added to a known state (e.g., obtained through a set of previously applied difference maps and / or obtained through previous replays), or identifying one or more difference maps to be subtracted from a known state (e.g., obtained through a set of previously applied difference maps and / or obtained through previous replays). After the appropriate set of difference maps (including any dependent keyframes) has been identified, the difference map application component 116b-2 may apply (i.e., add or subtract) these difference maps to the existing or restored state as needed.

[0079] Output component 117 can output the results of any code simulation via simulation component 116. For example, output component 117 can visualize code simulation, presenting any runtime states generated by the application of difference maps and / or by code replay, etc. In embodiments, output component 117 can provide the output to another software component, such as a profiler or other components in a debugging suite.

[0080] As will be understood, the embodiments described herein can be used to generate index data (including difference maps) and to replay traces based on the difference maps. It should be understood that indexing and replay can be considered as two different and independent methods, and they can also be combined into a single method.

[0081] According to an embodiment used to generate index data including a difference map, Figure 5 A flowchart of an example method 500 for indexing traces using a difference graph is shown. Method 500 will now be described in the context of Figure 1-4B. Although the actions of method 500 are shown in a specific order for ease of description, it should be understood that some of these actions may be implemented in a different order and / or in parallel.

[0082] like Figure 5 As shown, method 500 includes an action 501 of accessing a replayable trace. In some embodiments, action 501 includes accessing a replayable trace of a previously executed thread of a recording entity. For example, data access component 114 may access one or more recorded executions 113 of application 112 (e.g., using trace access component 114a). Figure 3As shown, each of these (multiple) recorded executions 113 may include at least one data stream 301, which includes multiple data packets 302; each data packet 302 may include a data input portion 304 that records input of executable instructions executed as part of a previous execution of the application. Each trace data stream 301 may include data packets 302 that record previous executions of one or more threads of application 112. For example, trace data stream 301a may correspond to Figure 4A Data stream 401a, while tracking data stream 301n can correspond to data stream 401b.

[0083] The recorded executions 113 may include a prior “real-time” execution of application 112 directly or via a managed runtime at processors 102, or a prior emulated execution of application 112 using emulation component 116. Thus, in action 501, one or more recorded executions 113 may include at least one of a “real-time” execution of an executable entity or an emulated execution of an executable entity.

[0084] Method 500 further includes action 502 of identifying a subset of instructions within a trace segment. In some embodiments, action 502 includes identifying a subset of a sequence of instructions within a previously executed trace segment of a sequence of multiple instructions of a first thread in one or more threads, the subset of instructions beginning with a first instruction and ending with a second instruction. For example, boundary identification component 115a-1 may consider one or more segments of trace instruction execution to identify a subset of these instructions for which a corresponding difference map will be generated.

[0085] For example, refer to Figure 4A Boundary identification component 115a-1 may consider at least a portion of the instruction segment traced between keyframes 402b and 402c on data stream 401a, and identify a subset of instructions within that segment for which a difference map (e.g., difference map 403c) will be generated. This subset may begin with a first start boundary instruction and end with a second end boundary instruction. For example, boundary identification component 115a-1 may identify a subset of instructions that begin with a first instruction following keyframe 402b and end with a second instruction at the line corresponding to difference map 403c.

[0086] In an embodiment, boundary identification component 115a-1 can identify multiple subsets of instructions for which a difference map will be generated. Thus, for example, in method 500, the subset of instructions can include a first subset of instructions, and action 502 can also include identifying a second subset of the sequence of instructions within the trace segment, the second subset of instructions beginning with a third instruction and ending with a fourth instruction. For example, boundary identification component 115a-1 can identify a second subset of instructions beginning with a third instruction at a row corresponding to difference map 403c and ending with a second instruction at a row corresponding to difference map 403d. This can continue for any number of subsets. Depending on the implementation, the second instruction can also be a third instruction, and the second state can also be a third state.

[0087] In action 503, identifying a subset of the instructions(s) may include a baseline identification component 115a-2 identifying a baseline for each subset. As previously described, a difference map may use a keyframe or a difference map as its baseline. Therefore, in the example subset above, the baseline identification component 115a-2 may identify keyframe 402b as the baseline of the first subset and may identify difference map 403c (i.e., corresponding to the first subset) as the baseline of the second subset.

[0088] Method 500 further includes an action 503 of replaying a subset to obtain a program state. In some embodiments, action 503 includes replaying a subset of instructions identified in action 502 to obtain the state of one or more named resources, which have a first state at a first instruction and a different second state at a second instruction. For example, transformation generation component 115a-3 may utilize simulation component 116 to replay the execution of the first subset of instructions identified in action 502. Based on this replay, transformation generation component 115a-3 may identify the start state of one or more named resources at the start instruction of the subset and the end state of these named resources at the end instruction of the subset.

[0089] If multiple subsets are identified in action 502, action 503 may include replaying each of these subsets. For example, if a second subset is also identified, action 503 may also include replaying the second subset of the sequence of instructions to obtain the state of one or more named resources, which have a third state at the third instruction and a different fourth state at the fourth instruction. This can continue for any number of subsets.

[0090] It is worth noting that action 503 refers to the state "at" the instruction. Depending on the implementation, the term "at" can refer to the state before the instruction is executed or the state after the instruction is executed.

[0091] Method 500 further includes action 504 of generating a difference map. In some embodiments, action 504 includes generating a difference map for a subset of instructions based on a subset of replay instructions, the difference map being configured such that adding to the difference map at a first instruction brings one or more named resources to a second state, and subtracting from the difference map at a second instruction brings one or more named resources to a first state. For example, based on replay in action 503 of a subset identified in action 502, transform generation component 115a may identify one or more named resources whose values ​​change between a start state and an end state of the subset. For each changed named resource, transform generation components 115a-3 may generate a transform that can be used to transform the start state of the named resource to the end state of the named resource (i.e., for use when applying a transform as part of adding to the difference map) and / or transform the end state to the start state (i.e., for use when applying a transform as part of subtracting from the difference map). Therefore, the transformation generation component 115a can generate a difference map containing any transformation(s) required to transform any(s) values(s) of any(s) named resources(s), where the values ​​are modified in subsets between the start and end values ​​of the named resources.

[0092] If multiple subsets are identified in action 502 and replayed in action 503, action 504 may further include generating a difference map for each of these subsets. Thus, for example, the difference map just discussed could be a first difference map and action 504 could include generating a second difference map for a second subset (e.g., 403d). Therefore, action 504 may also include generating a second difference map for a second subset of instructions based on the second subset of the replay instructions, the second difference map being constructed such that adding to the difference map at a third instruction brings one or more named resources to a fourth state, and subtracting from the difference map at a fourth instruction brings one or more named resources to a third state. This can continue for any number of subsets and difference maps.

[0093] Method 500 also includes an action 505 of storing the difference maps. In some embodiments, action 505 includes storing the difference maps in conjunction with the tracking. For example, difference map storage components 115a-4 may store any and more of the generated difference maps to a location accessible during tracking replay. For example, difference map storage components 115a-4 may store one or more difference maps to persistent storage associated with the tracking (e.g., as part of the execution recorded in persistent storage 104), and / or to volatile memory associated with the replay of the tracking (e.g., system memory 103 used by debugging component 109).

[0094] As described above, a difference map can use a keyframe or another difference map as its baseline. For example, a first difference map 403c is shown using keyframe 402b as its baseline (although it can also use another difference map as its baseline). Thus, in method 500, the first difference map can use a keyframe as its baseline, and adding a difference map to a keyframe can bring one or more named resources to a second state, while subtracting a difference map at a second instruction can result in storing the state of one or more named resources in a keyframe. In this case, the state stored in the keyframe can include the first state. Although in this example, the baseline keyframe is associated with the tracking segment used in action 502 (i.e., the segment from keyframe 402b to keyframe 402c), alternatively, the baseline keyframe can be associated with a different tracking segment (e.g., the segment from keyframe 402a to keyframe 402b).

[0095] Furthermore, the second difference map 403d is shown using difference map 403c as its baseline. Therefore, in method 500, the second difference map can use the first difference map as its baseline, and subtraction of the second difference map at the fourth instruction can bring one or more named resources to a third state (which could also be a second state, depending on execution). In this case, addition of the first and second difference maps at the first instruction can bring one or more named resources to a fourth state, and subtraction of the first and second difference maps at the fourth instruction can bring one or more named resources to a first state (i.e., because the difference maps are composable). However, the second difference map can also use a keyframe as its baseline. Therefore, alternatively, the second difference map may have used a keyframe as its baseline, and subtraction of the second difference map at the fourth instruction can bring one or more named resources to a state stored in the keyframe.

[0096] Each generated difference map can be a complete or partial difference map. Therefore, if the first difference map is a complete difference map, the second state can include state changes made by a second thread (e.g., data flow 401b) after the first instruction. If the first difference map is a partial difference map, the second state can omit state changes made by a second thread (e.g., data flow 401b) after the first instruction. In other words, for a partial difference map, the second state can include only state changes made by the first thread (e.g., data flow 401a).

[0097] As will be understood, method 500 can be repeated any number of times on any number of threads and / or trace segments. Thus, method 500 can be used to create Figure 4A Each difference graph is shown.

[0098] According to an embodiment used for dependency difference map replay tracking, Figure 6A flowchart of an example method 600 for replaying tracing using difference graphs is shown. Method 600 will now be described in the context of Figures 1-5. In an embodiment, method 600 may be executed after method 500 to utilize any difference graph(s) created using method 500 (e.g., difference graphs 403a-403o). Thus, method 600 can be viewed as a standalone method or an extension of method 500, such that methods 500 and 600 are part of a single, larger method that combines indexing and replay. Although the actions of method 600 are shown in a specific order for ease of description, it should be understood that some of these actions may be implemented in a different order and / or in parallel.

[0099] like Figure 6 As shown, method 600 includes an action 601 of accessing a replayable trace. In some embodiments, action 601 includes accessing a previously executed replayable trace of one or more threads of a recording entity. For example, the operation of action 601 may be substantially similar to action 501 of method 500.

[0100] Method 600 also includes an action 602 of identifying a target instruction. In some embodiments, action 602 includes identifying a specific instruction within a previously executed trace segment of a sequence of multiple instructions in a first thread that is recorded in one or more threads, the multiple instructions including the specific instruction. For example, simulation component 116 may identify a specific instruction of interest in a trace accessed in action 601. For example, simulation component 116 may identify one of POIs 404.

[0101] Method 600 also includes action 603, which identifies a set of one or more difference maps for reaching a target instruction. In some embodiments, action 603 includes identifying a set of one or more difference maps for restoring a previous state of one or more named resources required to emulate a previous execution of a particular instruction. For example, difference map identification component 116b-1 may identify any of the difference maps(s) required to access PIO 404 identified in action 603. The identified particular difference map(s) may depend on the previously available previous state.

[0102] As an example, to jump to POI 404a, the difference map identification component 116b-1 can identify difference map 403c (which is based on keyframe 402b) and difference map 403f. To jump to POI 404b, the difference map identification component 116b-1 can identify difference maps 403c, 403f, and 403g. To jump to POI 404c, the difference map identification component 116b-1 can identify difference maps 403c, 403f, and 403i.

[0103] As another example, if simulation component 116 has already reconstructed the state for POI 404a, then difference map identification component 116b-1 can identify difference map 403g to jump forward to POI 404b, or identify difference map 403i to jump forward to PIO 404c.

[0104] As another example, if simulation component 116 has already reconstructed the state for POI 404c, then difference map identification component 116b-1 can identify difference map 403i to jump backward to POI 404a, or identify difference maps 403i and 403g to jump backward to PIO 404b.

[0105] Method 600 also includes an action 604 of applying the difference maps(s). In some embodiments, action 604 includes applying a set of one or more difference maps to restore a previous state of one or more named resources. For example, applying the difference maps may include adding and / or subtracting difference maps from a known / restored state. This may include adding one or more difference maps to a known / restored previous state of one or more named resources, or subtracting one or more difference maps from a known / restored previous state of one or more named resources. In embodiments, applying a set of one or more difference maps to restore a previous state of one or more named resources is done without emulating any instructions.

[0106] As an example, in action 604, applying a set of one or more difference maps to restore a previous state of one or more named resources may include adding a set of one or more difference maps to the state of one or more named resources obtained from a keyframe associated with a tracking segment or a keyframe within another tracking segment. For example, to jump to POI 404a, difference map application component 116b-2 can restore the state from keyframe 402b and then add difference maps 403c and 403f. To jump to POI 404b, difference map application component 116b-2 can restore the state from keyframe 402b and then add difference maps 403c, 403f, and 403g. To jump to POI 404c, difference map application component 116b-2 can restore the state from keyframe 402b and then add difference maps 403c, 403f, and 403i.

[0107] As another example, in action 604, applying a set of one or more difference maps to restore a previous state of one or more named resources may include adding a set of one or more difference maps to the state of one or more named resources such as: a state obtained from another difference map that restores the state to an instruction prior to a specific instruction in a sequence of instructions or an instruction prior to a specific instruction in a sequence of instructions. For example, to jump forward from POI 404a to POI 404b, difference map application component 116b-2 may add difference map 403g, and to jump forward from POI 404a to POI 404c, difference map application component 116b-2 may add difference map 403i.

[0108] As yet another example, in action 604, applying a set of one or more difference maps to restore a previous state of one or more named resources may include subtracting the set of one or more difference maps from the state of one or more named resources at the state following a specific instruction in a sequence of instructions. For example, to jump backward from POI 404c to POI 404a, difference map application component 116b-2 may subtract difference map 403i, and to jump backward from POI 404c to POI 404b, difference map application component 116b-2 may subtract difference map 403i and then add difference map 403g.

[0109] Method 600 also includes action 605 of replaying a target instruction based on the applied difference maps(multiple) maps. In some embodiments, action 605 includes simulating a previous execution of a particular instruction based on a restored previous state of one or more named resources after applying a set of one or more difference maps. For example, by adding and / or subtracting difference maps in action 604, simulation component 116 can initiate replay from points reached through the addition / subtraction of difference maps, and uses simulation guidance component 116a to control instruction execution based on the trace.

[0110] As an example, to replay the instruction at POI 404a, after the difference map component 116b recovers its state from keyframe 402b and adds difference maps 403c and 403f, the simulation component 116 can initiate a replay at POI 404. To replay the instruction at POI 404b, after the difference map component 116b recovers its state from keyframe 402b and adds difference maps 403c, 403f, and 403g, the simulation component 116 can initiate a replay at or after the end boundary instruction of difference map 403g. To replay the instruction at POI 404c, after the difference map component 116b recovers its state from keyframe 402b and adds difference maps 403c, 403f, and 403i, the simulation component 116 can initiate a replay at POI 404c.

[0111] As another example, to replay instructions at POI 404b after a forward jump from POI 404a, simulation component 116 can initiate replay at or after the end boundary instruction of difference map 403g after adding difference map component 116b. To replay instructions at POI 404c after a forward jump from POI 404a, simulation component 116 can initiate replay at POI 404c after adding difference map 403i in difference map component 116b.

[0112] As another example, to replay instructions at POI 404a after a backward jump from POI 404c, simulation component 116 can initiate replay at POI 404a after subtracting difference map 403i from difference map component 116b. To replay instructions at POI 404b after a backward jump from POI 404c, simulation component 116 can initiate replay at or after the end boundary instruction of difference map 403g after subtracting difference map 403i from difference map component 116b and adding difference map 403g.

[0113] As will be understood, the difference maps(s) used in method 600 may be obtained from the trace itself (e.g., inserted via an offline indexing process) and / or from previously replayed trace segments (e.g., generated on the fly).

[0114] As described above, the difference map can be used as a reverse lookup data structure to determine which named resources are modified at the end boundary instruction compared to the start boundary instruction. If the difference map is enhanced with memory locations written by intermediate instructions, it can further cover named resources touched by intermediate instructions but having the same value at both the start and end boundary instructions. Either way, method 600 may include identifying one or more named resources modified by instructions covered by one or more difference maps from a set of one or more difference maps. Furthermore, the difference map can even be enhanced with data about which named resources are read by instructions covered by the difference map. In this case, method 600 may include identifying one or more named resources touched by instructions covered by one or more difference maps from a set of one or more difference maps.

[0115] As mentioned above, methods 500 and 600 can be viewed as part of a single, larger method that combines indexing and replay. To illustrate this, Figure 7 A flowchart of an example method 700 for generating and utilizing difference maps during tracking replay is shown. Method 700 will now be described in the context of Figures 1-6. Although the actions of method 700 are shown in a specific order for ease of description, it should be understood that some of these actions may be implemented in a different order and / or in parallel.

[0116] like Figure 7 As shown, method 700 includes an action 701 of accessing replayable traces. In some embodiments, action 701 includes accessing previously executed replayable traces of a recording entity. For example, action 701 may typically correspond to... Figure 5 Action 501.

[0117] Method 700 further includes action 702 of identifying a subset of instructions within a trace segment. In some embodiments, action 702 includes identifying a subset of the sequence of instructions within a previously executed trace segment of a sequence of multiple instructions of a recorded entity, the subset of instructions beginning with a first instruction and ending with a second instruction. For example, action 702 may typically correspond to... Figure 5 Action 502.

[0118] Method 700 further includes an action 703 of replaying a subset of instructions to obtain a program state. In some embodiments, action 703 includes replaying a subset of instructions to obtain the state of one or more named resources, which have a first state at a first instruction and a different second state at a second instruction. For example, action 703 may typically correspond to Figure 5 Action 503.

[0119] Method 700 further includes action 704 of generating a difference map. In some embodiments, action 704 includes generating a difference map for a subset of instructions based on a subset of replay instructions, the difference map being configured such that adding to the difference map at a first instruction brings one or more named resources to a second state, and subtracting from the difference map at a second instruction brings one or more named resources to the first state. For example, action 704 may typically correspond to Figure 5 Action 504.

[0120] Method 700 also includes action 705 of identifying target instructions. In some embodiments, action 705 includes identifying specific instructions to be replayed within a subset of instructions in the replayable trace after the difference map is generated. For example, action 705 may typically correspond to... Figure 6 Action 602.

[0121] Method 700 further includes action 706 identifying the difference map(s) for reaching a target instruction. In some embodiments, action 706 includes identifying the generated difference map for reaching a specific instruction. For example, action 706 may typically correspond to... Figure 6 Action 603.

[0122] Method 700 also includes action 707 of applying a difference map(s). In some embodiments, action 707 includes applying a difference map at a second instruction to restore a first state of one or more named resources. For example, action 707 may typically correspond to... Figure 6Action 604.

[0123] Method 700 also includes action 708 of replaying a target instruction based on the applied difference map(s). In some embodiments, action 708 includes replaying a subset of instructions after applying the difference map at the second instruction, including replaying a specific instruction based on a restored first state of one or more named resources. For example, action 708 may typically correspond to Figure 6 Action 605.

[0124] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above or the order of such actions. Rather, the described features and actions are disclosed as exemplary forms for implementing the claims.

[0125] Embodiments of the present invention may include or utilize dedicated or general-purpose computer systems comprising computer hardware, such as one or more processors and system memory, as discussed in more detail below. Embodiments within the scope of the invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media accessible by a general-purpose or dedicated computer system. A computer-readable medium storing computer-executable instructions and / or data structures is a computer storage medium. A computer-readable medium carrying computer-executable instructions and / or data structures is a transmission medium. Thus, by way of example and not limitation, embodiments of the present invention may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0126] Computer storage media are physical storage media that store computer-executable instructions and / or data structures. Physical storage media include computer hardware such as RAM, ROM, EEPROM, solid-state drives (“SSDs”), flash memory, phase-change memory (“PCM”), optical disc storage, magnetic disk storage, or other magnetic storage devices, or any other hardware storage devices(s) that can be used to store program code in the form of computer-executable instructions or data structures and can be accessed and executed by a general-purpose or special-purpose computer system to implement the functions disclosed in this invention.

[0127] Transmission media may include networks and / or data links that can be used to carry program code in the form of computer-executable instructions or data structures and that can be accessed by general-purpose or special-purpose computer systems. A “network” is defined as one or more data links that enable the transmission of electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer system via a network or other communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computer system may consider that connection as a transmission medium. Combinations of the foregoing should also be included within the scope of computer-readable media.

[0128] Furthermore, upon arrival at various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the computer storage medium (or vice versa). For example, computer-executable instructions or data structures received via a network or data link can be cached in RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to the computer system RAM and / or the weakly non-volatile computer storage medium at the computer system. Therefore, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize the transmission medium.

[0129] For example, computer-executable instructions include instructions and data that, when executed on one or more processors, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a particular function or a set of functions. For example, computer-executable instructions can be binary, intermediate format instructions (such as assembly language), or even source code.

[0130] Those skilled in the art will understand that this invention can be practiced in network computing environments with various types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. This invention can also be practiced in distributed system environments, where local and remote computer systems connected via network links (via hardwired data links, wireless data links, or a combination of hardwired and wireless data links) perform tasks. Thus, in a distributed system environment, the computer system can include multiple constituent computer systems. In a distributed system environment, program modules can reside in local and remote memory storage devices.

[0131] Those skilled in the art will also understand that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, but this is not required. When distributed, a cloud computing environment can be internationally distributed within an organization and / or have components owned across multiple organizations. In this description and the appended claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the many other advantages that can be obtained from such a model when properly deployed.

[0132] Cloud computing models can be composed of various features, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measurable services. Cloud computing models can also appear in various service models, such as Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). Cloud computing models can also be deployed using different deployment models, such as private clouds, community clouds, public clouds, and hybrid clouds.

[0133] Some embodiments (such as cloud computing environments) may include a system comprising one or more hosts, each capable of running one or more virtual machines. During operation, the virtual machines emulate an operational computing system to support an operating system, and perhaps one or more other applications. In some embodiments, each host includes a hypervisor that emulates the virtual resources of the virtual machines using physical resources abstracted from a view of the virtual machines. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides an illusion about the interface between the virtual machine and physical resources, even if the virtual machine only interfaces with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0134] The invention may be practiced in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes within the equivalent meaning and scope of the claims should be included within their scope. When elements are introduced in the appended claims, the articles “a,” “an,” “the,” and “the” are intended to indicate the presence of one or more elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and indicate that other elements besides those listed may be present.

Claims

1. A method for indexing traces using a difference map, the method being implemented at a computer system including at least one processor, the method comprising: Access a replayable tracing, which records the previous execution of one or more threads of an entity; Within a trace segment, a subset of a sequence of multiple instructions of a first thread in one or more threads is identified, the trace segment recording previous execution of the sequence of instructions, the subset of instructions beginning with a first instruction and ending with a second instruction; The subset of replay instructions is used to obtain the state of one or more named resources, which have a first state at the first instruction and a different second state at the second instruction. Based on the subset of replay instructions, a difference graph is generated for the subset of instructions. The difference graph includes one or more reversible mathematical operations on the first state, which transform the first state into the second state, such that the one or more named resources are brought to the second state by adding the difference graph at the first instruction to the first state using the one or more reversible mathematical operations, and the one or more named resources are brought to the first state by subtracting the difference graph at the second instruction to the second state using the inverse of the one or more reversible mathematical operations. as well as The difference map is stored in conjunction with the tracking.

2. The method of claim 1, wherein storing the difference map in conjunction with the tracking comprises at least one of: (i) storing the difference map in a persistent storage device associated with the tracking, or (ii) storing the difference map in a volatile memory associated with a replay of the tracking.

3. The method of claim 1, wherein the difference map uses a keyframe as a baseline, the addition of the difference map to the keyframe brings the one or more named resources to the second state, and the subtraction of the difference map at the second instruction brings the one or more named resources to the state stored in the keyframe.

4. The method of claim 3, wherein the state stored in the keyframe includes the first state.

5. The method of claim 4, wherein the keyframe is associated with the tracking segment.

6. The method of claim 1, wherein the second state includes a state change made by a second thread of the plurality of threads after the first instruction.

7. The method of claim 1, wherein in response to the difference map being a partial difference map, the second state omits the state change made by the second thread of the plurality of threads after the first instruction.

8. The method of claim 1, wherein the subset of instructions comprises a first subset and a second subset of instructions, and the difference map comprises a first difference map and a second difference map, the method further comprising: The second subset of the sequence of instructions is identified within the tracking segment, the second subset of instructions beginning with a third instruction and ending with a fourth instruction; The second subset of the sequence of replay instructions is used to obtain the state of one or more named resources, which have a third state at the third instruction and a different fourth state at the fourth instruction. as well as Based on the second subset of replay instructions, a second difference map is generated for the second subset of instructions. The second difference map is structured such that adding the second difference map at the third instruction brings the one or more named resources to the fourth state, and subtracting the second difference map at the fourth instruction brings the one or more named resources to the third state.

9. The method of claim 8, wherein the second difference map uses a keyframe as a baseline, and the subtraction of the second difference map at the fourth instruction brings the one or more named resources to a state stored in the keyframe.

10. The method of claim 8, wherein the second difference map uses the first difference map as a baseline, and the subtraction of the second difference map at the fourth instruction brings the one or more named resources to the third state.

11. The method of claim 8, wherein adding the first difference map and the second difference map at the first instruction brings the one or more named resources to the fourth state, and subtracting the first difference map and the second difference map at the fourth instruction brings the one or more named resources to the first state.

12. A method for replaying tracking using a difference map, the method being implemented at a computer system including at least one processor, the method comprising: Access a replayable tracing, which records the previous execution of one or more threads of an entity; Within the replayable trace, a specific instruction is indicated within a trace segment, which records the prior instruction of a sequence of multiple instructions of a first thread of the one or more threads, the multiple instructions including the specific instruction; A set of one or more difference maps is identified for restoring a first state of one or more named resources, the first state being required for simulating the prior execution of the specific instruction, the set of one or more difference maps including one or more reversible mathematical operations on the first state, the one or more reversible mathematical operations transforming the first state into a second state such that the one or more named resources are brought to the second state by adding the difference maps to the first state by applying the one or more reversible mathematical operations to the first state, and the one or more named resources are brought to the first state by subtracting the difference maps from the second state by applying the inverse of the one or more reversible mathematical operations to the second state. Apply the set of one or more difference maps to restore the first state of the one or more named resources; as well as After applying the set of one or more difference maps, the previous execution of the specific instruction is simulated based on the restored first state of the one or more named resources.

13. The method of claim 12, wherein applying the set of one or more difference maps to restore the first state of the one or more named resources comprises adding the set of one or more difference maps to the state of the one or more named resources obtained from a keyframe associated with the tracking segment or a keyframe within another tracking segment.

14. The method of claim 12, wherein applying the set of one or more difference maps to restore the first state of the one or more named resources comprises adding the set of one or more difference maps to the state of the one or more named resources as: a state obtained from another difference map, the other difference map restoring the state to the specific instruction in the sequence of instructions or an instruction preceding the specific instruction in the sequence of instructions.

15. The method of claim 12, wherein applying the set of one or more difference maps to recover the first state of the one or more named resources comprises subtracting the set of one or more difference maps from the state of the one or more named resources at the state at the instruction following the specific instruction in the sequence of instructions.

16. The method of claim 12, wherein applying the set of one or more difference graphs to restore the first state of the one or more named resources comprises: Add multiple difference maps to the restored previous state of the one or more named resources, or subtract the multiple difference maps from the restored previous state of the one or more named resources.

17. The method of claim 12, wherein at least one difference map is obtained from the tracking or from a previously replayed segment of the tracking.

18. The method of claim 12, further comprising: Identify one or more named resources modified by instructions covered by the set of one or more difference maps.

19. The method of claim 12, wherein applying the set of one or more difference maps to restore the first state of the one or more named resources comprises: The first state of the one or more named resources is restored without simulating any instructions.

20. A computer system, comprising: processor, and A computer-readable medium having stored thereon computer-executable instructions, said computer-executable meanings being executable by said processor to cause said computer system to generate and utilize a difference map during a tracking playback process, said computer-executable instructions including instructions executable by said processor to cause said computer system to perform at least the following processes: Access a replayable trace, which records the entity’s previous execution; A subset of the sequence of instructions is identified within a trace segment, the trace segment recording the previous execution of the sequence of multiple instructions of the entity, the subset of instructions beginning with a first instruction and ending with a second instruction; The subset of replay instructions is used to obtain the state of one or more named resources, which have a first state at the first instruction and a different second state at the second instruction. Based on the subset of replay instructions, a difference graph is generated for the subset of instructions. The difference graph includes one or more reversible mathematical operations on the first state, which transform the first state into the second state, such that the one or more named resources are brought to the second state by adding the difference graph at the first instruction to the first state using the one or more reversible mathematical operations, and the one or more named resources are brought to the first state by subtracting the difference graph at the second instruction to the second state using the inverse of the one or more reversible mathematical operations. After generating the difference map, the specific instructions to be replayed are identified within the subset of instructions identified in the replayable trace. The generated difference map is identified for use in obtaining the specific instruction; The difference map is applied to the second instruction to restore the first state of the one or more named resources; as well as After applying the difference map to the second instruction, replaying the subset of instructions includes: restoring the specific instruction based on the restored first state of the one or more named resources.

Images