BACKGROUND

[0001] When writing code during the development of software applications, developers commonly spend a significant amount of time "debugging" the code to find runtime and other source code errors. In doing so, developers may take several approaches to reproduce and localize a source code bug, such as observing behavior of a program based on different inputs, inserting debugging code (e.g., to print variable values, to track branches of execution, etc.), temporarily removing code portions, etc. Tracking down runtime errors to pinpoint code bugs can occupy a significant portion of application development time.

[0002] Many types of debugging applications ("debuggers") have been developed in order to assist developers with the code debugging process. These tools offer developers the ability to trace, visualize, and alter the execution of computer code. For example, debuggers may visualize the execution of code instructions, may present code variable values at various times during code execution, may enable developers to alter code execution paths, and/or may enable developers to set "breakpoints" and/or "watchpoints" on code elements of interest (which, when reached during execution, causes execution of the code to be suspended), among other things.

[0003] An emerging form of debugging applications enable "time travel," "reverse," or "historic" debugging. With "time travel" debugging, execution of a program (e.g., executable entities such as threads) is recorded/traced by a trace application into one or more trace files. These trace file(s) can then be used to replay execution of the program later, for both forward and backward analysis. For example, "time travel" debuggers can enable a developer to set forward breakpoints/watchpoints (like conventional debuggers) as well as reverse breakpoints/watchpoints.

BRIEF SUMMARY

[0004] Embodiments herein expand the utility of time travel debuggers by leveraging recoded trace file data and machine learning to identify and present runtime differences between different invocations of an executable entity at a user interface. For example, embodiments may utilize machine learning on trace file data to classify different invocations of the same executable entity into different families, based on differences in their runtime behaviors (e.g., what blocks of code executed, what sequences of blocks of code executed, what exceptions were encountered, etc.). Embodiments can also identify what runtime behavioral attributes contributed to the different invocations being classified into the different families. Using this knowledge, embodiments can visually present differences between different invocations of the entity including, for example, which runtime differences contributed to the entity executing in different manners, coverage of code executed by different invocations, code paths taken by different invocations, what conditions contributed to invocations taking different branches, and the like.

[0005] In some embodiments, a method for presenting one or more differences between code entity invocations comprises identifying a code entity for which a differential analysis is to be performed. The method also includes identifying a plurality of families of invocations of the code entity. Each family is defined based upon a plurality of attributes that identify at least one class of runtime behavior of the code entity. The method also includes identifying one or more first attributes of a first family that substantially contribute to classifying a first class of invocations of the code entity within the first family, and one or more second attributes of a second family that substantially contribute to classifying a second class of invocations of the code entity within the second family. The method also includes presenting differences between at least two invocations of the code entity based on differences between the one or more first attributes and the one or more second attributes.

[0006] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0008] Figure 1 illustrates an example computing environment that facilitates presenting differences between code entity invocations based on trace file data; [0009] Figure 2A illustrates a first example of classifying related invocations of code entities into different families;

[0010] Figure 2B illustrates a second example of classifying related invocations of code entities into different families;

[0011] Figure 3 A illustrates a first example of presenting differences between invocations using a code comparison user interface;

[0012] Figure 3B illustrates a second example of presenting differences between invocations using a code comparison user interface;

[0013] Figure 4 illustrates an example of a user interface that presents differences during a time travel debugging session; and

[0014] Figure 5 illustrates a flowchart of an example method for presenting differences between code entity invocations.

DETAILED DESCRIPTION

[0015] Embodiments herein expand the utility of time travel debuggers by leveraging recoded trace file data and machine learning to identify and present runtime differences between different invocations of an executable entity at a user interface. For example, embodiments may utilize machine learning on trace file data to classify different invocations of the same executable entity into different families, based on differences in their runtime behaviors (e.g., what blocks of code executed, what sequences of blocks of code executed, what exceptions were encountered, etc.). Embodiments can also identify what runtime behavioral attributes contributed to the different invocations being classified into the different families. Using this knowledge, embodiments can visually present differences between different invocations of the entity including, for example, which runtime differences contributed to the entity executing in different manners, coverage of code executed by different invocations, code paths taken by different invocations, what conditions contributed to invocations taking different branches, and the like.

[0016] To the accomplishment of the foregoing, Figure 1 illustrates an example computing environment 100 that facilitates presenting differences between code entity invocations based on trace file data. As depicted, embodiments may comprise or utilize a special-purpose or general-purpose computer system 101 that includes computer hardware, such as, for example, one or more processors 102, system memory 103, one or more data stores 104, and/or input/output hardware 105 (e.g., such as the depicted keyboard/mouse hardware 105a, networking hardware 105b, and display device 105c). In some embodiments, computer system 101, and the components therein, could comprise a virtualized environment.

[0017] Embodiments within the scope of the present invention include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by the computer system 101. Computer-readable media that store computer- executable instructions and/or data structures are computer storage devices. Computer- readable media that carry computer-executable instructions and/or data structures are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage devices and transmission media.

[0018] Computer storage devices are physical hardware devices that store computer- executable instructions and/or data structures. Computer storage devices include various computer hardware, such as RAM, ROM, EEPROM, solid state drives ("SSDs"), flash memory, phase-change memory ("PCM"), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware device(s) which can be used to store program code in the form of computer-executable instructions or data structures, and which can be accessed and executed by the computer system 101 to implement the disclosed functionality of the invention. Thus, for example, computer storage devices may include the depicted system memory 103, the depicted data store 104 which can store computer-executable instructions and/or data structures, or other storage such as on- processor storage, as discussed later.

[0019] Transmission media can include a network and/or data links which can be used to carry program code in the form of computer-executable instructions or data structures, and which can be accessed by the computer system 101. A "network" is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer system, the computer system may view the connection as transmission media. Combinations of the above should also be included within the scope of computer-readable media. For example, the input/output hardware 105 may comprise networking hardware 105b (e.g., a hard-wired or wireless network interface module) that connects a network and/or data link that can be used to carry program code in the form of computer-executable instructions or data structures.

[0020] Further, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage devices (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within networking hardware 105b, and then eventually transferred to the system memory 103 and/or to less volatile computer storage devices (e.g., data store 104) at the computer system 101. Thus, it should be understood that computer storage devices can be included in computer system components that also (or even primarily) utilize transmission media.

[0021] Computer-executable instructions comprise, for example, instructions and data which, when executed at the processor(s) 102, cause the computer system 101 to perform a certain function or group of functions. Computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.

[0022] Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0023] A cloud computing model can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as, for example, Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.

[0024] Some embodiments, such as a cloud computing environment, may comprise a system that includes one or more hosts that are each capable of running one or more virtual machines. During operation, virtual machines emulate an operational computing system, supporting an operating system and perhaps one or more other applications as well. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources that are abstracted from view of the virtual machines. The hypervisor also provides proper isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with a physical resource, even though the virtual machine only interfaces with the appearance (e.g., a virtual resource) of a physical resource. Examples of physical resources including processing capacity, memory, disk space, network bandwidth, media drives, and so forth.

[0025] The data store 104, which typically comprises durable storage, can store computer-executable instructions and/or data structures representing application code such as, for example, a debugger 106 (including, for example, a record component 106a, a replay component 106b, an indexing component 106c, a query/search component 106d, a machine learning component 106e, etc.), an operating system 107, and an application 108 (including portions of executable code 108a of the application 108). The data store 104 can also store other types of data, such as one or more trace file(s) 109. When application code is executing (e.g., using the processor(s) 102), the system memory 103 can store corresponding runtime data, such as runtime data structures, computer-executable instructions, etc. Thus, Figure 1 illustrates the system memory 103 as including runtime debugger data 106' (runtime record data 106a', runtime replay data 106b', runtime indexing data 106c', runtime query/search component data 106d', runtime machine learning component data 106e', etc.), runtime operating system data 107', and runtime application data 108' (including, for example, runtime variables, data structures, etc. of application 108 as it executes, as well as runtime code portions 108a' which are in- memory copies of code portions 108a).

[0026] While the record component 106a, replay component 106b, indexing component 106c, query/search component 106d, and machine learning component 106e are depicted as being part of debugger 106, it will be appreciated that one more of these components could be a standalone application, or part of some other application. The record component 106a is usable to trace execution of an application, such as application 108 (including its executable code portions 108a), and to store trace data in the trace file(s) 109. The record component 106a may, in some embodiments, be integrated into the operating system 107, itself, into a hypervisor, or into some other runtime or virtualization technology. The record component 106a may also exist at an entirely different computer system. Thus, the record component 106a may trace execution of code at another computer system. Then, the trace file(s) 109 resulting from that tracing can be transferred (e.g., using the networking hardware 105b) to the computer system 101 for indexing by the indexing component and/or replay by the replay component 106b. While the trace file(s) 109 are depicted as being stored in the data store 104, they may also be recorded exclusively or temporarily in the system memory 103, or at some other storage device.

[0027] Figure 1 also includes a simplified representation of the internal hardware components of the processor(s) 102. As illustrated, each processor 102 includes processing unit(s) 102a. Each processing unit may be physical (i.e., a physical processor core) and/or logical (i.e., a logical core presented by a physical core that supports hyper-threading, in which more than one application thread executes at the physical core). Thus, for example, even though the processor 102 may in some embodiments include only a single physical processing unit (core), it could include two or more virtual processing units 102a presented by that single physical processing unit.

[0028] Each processing unit 102a executes processor instructions that are defined by applications (e.g., debugger 106, operating system 107, application code portions 108a, etc.), and which instructions are selected from among a predefined processor instruction set architecture. The particular instruction set architecture of a given processor 102 varies based on processor manufacturer and processor model. Common instruction set architectures include the IA-64 and IA-32 architectures from INTEL, INC., the AMD64 architecture from ADVANCED MICRO DEVICES, INC., and various Advanced RISC Machine ("ARM") architectures from ARM HOLDINGS, PLC, although a great number of other instruction set architectures exist and can be used by the present invention. In general, an "instruction" is the smallest externally visible (i.e., external to the processor) unit of code that is executable by a processor.

[0029] Each processing unit 102a obtains processor instructions from a shared processor cache 102b (i.e., shared by the processing units 102a), and executes the processor instructions based on data in the shared cache 102b, based on data in registers 102c, and/or without input data. In general, the shared cache 102b is a small amount (i.e., small relative to the typical amount of system memory 103) of random-access memory that stores on-processor copies of portions of the system memory 103. For example, when executing the executable code portions 108a of application 108, the shared cache 102b stores a subset of the runtime code portions 108b' in a code cache section of the shared cache 102b, and stores other runtime application data 108' (e.g., variables, data structures, etc.) in a data cache section of the shared cache 102b. If the processing unit(s) 102a require data not already stored in the shared cache 102b, then a "cache miss" occurs, and that data is fetched from the system memory 103 (potentially evicting some other data from the shared cache 102b). The registers 102c are hardware based storage locations that are defined based on the instruction set architecture of the processors(s) 102.

[0030] The replay component 106b replays one or more trace file(s) 109 by executing the code of the executable entity upon which the trace file(s) 109 are based at the processor(s) 102, while supplying that code with traced data (e.g., register values, memory values, etc.) from the trace file(s) 109 at appropriate times. Thus, for example, the record component 106a may record execution of one or more code portions 108a of application 108 at the processor(s) 102, while storing trace data (e.g., memory values read by code instructions, register values supplied code instructions, etc.) in the trace files(s) 109. Then, the replay component 106b can re-execute the code portion(s) 108a at the processor(s) 102, while supplying that code with the trace data from the trace files(s) 109 so that the code is executed in the same manner that it was at trace time.

[0031] According the embodiments herein, the indexing component 106c may take as input one or more trace file(s) 109 (e.g., original trace file(s) 109a), and record one or more trace file(s) 109 (e.g., indexed trace file(s) 109b). Indexing generally outputs indexed trace file(s) 109b that are structured to improve replay performance, such as by inserting key frames at various points in the trace (i.e., so that the replay component 106b can initiate replay at various places in the trace), and by inserting additional indexing data structures such as memory snapshots, reverse lookup data structures (that enable the replay component 106b to quickly identify trace segments relevant to desired data, such as accessed memory locations, return values seen, input parameters seen, and the like), etc.

[0032] While Figure 1 illustrates original trace file(s) 109a and indexed trace file(s) 109b as being separate, it will be appreciated that they could actually be the same file. For example, rather than recording an entirely new file, the indexing component 106c may update/augment the input trace file with indexing data. For example the indexing component 106c may update existing data streams of an input trace file, insert additional data streams into an input trace file, append data to the end of an input trace file, prepend data to the beginning of an input trace file, etc.

[0033] The query/search component 106d conducts uses the indexed trace file(s) 109b to respond to user inquiries. For example, a query may use the replay component 106b to replay select portions of the indexed trace file(s) 109b in order to return a raw data set that is responsive to a user's query. A search may further apply rules and machine learning of past queries and/or searches to filter a data set in order to return ranked results that attempt to surface the more relevant results responsive to a user's search.

[0034] The machine learning component 106e applies machine learning techniques to data in the trace file(s) 109 in order to identify attributes relating to execution of one or more of code portions 108a, and to classify these attributes into different families. These families of attributes are then usable by the debugger 106 to enhance and refine the data presented to a user, such as by the replay component 106b or the query/search component 106d. As will be discussed in more detail later, this includes utilizing the families to present runtime differences between different invocations of an executable entity at a user interface (e.g., by the replay component 106b and/or the query search component 106d).

[0035] In some embodiments, the index component 106c utilizes the machine learning component 106e to produce and store these families into indexed trace file 109d during an indexing run. In additional or alternative embodiments, the replay component 106b and/or the query search component 106d utilize the machine learning component 106e in order to apply machine learning on-the-fly in order to respond user-provided commands and requests. When doing so, the replay component 106b and/or the query search component 106d may cause the indexed trace file 109d to be augmented any data produced.

[0036] As mentioned, the machine learning component 106e identifies attributes relating to execution of one or more of code portions 108a, and to classifies these attributes into different families. Each family identifies invocations of the one or more of code portions 108a that are related to each other by their runtime behavior. For example, the same portion of code may execute in different manners when it is invoked due to changes in the environment in which it executes, changes in inputs, changes in timing, etc. The machine learning component 106e therefore identifies different classes of behavior that particular code exhibits when it is invoked, and groups these invocations into different families. For example, if the subject code portion is as function, one family could group patterns of invocations of the function that caused an exception, another family could group patterns of invocations of the function that returned a first return value or a first family of related return values, and yet another family could group patterns of invocations of the function that returned a second return value or a second family of related return values. The machine learning component 106e may also identify a ranking among these families. For example, the families may, in some embodiments, be ranked according to the frequency with which the invocations they identify occurred during execution. Thus, in these embodiments, families of less frequent (i.e., rare) invocations may be ranked higher than families of more frequent (i.e., common) invocations.

[0037] The particular machine learning algorithm(s) used by the machine learning component 106e can vary depending on implementation goals. However, two classes of machine learning algorithms that may be useful are cluster analysis algorithms and anomaly detection algorithms. Cluster analysis refers to classes of machine learning algorithms that group a set of objects in such a way that objects in the same group, or "cluster," are more similar to each other (in at least one way) than those in other clusters. Anomaly detection, on the other hand, refers to classes of machine learning algorithms that identify items in a dataset that do not conform to an expected pattern or other items in the dataset.

[0038] In some embodiments, the machine learning component 106e may use supervised machine learning, in which the machine learning algorithm(s) are supplied with a training dataset. For example, a training dataset could include the identity of desirable types of families, along with example invocations that should be classified under each family. In other embodiments, however, the machine learning component 106e may operate unsupervised, in which it performs its analysis without training data. Thus, the machine learning component 106e may, itself, determine common types of families and the patterns of invocations that belong to those families. In either embodiment, classification models developed by the machine learning algorithm(s) may be refined based on user feedback and/or analysis of how users interact the search result set (e.g., which results the user interacts with).

[0039] To facilitate a further understanding of machine learning techniques, Figures 2A and 2B illustrate some concrete examples of classifying related invocations of code entities into different families. Figure 2A provides one example 200 of machine learning that may be applied based on a code entity comprising a simple function 201, IsPointingToOne (...) . Note that while, for simplicity in description, function 201 shown in a higher-level programming language, in some embodiments it may be preferable for the search component 1500 to operate more granularly at the level lower- level assembly language / processor instructions.

[0040] As will be recognized by those skilled in the art, function 201 receives as an input parameter a pointer (pt r) to a character, and it returns a Boolean— t rue if the character's value is one, or fa l se if the character's value is anything other than one. In particular, at line 2, function 201 dereferences pt r to obtain the character's value, storing that value in the variable tol ns pect, and then at line 3 it determines if the value of tol ns pect is equal to one. If so, function 201 returns t rue at line 4, or it otherwise returns fa l se at line 6.

[0041] Invocations of function 201 are analyzed (e.g., by the machine learning component 106e) to determine different families of its invocations share the same or similar characteristics that may be of interest in relation to execution of function 201 (and particularly as they relate to debugging). Thus, invocations of function 201 can be grouped according to these families.

[0042] As mentioned above, machine learning algorithms can be trained with training datasets. Thus, a user may possibly supply the identity of desired categories of families as part of training datasets, though they can also be identified by using unsupervised machine learning. For example, some categories of families— shown in the first column 203a of table 203— may include those invocations that returned true, those invocations that returned fa lse, and those invocations that threw an exception (i.e., due to a failure to dereference pt r at line 2).

[0043] It will be recognized by those skilled in the art that after executing function 201 a great number of times (e.g., tens, hundreds, thousands, or more)— and depending on the environment in which function 201 executes— one likely pattern of the invocations of function 201 may be that the majority of the invocations returned fa l se (i.e., pt r pointed to something other than one), that most of the remainder of the invocations returned t rue (i.e., pt r pointed to one), and that a small set of the remainder of the invocations threw an exception (i.e., pt r could not be dereferenced since it pointed to an invalid memory location, an inaccessible memory location, etc.).

[0044] There are of course other categories of families that may be used to group related function invocations (as indicated generally by the ellipses in table 203). These may include, for example, a return value type, the direct values of input parameters (e.g., particular addresses/address ranges to which pt r points), the indirect values of input parameters (e.g., the particular values/ranges of values of the characters that ptr references), input parameter types, the values of any global variables (which may, for example, affect the value of pt r and/or the locations it references based on code other than function 201), the types of exceptions thrown, the number of instructions executed during the invocation of function 201, the count of branches taken and/or not taken for each decision point (e.g., the number of times the "if" path is taken at line 3; other types of counts could include the number of times an "els e" path is taken, the number of iterations of a loop, etc.), the number of times each sub-entity (block or sub-function) is executed, data structures changed, etc.

[0045] In some embodiments, classifying related invocations of entities (e.g., function 201) into families comprises dividing those entities into sub-entities (e.g., blocks or sub- functions), and analyzing patterns of invocations of those sub-entities. For example, when operating at the level of processor instructions, sub-entities could comprise "basic blocks"— which are known to those of skill in the art as sequences of instructions that are an execution unit (i.e., in which all or none of the instructions in the block executes, exceptions aside). These sub-entities can be viewed as "virtual" functions, or being separate functions that are invoked by the larger entity (e.g., function 201). Thus, the families can, in some embodiments, group not only invocations of the overall entity, but also related invocations of sub-entities (or sequences of invocations of sub-entities).

[0046] For example, referring to function 201, Figure 2 A illustrates three possible sub- entities 202 (i.e., blocks A, B, and C). Block A includes lines 2 and 3 (which dereference pt r and determine if the dereferenced value equals one), block B includes line 4 (which returns t rue), and block C includes line 6 (which returns fa ls e). Note that if the machine learning component 106e was operating at the level of processor instructions, rather than lines of higher-level source code, each block could include many individual instructions.

[0047] The machine learning component 106e can analyze different invocations of function 201— including invocations of its sub-entities 202— in order to group these invocations into different families. Thus, input to machine learning algorithm(s) may be attributes/variables comprising whether or not individual sub-entities (e.g., basic blocks) were invoked during invocation of function 201. As indicated, the families in which invocations are grouped may be suggested by a human user (e.g., as part of a training dataset), or may be identified entirely by the machine learning component's 106e own analysis.

[0048] For example, table 203 shows mappings between possible categories of families of invocations of function 201 (i.e., column 203a) and attributes values defined by sub-entities (A, B, and C) corresponding to those categories (i.e., column 203b). As shown in column 203a, possible families include when function 201 returned t rue, when function 201 returned fa ls e, and when function 201 threw an exception. In particular, the category "Return Value t rue" corresponds to attribute A=l (i.e., block A is invoked once when function 201 returns t rue), attribute B=l (i.e., block B is invoked once when function 201 returns t rue), and attribute A+B=l (i.e., the sequence A+B is invoked once when function 201 returns t rue). Attributes C=0 and A+C=0 indicate that block C and sequence A+C are not invoked when function 201 returns t rue. Similarly, the category "Return Value fa ls e" corresponds to attributes A=l, C=l, and A+C=l (and block B and the sequence A+B are not invoked when function 201 returns fa ls e). The category "Throw Exception" corresponds to attribute A=l (and blocks B and C are not invoked when function 201 throws an exception, nor are any combinations of blocks invoked). Note that column 203a is shown for clarity and ease in description, in order to introduce the concepts of grouping code entities into categories, and that identity of categories may, or may not, be known prior to a machine learning analysis based on the attributes in column 203b.

[0049] When the attributes in column 203b are supplied to one or more machine learning algorithm(s), those algorithm(s) identify set(s) of attribute(s) that go together in the same family. They can also identify one or more of the families, themselves, and/or group sets of attributes according to one or more predefined families. The algorithm(s) can also rank the families based on the frequency the occurrence of the set(s) of attributes in each family during execution.

[0050] Accordingly, Figure 2A shows three families 204a-204c that each includes sets of attributes that go together, because they characterize invocations of function 201 based on whether it returned t rue, whether it returned fa ls e, or whether it threw an exception. In particular, Figure 2B shows a first family 204a that includes one set of attributes (i.e., B=0, C=0) that characterize invocations in which function 201 threw an exception, a second family 204b that includes three sets of attributes (i.e., A=l, B=l, C=0; A+B=l; and A+C=0) that characterize invocations in which function 201 returned t rue, and a third family 204c that includes two sets of attributes (i.e., B=0, C=l and A+C=l) that characterize invocations in which function 201 returned false. Note that sets of attributes shown are examples only, and are not exhaustive. Additionally, there is some redundancy in the sets of attributes shown— for example, the sets in family 204b could be merged to "B=l, C=0," and the sets in family 204c could be merged on "B=0, C=l ."

[0051] Note that in Figure 2A the families 204a-204c have been sorted by rarity, in which invocations throwing exceptions are most rare and invocations returning false are most frequent. In particular, family 204a is ranked first since the sets of values it identifies occurred least frequently during different invocations of function 201, and family 204c is ranked last since the sets of values it identifies occurred most frequently during different invocations of function 201. This ranking may be based, at least in part, on replaying (i.e., by the replay component 106b) of instances of function 201 as recorded by a trace, and identifying the frequency with which each sequence occurred during execution. Additionally or alternatively, this ranking may be based, at least in part, on reference to indexed data, such as reverse lookup data structures. These rankings are usable for identifying which famil(ies) of invocations might be "normal" and which famil(ies) of invocations might be "abnormal."

[0052] Figure 2B provides another example 205 of machine learning that may be applied to a more complicated function 206, GetProcessingResults (...), that returns cached data, and which performs needed processing if the requested data is not in the cache. As will be recognized by those skilled in the art, function 206 receives as an input parameter a pointer (pinput) to input of the type InputType, and it returns a pointer to data of the type ReturnType that results from processing on pinput by the function PerformProcessing(...)— which is assumed in this example to be expensive enough to warrant caching the result. More particularly, function 206 obtains a key from pinput at line 2. Then, at line 3 is obtains— based on the key— a pointer to cached processing data from cache s_cache (i.e., the results from a prior processing of pinput by PerformProcessing(...)). At line 4 function 206 checks if there was no cached processing data (i.e., the pointer obtained at line 3 is null). If so, it performs the processing at line 5 and adds it to s_cache at line 6. Then, at line 8, function 206 returns the cached data (whether it already existed, or whether it was just added).

[0053] Figure 2B also illustrates three possible sub-entities 207 of function 207 (i.e., blocks A, B, and C). Block A includes lines 2 and 3 (which obtain a key from pinput and obtain a pointer to that key in s_cache), block B includes lines 5 and 6 (which calls PerformExpensiveCalculation(...) on plnput and caches the result), and block C includes line 8 (which returns a pointer to the cached result).

[0054] In addition, while there are a vast array of categories of families that could be used in connection with grouping invocations of GetProcessingResults(...), Figure 2B shows in the first column 208a of table 208 that two possible categories are whether the results were cached or un-cached. Table 208 also shows in the second column 208b that invocations that returned cached results have the attributes A=l, C=l, and A+C=l (i.e., block A and block C are invoked one time each, and sequence A+C is invoked once). Block B and the sequences A+B, B+C, and A+B+C are not invoked. Invocations that returned un-cached results have the attributes A=l, B=l, C=l, A+B=l, B+C=l, and A+B+C=l (i.e., blocks A, B, and C are invoked one time each, and sequences A+B, B+C, and A+B+C are each invoked once). The sequence A+C is not invoked.

[0055] Similar to Figure 2 A, the data in table 208 (e.g., the attributes in column 208b) can be used as input to one or more machine learning algorithm(s) in order to generate ranked families, including, for example, a family identifying set(s) of attributes characterizing invocations of function 206 that returned a cached result directly, and a family identifying set(s) of attributes characterizing invocations of function 206 that returned an un-cached result. These families can be ranked according to the frequency of the occurrence each family's set(s) of attributes.

[0056] For simplicity, the foregoing examples focused on classifying the behaviors invocations of individual functions using input attributes comprising basic blocks making up those functions. However, one of ordinary skill in the art will recognize, in view of the disclosure herein, that this is only one example way of applying machine learning to trace data. For example, machine learning could additionally or alternatively classify invocations at the levels of classes, modules, libraries, source code files, etc. Additionally, the attributes used as input to machine learning algorithms could comprise basic blocks (as in the foregoing examples), unique sequences of basic blocks (e.g., "n-grams" of basic blocks) that repeatedly occurred during an invocation, a count of individual basic blocks and/or n-grams that occurred during an invocation (e.g., due to loops/jumps in code), type(s) of exception(s) that occurred during execution of an invocation, a count of exceptions that occurred during execution of an invocation, functions and/or n-grams of functions that were executed during an invocation (e.g., if the invocation is at the level of a source code file, class, module, etc.), and the like.

[0057] Embodiments can utilize the foregoing machine learning— including use of families of code entity invocations identified by machine learning in order to clearly present to a user runtime differences between different invocations (or families of invocations) of a code entity. For example, based on an identification of a code entity (e.g., source code file, class, module, function, etc.) for which a differential analysis is to be performed, and based on an identification of two or more invocations of that code entity that are to be compared, the machine learning component 106e can utilize the families of invocations— including the attributes associated with those families— to identify one or more differences in the manner in which those invocations executed at runtime. Those runtime differences can then be presented at a user interface (e.g., by the replay component 106b, the query/search component 106d, etc.).

[0058] Runtime differences between invocations can be identified based on the differences between the attributes associated with the families to which the invocations that are being compared have been sorted. For example, referring back to Figure 2A, if one or more invocation(s) of function 201 that returned true are being compared to one or more invocation(s) of function 201 that returned false, the differences between the attributes in family 204b and the attributes in family 204c can be used to identify differences in runtime behavior between the invocations. In some embodiments all (or substantially all) of the attributes for each family may be presented as representing runtime behavior of each invocation. For example, when considering each block (A, B, and C) of function 201 individually, the attributes of "A=l, B=l, and C=0" contributed to invocations of function 201 being classified as returning true, while attributes of "A=l, B=0, and C=l" contributed to invocations of function 201 being classified as returning false. Thus, the runtime behaviors between two invocations could be presented based on these attributes.

[0059] Figure 3A illustrates one example of presenting differences between invocations using a code comparison user interface 301, in which the coverage of code executed by each invocation is presented side-by-side. User interface 301 may, for example, be presented by the query/search component 106d based on a selection of search results, or by replay component 106b based on a selection of a function during a debugging session. In Figure 3 A, code coverage of a first invocation of function 201 that returned t rue is displayed in a left pane 302, and code coverage of a second invocation of function 201 that returned fa ls e is displayed in a right pane 303. In this example, user interface 301 indicates code coverage by emphasizing executed lines of code in bold face, though this could be done in a number of manners such as through use of colors, different font faces, different font sizes, pointers or other indicators, etc. Here, since the first invocation executed blocks A and B, the lines corresponding to those blocks (2-4) are shown in bold in the left pane 302, and since the second invocation executed blocks A and C, the lines corresponding to those blocks (2, 3, and 6) are shown in bold in the right pane 303. Thus, at a quick glance, a user can identify differences between how the different invocations executed.

[0060] In some embodiments the machine learning component 106e can offer further refinements by identifying only a subset of attributes for each invocation to present— such as only those attributes that substantially contributed to an invocation being categorized under a family, or only those attributes that contributed most to an invocation being categorized under a family. For example, while the attributes of "A=l, B=l, and C=0" contributed to invocations of function 201 being classified as returning t rue, and the attributes of "A=l, B=0, and C=l" contributed to invocations of function 201 being classified as returning fa l se, some attributes contributed more than others. Since both invocations executed code block A, this attribute did not contribute to the decision to classifying these invocations into family 204b versus family 204c. However, attributes B and C did. As such, when presenting differences between invocations, that presentation may distinguish the invocations based on attributes B and C, while excluding attribute A.

[0061] Figure 3B illustrates another example of presenting differences between invocations using a code comparison user interface 304 that is similar to user interface 301. Like interface 301, user interface 304 presents code executed by each invocation side-by-side (with execution of a first invocation represented in a left pane 305 and execution of a second invocation represented in a right pane 306). However, unlike user interface 301— which highlights full code coverage, user interface 304 highlights only the code that substantially contributed (or contributed most) to the invocation being classified into its respective family. Thus, since the first invocation's execution of block B contributed most to it being classified as returning t rue, only line 4 (corresponding to block B) is shown in bold in the left pane 305. Similarly, since the second invocation's execution of block C contributed most to it being classified as returning fa l se, only line 6 (corresponding to block C) is shown in bold in the right pane 306. Thus, at a quick glance, a user can quickly drill down to the code that was most important for causing different behaviors between two invocations.

[0062] Note that hybrid approaches are also possible. For example, a user interface may present full code coverage between invocations, but emphasize the particular portions that contributed most to differing behaviors. For example, panes 302 and 305 could be combined by emphasizing lines 2 and 3 in a first color (i.e., to indicate they were executed by the invocation) and emphasizing line 4 in a second color (i.e., to indicate that is was executed by the invocation, and that it contributed to the invocation returning t rue). Similarly, panes 303 and 306 could be combined by emphasizing lines 2 and 3 in a first color (i.e., to indicate they were executed by the invocation) and emphasizing line 6 in a second color (i.e., to indicate that is was executed by the invocation, and that it contributed to the invocation returning fa l se).

[0063] Note that user interfaces such as user interface 301 and 304 can present additional information, depending on the attributes used to classify invocations. For example, if the code includes looping (e.g., statements such as for, wh ile, etc.), a source code line corresponding to the loop could be annotated with a number of times the invocation took the loop. Additionally or alternatively, the number of times different lines were executed could be presented as a "heat map," such as using lighter shading for less frequently executed lines, and darker shading for more frequently executed lines. As another example, if the code includes branching (e.g., statements such as if , el se, c a s e, etc.), a source code line corresponding to the branch could be annotated with an indication of which branch was taken. In the case of branching, the source code line corresponding to the branch could further be annotated to highlight which condition of the branch (e.g., which parameter among a plurality of parameters) cause the branch to be taken in the way it was. As another example, if an exception occurred, the source code line that caused the exception could be annotated to indicate such, and could potentially include other information such as the exception type, a number of times the exception occurred, etc.

[0064] Other types of user interfaces for presenting differences between invocations are also possible. For example, Figure 4 illustrates just one example of a user interface 400 that could present differences during a time travel debugging session. For example, Figure 4 presents an example debugging session, such as one that could be presented by the replay component 106b, of a prior invocation of function 206 of Figure 2B while comparing it to another invocation of function 206.

[0065] User interface 400 illustrates a few illustrative examples of how differential analysis could be applied while stepping through an invocation of function 206. As indicated in the header 401, the replay of execution of the code of GetResults.cpp during invocation X is being performed, while comparing it to invocation Y. In user interface 400, execution of function 206 during invocation X has been halted at line 16, as indicated by arrow 402. Here, as indicated in a breakpoint pane 403, the code replay has been halted do to a breakpoint. A user could have manually requested this breakpoint, however some embodiments contemplate automatically breaking replay when differences in execution between two invocations are encountered. Thus, as indicated in breakpoint pane 403, this breakpoint was set automatically, due to a difference in how the if statement was evaluated during execution of invocations X and Y. User interface also includes a differential analysis pane 404, which details these differences. For example, as indicated, the current invocation (X) evaluated the condition as fa ls e, and skipped to line 20. By contrast, the compared invocation (Y) evaluated the condition as t rue and proceeded to line 17.

[0066] There are many different ways in which an interface such as user interface 400 could present differences. For example, the user interface could hide or collapse code in which the invocations executed in the same manner, including entire branches of code in which the other invocation took the same code path. As another example, as user interface 400 could indicate at branches that the other invocation took the other path in a variety of manners (in addition or as an alternative to the differential analysis 404 shown), such as by highlighting or color-coding of lines of code taken by the other invocation (e.g., as described in connection with Figure 3B), by using a tooltip or other form of popup associated with the line of code associated the condition, by annotating the line of code associated the condition with an icon or some other indicator, etc. Additionally, any of the examples discussed in connection with Figure 3B could be applied to user interface 400, including presenting interface 400 in a split-pane view.

[0067] Differences could also be presented using a graphical view of paths taken. For example, a user interface could present high-level code structure in any relevant form, such as a tree, a graph, etc. This structure could then be annotated (e.g., with text, different colors, holding, etc.) to indicate which paths different invocations took, how many times invocations executed certain elements, where exceptions occurred, etc. In some embodiments, different structures corresponding to different invocations could be visually presented side-by-side.

[0068] Additionally, while the user interfaces have been described as comparing differences between individual invocations, they could be equally applicable to comparing entire families of invocations (e.g., comparing a single invocation to a family of invocations, or comparing one family of invocations to another family of invocations). For example, rather than depicting differences in behaviors of individual invocations, the user interface could depict differences in behaviors that are common to all, most, or a statistically significant number of invocations in one family versus behaviors that are common to all, most, or a statistically significant number of invocations in another family.

[0069] Furthermore, while the user interfaces herein depict comparisons between two invocations (or families), they could be extended to comparing more than two invocations/families at the same time. For example, Figures 3A and 3B could use additional panes, or Figure 4 could present information for alternate invocations beyond invocation Y.

[0070] In view of the foregoing, Figure 5 illustrates an example of a method 500 for presenting differences between code entity invocations. Method 500 is described in view of Figures 1-4. While method 500 is presented as a series of acts, it will be appreciated that the particular number and ordering of the acts shown is only example of presenting differences between code entity invocations.

[0071] As depicted, method 500 includes an act 501 of identifying a code entity for differential analysis. In some embodiments, act 501 comprises identifying a code entity for which a differential analysis is to be performed. For example, a code entity could be selected based on user activity during replay by the replay component 106b, or based on a selection of search results presented by the query/search component 106d. This code entity could comprise executable instructions corresponding to an entire source code file or set of source code files, or executable instructions corresponding individual code sections, such as classes, modules, functions, etc.

[0072] Method 500 also includes an act 502 of identifying families of invocations of the code entity. In some embodiments, act 502 comprises identifying a plurality of families of invocations of the code entity, each family being defined based upon a plurality of attributes that identify at least one class of runtime behavior of the code entity. For example, as described in connection with Figures 2A and 2B, the machine learning component 106e can develop families of code entity invocations based on attributes (e.g., code blocks and/or code block sequences executed, exceptions encountered, a count of code blocks/sequences executed, etc.) that describe runtime behavior of different invocations. These families could be identified as part of indexing by the indexing component 106c, and/or based on a request by the replay component 106b and/or the query/search component 106d in response to user input.

[0073] Method 500 also includes an act 503 of identifying attributes that substantially contribute to classifying different invocations. In some embodiments, act 503 comprises identifying one or more first attributes of a first family that substantially contribute to classifying a first class of invocations of the code entity within the first family, and one or more second attributes of a second family that substantially contribute to classifying a second class of invocations of the code entity within the second family. For example, as discussed in connection with Figure 2A, the machine learning component 106e can identify which attributes substantially contributed, or contributed most, to a subject invocation being classified within a particular family. Thus, for each invocation that is to be compared, these attributes can be identified.

[0074] Method 500 also includes an act 504 of presenting differences between invocations based on the identified attributes. In some embodiments, act 504 comprises presenting differences between at least two invocations of the code entity based on differences between the one or more first attributes and the one or more second attributes. For example, as described in connection with Figures 3A-4, there are a variety of ways in which differences could be presented at a user interface.

[0075] Presentation could include, for example, presenting a graphical view of first code coverage based on the one or more first attributes versus second code coverage based on the one or more second attributes (e.g., as shown in Figures 3A and 3B), presenting a graphical view of a first code path taken based on the one or more first attributes versus a second code path taken based on the one or more second attributes (e.g., as part of a tree or graph diagram), indicating that a second invocation took a different branch than the first invocation, automatically breaking at one or more branches taken by the second invocation, hiding one or more branches taken by the second invocation, indicating which of a plurality of conditions caused the second invocation to take an alternate execution path, etc.

[0076] Accordingly, the embodiments herein expand the utility of time travel debuggers by leveraging recoded trace file data and machine learning to identify and present runtime differences between different invocations of an executable entity at a user interface. Embodiments can visually present differences between different invocations of the entity including, for example, which runtime differences contributed to the entity executing in different manners, coverage of code executed by different invocations, code paths taken by different invocations, what conditions contributed to invocations taking different branches, and the like.

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

[0078] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.