Abstract: A trace of the execution of a program is recorded. This program trace includes various information regarding each instruction of the program that is executed, such as the values or locations of any inputs to the instruction, the values or locations of any outputs by the instruction, and so forth. After execution of the program completes, an execution analysis system analyzes the program trace and can perform various different tasks. One such task that the execution analysis system can perform is automatically identifying potential concurrency problems with the program resulting from asynchronous execution of threads of the program. Another such task that the execution analysis system can perform is reordering the information in the program trace so that a linear view of the information can be displayed in accordance with the order of the code in the program rather than the order in which the asynchronous threads were executed.

Abstract: Focusing execution of traced code includes, during replay of an executable entity based on a trace file, suspending replay of the executable entity at a particular point in the replay. While suspended, user input specifying a runtime data structure existing at the particular point in the replay is received. Based on the user input, one or more code elements, within a defined search depth, are identified. These code element's execution contributed to a value of the runtime data structure at the particular execution point. The identity of the code element(s) are presented at a user interface.

Abstract: Tentatively executing an entity includes performing a first, execution of an entity. At a point in the first execution, the first execution is suspended and input specifying an alternate value for a runtime data element is received. Based on the input, a second execution of the entity is performed starting at the point in the first execution, while enabling the first execution to be later resumed unaffected by the second execution. This second execution includes setting the runtime data element to the alternate value, and emulating one or more memory writes performed by the entity during the second execution. The first execution of the entity could comprise a live execution, an execution that is based on trace data, an execution based on a process dump, etc.

Abstract: Embodiments herein are directed to parallel replay of code execution. An embodiment parses trace data comprising a plurality of trace data streams that each represents execution of a corresponding one of a plurality of executable entities, and identifies a plurality of trace sections that each represents one or more events executed by one of the executable entities over a period of time. The embodiment defines an ordering among the trace sections, identifies a point of interest in at least one of the executable entities, and identifies a subset of the trace sections that, when replayed linearly according to the ordering, would encounter the point of interest. The embodiment queues the subset of trace sections in an execution pool for replay by one or more processors. Then, based on the trace data, the embodiment uses the processor(s) to replay two or more of the subset of trace sections in parallel.

Abstract: Querying resource lifetime using a trace of program execution. An embodiment includes identifying a query expression targeted at least a portion of the trace of program execution. The query expression specifies at least (i) a data object representing a plurality of events identified in the trace, each event associated with one or more attributes relating to resource lifetime, and (ii) one or more conditions matching the one attributes relating to resource lifetime. In response to receiving the query expression, the query expression is processed based at least on an analysis of an identified subset of the trace. Based on processing the query expression, a result data set that includes or identifies at least one of the plurality of events that meets the one or more conditions is presented.

Abstract: Recording a replay-able trace of execution of a multi-threaded process includes identifying a trace memory model that defines one or more orderable events that are to be ordered across a plurality of threads of the multi-threaded process. The plurality of threads are executed concurrently across one or more processing units of one or more processors. During execution of the plurality of threads, a separate replay-able trace is recorded for each thread independently. Recording includes, for each thread, recording initial state for the thread, recording at least one memory read performed by at least one processor instruction executed by the thread that takes memory as input, and recording a least one orderable event performed by the thread with a monotonically increasing number that orders the event among other orderable events across the plurality of threads.

Abstract: Preserving memory values during replay includes identifying trace sections that each represents events executed by an entity over a period of time. A parallel replay of trace sections is performed at a plurality of processing units. While performing the parallel replay, a persistence data structure corresponding to each trace section is maintained. This includes, for each trace section, storing, in the trace section's persistence data structure, a record of each memory address consumed by the processing unit while replaying the trace section, and a most recent memory value stored at each memory address. Returning a memory value during replay includes identifying relevant persistence data structures, and searching these data structures, in turn, based on a defined ordering. When a relevant memory address is identified during the search, the search is ceased and the value associated at the memory address, as stored in a persistence data structure, is returned.

Abstract: Replaying a trace that relies on processor undefined behavior includes identifying reliance on processor undefined behavior by an instruction executed based on replay of traced program execution from a trace file. Based on the reliance on the processor undefined behavior, the replay includes one or more of: (i) initiating a notification of the reliance on the undefined behavior, (ii) skipping to a key frame in the trace file, and resuming replay at the key frame, (iii) forking replay using two or more potential behaviors, or (iv) continuing replay using a selected behavior that is selected from among the two or more potential behaviors.

Abstract: Distributed trace recording and replay is based on tracing execution of a first entity at a first computer system, while also concurrently and independently tracing execution of a second entity at a second computer system. The traces include corresponding orderable events that occurred during execution of the entities at their corresponding computer systems, and are recorded at fidelity that enables complete replay of the recorded execution of the entities. Each trace includes information that at least partially orders, among the respective orderable events, sending or receipt of at least one message passed between the entities.

Abstract: Enabling breakpoints on entire data structures include methods, systems, and computer program products for setting breakpoints on a plurality of memory addresses covered by a data structure. One embodiment includes receiving a reference to a data structure for which breakpoints are requested and then, based on this reference, identifying a data structure layout of the data structure. Based on the data structure layout of the data structure, a plurality of memory addresses that are covered by the data structure are identified, and the plurality of memory addresses are added to a list of breakpoints.

Abstract: Presenting differences between code entity invocations includes identifying a plurality of families of invocations of a code entity. Each family is defined based upon a plurality of attributes that identify a class of runtime behavior of the code entity. First attribute(s) of a first family are identified. These first attribute(s) substantially contributed to classifying a first class of invocations of the code entity within the first family. Similarly, second attribute(s) of a second family are identified. These second attribute(s) substantially contributed to classifying a second class of invocations of the code entity within the second family. Differences between at least two invocations of the code entity are presented, based on differences between the one or more first attributes and the one or more second attributes.

Abstract: A processor is configured to record a replay-able trace of execution of an execution entity. Based on detection of a cache miss during the execution of the execution entity, the processor records an influx of data imported into a processor cache in response to the cache miss, and sets a hardware bit on a cache line of the processor cache storing the influx of data. The hardware bit indicates that the cache line has been recorded into a trace. In addition, the processor records an event selected from a group consisting of (i) an un-cached read resulting from execution of the execution entity, the recorded event including the result of the un-cache read; (ii) execution of a non-deterministic processor instruction, the recorded event including a register value changed by the execution of the non-deterministic processor instruction; and (iii) an access to a model-specific register, the recorded event including a side effect of the access to the model-specific register.

Abstract: Embodiments relate to a virtualization layer capturing replayable execution traces of VMs managed by the virtualization layer. Execution tracing can be performed on any unit of execution managed by the virtualization layer, e.g., threads, processes, virtual processors, individual VMs, multiple VMs, etc. Traced execution units may be executing in parallel. Execution tracing involves capturing to a buffer: executed instructions, memory inputted to instructions, memory outputted by instructions, registers touched by instructions, and ordering markers. Trace data can be captured in chunks, where causality is preserved and ordering is preserved between chunks but not necessarily within chunks. The chunks may be delineated by inserting monotonically increasing markers between context switches, thus relatively ordering the chunks. Determinism may be partially provided by identifying non-deterministic events. VM tracing may be transparent to guest software, which need not be instrumented.

Abstract: Enabling breakpoints on entire data structures include methods, systems, and computer program products for setting breakpoints on a plurality of memory addresses covered by a data structure. One embodiment includes receiving a reference to a data structure for which breakpoints are requested and then, based on this reference, identifying a data structure layout of the data structure. Based on the data structure layout of the data structure, a plurality of memory addresses that are covered by the data structure are identified, and the plurality of memory addresses are added to a list of breakpoints.

Abstract: Querying resource lifetime using a trace of program execution. An embodiment includes identifying a query expression targeted at least a portion of the trace of program execution. The query expression specifies at least (i) a data object representing a plurality of events identified in the trace, each event associated with one or more attributes relating to resource lifetime, and (ii) one or more conditions matching the one attributes relating to resource lifetime. In response to receiving the query expression, the query expression is processed based at least on an analysis of an identified subset of the trace. Based on processing the query expression, a result data set that includes or identifies at least one of the plurality of events that meets the one or more conditions is presented.

Abstract: Creating key frames during indexing of a trace for responsive trace replay. A method includes identifying responsiveness goal(s) for trace replay, including identifying a target trace section replay time. A portion of execution of executable entit(ies) is replayed based on trace data stream(s). While replaying execution of the executable entit(ies), and based on the identified target trace section replay time, points of interest in execution of the executable entit(ies) are identified. At least one key frame is created for each of the identified plurality of points of interest. Each key frame enables replay of at least one of the one or more executable entities beginning at the key frame.

Abstract: Techniques for estimating time remaining for an operation are described. Examples operations include file operations, such as file move operations, file copy operations, and so on. A wide variety of different operations may be considered in accordance with the claimed embodiments, further examples of which are discussed below. In at least some embodiments, estimating a time remaining for an operation can be based on a state of the operation. A state of an operation, for example, can be based on events related to the operation itself, such as the operation being initiated, paused, resumed, and so on. A state of an operation can also be based on events related to other operations.

Abstract: Recording a replay-able trace of execution of a multi-threaded process includes identifying a trace memory model that defines one or more orderable events that are to be ordered across a plurality of threads of the multi-threaded process. The plurality of threads are executed concurrently across one or more processing units of one or more processors. During execution of the plurality of threads, a separate replay-able trace is recorded for each thread independently. Recording includes, for each thread, recording initial state for the thread, recording at least one memory read performed by at least one processor instruction executed by the thread that takes memory as input, and recording a least one orderable event performed by the thread with a monotonically increasing number that orders the event among other orderable events across the plurality of threads.

Abstract: Preserving memory values during replay includes identifying trace sections that each represents events executed by an entity over a period of time. A parallel replay of trace sections is performed at a plurality of processing units. While performing the parallel replay, a persistence data structure corresponding to each trace section is maintained. This includes, for each trace section, storing, in the trace section's persistence data structure, a record of each memory address consumed by the processing unit while replaying the trace section, and a most recent memory value stored at each memory address. Returning a memory value during replay includes identifying relevant persistence data structures, and searching these data structures, in turn, based on a defined ordering. When a relevant memory address is identified during the search, the search is ceased and the value associated at the memory address, as stored in a persistence data structure, is returned.

Abstract: Recording a replay-able trace of execution of an executable entity using cache data includes executing one or more threads of the executable entity concurrently across one or more processing units of the one or more processors. During execution of the one or more threads, a separate replay-able trace is recorded for each thread independently. Recording includes, for each thread, recording initial processor register state for the thread. Recording also includes, for each thread, and upon detecting a processor data cache miss, recording at least one line of cache data imported into the processor data cache.