Abstract: Detecting and providing notice of non-faulting memory accesses during prior execution of an application based on a replay-able trace of the application's execution. Embodiments include replaying portion(s) of prior execution of the application from a replay-able trace the application's prior execution, while tracking lifetime of memory region(s) used by the application. Based on tracking lifetime of the memory region, non-faulting but improper memory access(es) by the application during its prior execution are detected. Notification of these non-faulting but improper memory access(es) are provided at a user interface and/or to a software component.

Abstract: Recording a memory address includes identifying a first subset of high bits of the memory address, determining that a first value of the first subset equals a second value of a group of high bits already recorded, recording a second subset of low bits of the memory address while refraining from recording the first subset, and setting one or more flag bits to indicate that only the second subset were recorded. Also, recording a memory value includes identifying a plurality of groups of consecutive bits of the memory value, determining that a first group contains bits having a defined pattern and that a second group contains bits lacking the defined pattern, recording the second group while refraining from recording at least a portion of the first group, and setting one or more flag bits to indicate that the first group was not recorded.

Abstract: Decoupling trace data streams using cache coherence protocol (CCP) data. One or more trace data streams include cache activity trace data and CCP trace data relating to executing a plurality of threads. The cache activity trace data includes inter-thread data dependencies comprising dependent cache activity trace entries, which each record a corresponding memory access by a corresponding thread in reliance on traced CCP dependence between threads. The inter-thread data dependencies are removed to create independent cache activity trace data for each of the plurality of threads that enables each thread to be replayed independently. The removal includes, for each dependent cache activity trace entry (i) identifying a corresponding value of the corresponding memory access by the corresponding thread based on the traced CCP dependence between threads, and (ii) recording the corresponding value of the corresponding memory access on behalf of the corresponding thread.

Abstract: Trace recording based on recording an influx to a lower-level cache by reference to prior log data, based on knowledge of an upper-level cache. A computing device includes a plurality of processing units, a plurality of N-level caches, and an (N+i)-level cache that is a backing store for the N-level caches. Based on activity of a first processing unit, the computing device detects an influx of data to a first N-level cache. The computing device checks the (N+i)-level cache to determine if the data was already logged for a second processing unit. Based on the check, the computing device (i) causes the data to be logged for the first processing unit by reference to log data (i.e., when the data was already logged), or causes the data to be logged by value for the first processing unit (i.e., when the data was not already logged).

Abstract: Reusing a related thread's cache during tracing. An embodiment includes executing a first thread at a processing unit while recording a trace to a first buffer. During execution, a context switch from the first thread to a second thread at the same processing unit is detected. Based on the context switch, it is determined that the second thread is related to the first thread, and that it is being traced to a separate second buffer. Based on this determination, a cache of the first thread is reused. The reuse includes recording a first identifier in the first buffer, and recording a second identifier in the second buffer. The first and second identifiers provide a linkage between the first buffer and the second buffer. Execution of the second thread is then initiated, while recording a trace to the second buffer, and without invalidating logging state of a cache.

Abstract: Protecting sensitive information in connection with tracing an original execution of an entity. Embodiments include identifying that original information—which was accessed based on an original execution of one or more original executable instructions of the entity—comprises sensitive information. Based on the original information comprising the sensitive information, embodiments include performing one or both of (i) storing first trace data comprising alternative information—rather than the original information—into the trace, while ensuring that an execution path that was taken by the entity based on the original information is also taken during replay of the original execution of the entity using the trace; or (ii) storing second trace data into the trace that causes zero or more alternative executable instructions—rather than the one or more original executable instructions of the entity—to be executed during the replay of the original execution of the entity.

Abstract: Techniques for processing recorded program data are described. In implementations, a trace module in a computing device processes instructions of a recorded program and generates a trace file for program optimization. In implementations, the trace module records a subset of a received program for inclusion in the trace file. The computing device can also or instead be implemented to gather and initiate analysis of application data proactively and without user initiation.

Abstract: Described technologies aid execution control during replays of traced program behavior. Cross-level mapping correlates source code, an intermediate representation, and native instructions in a trace. The trace includes a record of native code instructions which were executed by a runtime-managed program. The trace does not include any executing instance of the runtime. Breakpoints are set to align trace locations with source code expressions or statements, and to skip over garbage collection and other code unlikely to interest a developer. A live debugging environment is adapted to support trace-based reverse execution. An execution controller in a debugger or other tool may utilize breakpoint ranges, cross-level mappings, backward step-out support, and other items to control a replay execution of the trace.

Abstract: Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. A create task function is modified to include the setting of an indicator that a newly created task is to be traced if a current task or thread is being traced. An execute task function is modified to request the tracing of the newly created task when it is executed based on the indicator, thereby enabling selective tracing that operates across process boundaries and traces asynchronous code execution.

Abstract: Expressly turning tracing on and off at each juncture between code that a developer wants to have traced and other code may reduce trace file size but adds computational cost. Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. The amount of extra tracing is balanced against the reduction in trace enablement/disablement operations by tuning thresholds, based on information about routine size and computational cost.

Abstract: Performing a cache-based trace recording using cache coherence protocol (CCP) data. Embodiments detect that an operation that causes an interaction between a cache line and a backing store has occurred, that logging is enabled for a processing unit that caused the operation, that the cache line is a participant in logging, and that the CCP indicates that there is data to be logged to a trace. Embodiments then cause that data to be logged to the trace, which data is usable to replay the operation.

Abstract: Described technologies extend the information available from an execution trace of a program by providing heuristically-derived values for memory contents when the trace does not include data expressly showing the value of a memory cell at a particular execution time. Various heuristics are described. The heuristics may use information about the memory cell at other times to produce the derived value. Some heuristics use other trace data, such as whether the memory cell is in a stack, whether there are gaps in the trace, or whether garbage collection or compilation occurred near the time in question. Grounds for the derived value are reported along with the derived value. A time-travel debugger or other program analysis tool can then present the derived values to users, or make other use of the derived values and grounds to assist debugging and other efforts to improve the functioning of a computing system.

Abstract: Presenting historical state of a code element of a prior execution of an entity. An embodiment includes presenting historical state of the code element based on replaying segment(s) of the prior execution from trace data. Presenting the historical state includes presenting a first state of the code element, in connection with a first execution time point. The first state is based on a first memory access for the code element at the first execution time point. Presenting the historical state also includes presenting the first state of the code element along with an indication that the first state is a last known state (in connection with a subsequent execution time point) or a next known state (in connection with a prior execution time point).

Abstract: Presenting historical state associated with prior execution of an entity. Based on replaying segment(s) of execution of an entity based on a trace, embodiments could present an indication of whether a value of a code element is, at a first execution time point, unknown, known, previously known, and/or known in the future. Additionally, or alternatively, embodiments could present an indication of a value relied upon by simulated execution of a function at a second execution time point, along with an indication of a timing of knowledge of the value in relation to the second execution time point. Additionally, or alternatively, embodiments could present an indication that a return value of a function would be known if the function had executed at a third execution time point, or an indication that the return value would be unknown if the function had executed at the third execution time point.

Abstract: A computing device includes processing units and a shared processor cache. Each cache line is associated with a different plurality of accounting bits, including a unit bit associated with each processing unit. An operation by a particular processing unit on a particular cache line is identified. If the operation is a read consumed by that processing unit, and when a unit bit for that processing unit in the accounting bits associated with the particular cache line is not set, at least the value portion of the particular cache line is stored or referenced in the trace, and the particular unit bit is set. If the operation is a write, each unit bit in the accounting bits associated with the cache line that are associated with any processing unit other than the particular processing unit is cleared, and the particular unit bit associated with the particular processing unit is set.

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: Methods and systems are disclosed for debugging program code at instruction level by emulating an epilog. Issues with retrieving values that a caller function has stored in non-volatile registers before calling a callee function are addressed at the instruction code level by through emulation. The epilog of the callee function may be emulated after copying a computing environment of the target program code from a target system to an emulation system. When the debugged code does not include an epilog, values that a caller function stored before calling a callee function in non-volatile registers may be retrieved by emulating the calling function forward from the breakpoint.

Abstract: Methods and systems are disclosed for logging trace data generated by executing program code at an instruction level. In aspects, high volumes of trace data are generated during certain time periods, e.g., immediately following a start of the tracing. Processors operating at normal speeds are often unable to log such high volumes of trace data. The issue of such high volumes of trace data may be addressed by selectively and dynamically controlling logging of outstanding trace data. For example, a rate of generating the trace may be reduced by slowing processor speeds, logging of outstanding trace data may be suspended for a period, and logging of non-urgent trace data may be selectively delayed.

Abstract: Protecting sensitive information in connection with tracing an original execution of an entity. Embodiments include identifying that original information—which was accessed based on an original execution of one or more original executable instructions of the entity—comprises sensitive information. Based on the original information comprising the sensitive information, embodiments include performing one or both of (i) storing first trace data comprising alternative information—rather than the original information—into the trace, while ensuring that an execution path that was taken by the entity based on the original information is also taken during replay of the original execution of the entity using the trace; or (ii) storing second trace data into the trace that causes zero or more alternative executable instructions—rather than the one or more original executable instructions of the entity—to be executed during the replay of the original execution of the entity.

Abstract: Trace logging based on an upper cache layer determining how to log an influx by a lower cache layer. A second cache receives, from a lower layer first cache, a logging request referencing a memory address. The second cache determines whether it has a cache line for the memory address. When the cache line is present, the second cache either forwards the request to a next logging cache layer or causes the cache line to be logged if second cache is the outermost logging layer. When the cache line isn't present, the second cache causes the cache line to be logged when the cache line isn't determined by the second cache to be logged, or when it is determined by the second cache to be logged but it is not determined whether the first cache is aware of a current value of the cache line in the second cache.