Selective tracking portion of computer process execution

Abstract

Unambiguously turning on and off tracking at each connection point between the code that a developer wishes to track and other code can reduce the tracking file size but increase computational costs. The described techniques support selective tracking of execution of a process, some additional tracking in addition to code that a developer wants to track, but significantly reduce computational costs by reducing the number of tracking enable and disable operations. The tracking controller uses a tracking disabling distance variable, the value of which indicates a computational distance from the tracking disabling. As the process is executed, the distance variable modifier automatically moves the distance variable closer to the stop tracking value. Based on information about routine size and computational cost, an additional amount of tracking is balanced with a reduction in tracking enable / disable operations by adjusting a threshold. Operation of the tracking controller is described by example APIs, tracking state diagrams, and side-by-side comparisons, among others.

Description

[0001] Related Applications

[0002] This application is a divisional application of a patent application for invention, with an international filing date of April 22, 2019, entering the Chinese national phase on October 27, 2020, a Chinese national application number of 201980028633.4, and an invention title of "Selective Trace Portions of Computer Process Execution". Background Art

[0003] Computer software is generally complex. Some of the complexity may arise from the nature of the work the program is designed to perform, e.g., tracking a large number of real-world items or ongoing transactions over hours or longer, coordinating activities with other complex software, controlling complex hardware, etc. Complexity also occurs in almost any real-world use of software because many details are introduced and should be correctly managed to instruct the computer hardware on how to perform real-world work, which is much less precise when initially described in English or another natural language. That is, the translation from a high-level description to a low-level implementation executable by a computer system inevitably introduces complexity. Even programming language source code, which is more precise than natural language, is still at a relatively high level and is thus ambiguous and open to various interpretations and implementations. The source code is translated into low-level instructions directly executable by computational hardware, many details are introduced, and choices are made during the translation.

[0004] Complexity introduction often raises the possibility of programming errors (also known as "defects", bugs). The process of identifying the cause of a defect and attempting to modify the program to remedy or remove the effects of the defect is called "debugging". Specialized software tools that assist in debugging are called "debuggers". The program being debugged is called the "debuggee".

[0005] Debugging can be easiest when the developer can freely run the debuggee slowly or at full speed, or freely pause the execution of the debuggee, and can inspect all the state information of the debuggee at any time during its execution. This is called "real-time process debugging". However, such full access to the debuggee is usually not available. For example, the debuggee can be production software that cannot be debugged in real time without violating service agreements or harming the reputation, security, or financial situation of the interested parties. If a real-time process debuggee is paused for a few seconds at a time while the developer examines variable values, checks which function calls were made with which parameter values, views the source code, considers possible explanations for the defect, and designs tests that might help identify, remedy, or eliminate the defect, unacceptable harm might be caused.

[0006] Accordingly, sometimes status information is recorded during the execution of a debuggee so that it can be examined later with little or no suspension of the debuggee's execution. For example, some or all of the memory values associated with the execution of the debuggee and operations on those values can be recorded over time in an execution trace. In cases where the debuggee is not a real-time process, some debuggers support using such a trace to replay the execution of the traced debuggee. Using some debuggers, the execution of the debuggee captured in the trace can be replayed forward or backward, thus permitting "time travel", "reverse", or "historical" debugging.

[0007] However, tracing generally slows down the debuggee. Thus, tracing the progress of the execution of a software program while avoiding an undue impact on software performance helps to improve the information available for debugging and will thus tend to improve the functionality of the debuggee computer system by supporting the mediation and elimination of their defects. SUMMARY OF THE INVENTION

[0008] Some of the techniques described herein relate to the technical activity of creating an execution trace that focuses on the parts of a program that are most likely to contain defects of interest, thereby improving trace-based debugging. Some teachings relate to specific computational mechanisms for balancing the computational cost of enabling or disabling tracing against the computational and storage costs of tracing code that is not helpful for a particular debugging effort. Technical mechanisms for adapting the environment to create a focused trace from a native or managed process are described. In response to the challenge of focusing a trace on user code of interest, specific technical tools and techniques are described herein to reduce the undesired performance degradation and increase in trace size due to tracing non-user code such as kernel, compiler, garbage collector, or standard library code. Other technical activities related to the teachings herein will also become apparent to those skilled in the art.

[0009] Some of the selective execution tracing embodiments described herein include a processor, a digital memory operably communicable with the processor, and executable code for a computer-implemented process. The executable code has portions that are implicitly or explicitly designated for tracing and other portions that are not designated for tracing. There is an execution tracer, with a tracing disabler to disable tracing of the execution tracer and a tracing enabler to enable tracing of the execution tracer. The tracing controller includes a tracing disable distance variable, the varying value of which indicates the current computed distance from the execution tracing disabler. That is, the larger the distance variable when tracing is enabled, the more execution of the executable code will be traced before tracing is disabled. The tracing controller invokes the tracing disabler in conjunction with the distance variable having a stop tracing value (e.g., zero). The tracing controller can then invoke the tracing enabler in conjunction with the distance variable not having a stop tracing value. As the executable code executes, a distance variable modifier incrementally moves the distance variable closer to the stop tracing value. For example, the distance variable modifier can decrement a positive value in the distance variable, thus moving the distance variable closer to zero, and when the distance variable reaches zero, tracing will be disabled.

[0010] By using a distance variable to control tracing disablement rather than explicitly invoking the tracing disabler each time execution exits a portion of the executable code designated for tracing, embodiments can reduce the computational cost of tracing. This can be beneficial in various situations because tracing is used for multiple purposes such as during debugging to assist code understanding, for statistical analysis, and to support other goals. This reduction in computational cost comes at the expense of tracing some code that is not of interest. The tracing file may be larger than in the case of tracing only the code of interest, but the performance impact of the tracing tends to be less compared to the case of tracing only the code of interest. For example, in a debugging context, when the code is outside the suspected portion of the code, it is considered "not interesting" relative to a particular defect, making it less likely to contribute to identifying and mitigating or removing the defect. For example, code in items such as kernels, compilers, system libraries, or garbage collectors is not interesting for identifying defects in user code outside of those items.

[0011] Some embodiments described herein relate to configuring an environment to perform computer-implemented selective execution tracing. Some embodiments particularly relate to configuring executable code for tracing, where the tracing is controlled using a trace-disable distance variable (i.e., a variable whose value indicates the relative distance in computational cost to disabling the trace). A method embeds non-zero high-count assurance code in the executable code, where the non-zero high-count assurance code is configured to set the distance variable to a value not less than a high-count threshold when executed. The method associates an instruction count decrement mechanism with the executable code, where the instruction count decrement mechanism is configured to decrement the distance variable as the executable code executes. The method also couples an execution tracer to the executable code. The method configures a trace controller to disable tracing when the distance variable reaches a stop-tracing value, and also configures the trace controller to enable tracing during at least a portion of the execution of the executable code when the distance variable is different from the stop-tracing value.

[0012] Some embodiments relate to actually performing computer-implemented selective execution tracing. One embodiment sets a trace-disable distance variable at an entry point of a code unit. The distance variable is set to a value not less than a non-zero high-count threshold. The distance variable measures the relative distance in computational cost to disabling the trace. In combination with setting the distance variable to a value not less than the high-count threshold, the embodiment makes a call that, if tracing has not been enabled, supports the execution tracer to trace up to the value of the distance variable number of instructions, and if tracing has already been enabled, causes the tracing to continue to be enabled. At an exit point of the code unit, the embodiment sets the distance variable to a non-zero low-count threshold less than the high-count threshold. As the computer processor executes the instructions of a computer process that includes the code unit, the distance variable automatically decrements. When the value of the distance variable is positive and the execution tracer is enabled, the execution tracer will trace the execution of the computer process, and if the value of the distance variable reaches zero, the embodiment will disable the tracing of the execution of the computer process.

[0013] The examples given are merely illustrative. This "Summary of the Invention" is neither intended to identify key features or essential features of the claimed subject matter nor to be used to limit the scope of the claimed subject matter. Instead, this "Summary of the Invention" is provided to introduce some technical concepts in a simplified form that will be further described in the "Detailed Description" below. The invention is defined by the claims, and in case of conflict between this Summary of the Invention and the claims, the claims shall prevail. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] A more specific description will be given with reference to the accompanying drawings. These drawings only illustrate selected aspects and thus cannot fully determine coverage or scope.

[0015] Figure 1is a block diagram showing a computer system and also showing a configured storage medium;

[0016] Figure 2 is a block diagram showing aspects of tracking a managed code process;

[0017] Figure 3 is a block diagram showing aspects of tracking a native code process;

[0018] Figure 4 is a block diagram showing aspects of performing tracking;

[0019] Figure 5 is a block diagram showing some types of memory cells that can be referenced in tracking;

[0020] Figure 6 is a block diagram showing aspects of thread tracking data;

[0021] Figure 7 is a block diagram showing aspects of a selective execution tracking system;

[0022] Figure 8 is a block diagram showing aspects of the computational cost advantage of tracking with a tracking disable distance variable versus tracking without such a distance variable;

[0023] Figure 9 is a block diagram showing aspects of a tracking controller that uses a tracking disable distance variable to control the performance of tracking;

[0024] Figure 10 is a tracking state diagram;

[0025] Figure 11 is a block diagram showing various code units that can be tracked and associated items;

[0026] Figure 12 is a block diagram showing some aspects of code that can be related to tracking and some adjustment conditions that can be employed when tracking code under the control of a tracking disable distance variable;

[0027] Figure 13 is a computational cost comparison of side-by-side tracking control implementations in a tracking scenario;

[0028] Figure 14 is a flowchart showing an example method for configuring a system for selective execution tracking that uses a tracking disable distance variable;

[0029] Figure 15 is a flowchart showing an example method for selective execution tracking that uses a tracking disable distance variable; and

[0030] Figure 16is a flowchart further illustrating a method related to selective execution tracing using a trace-disable distance variable. Detailed Description

[0031] Overview

[0032] Software developers are often responsible for investigating software bugs that are difficult to reproduce, or bugs that occur on machines they do not have access to for direct debugging purposes. In these cases, a system that automatically records the execution of a process to a file so that the problem can be debugged later, or debugged without interrupting the execution of the process, would be helpful. However, such recording can lead to significant overhead and extremely large file sizes.

[0033] In particular, debugging in a production cloud environment presents serious technical challenges. For example, assume that a particular request R for an online shopping cart does not work. How can a developer debug the processing of request R without slowing down the processing of all other requests and minimizing the slowdown of the processing of request R? To find the bug, the developer uses information about what is happening inside the code, such as a way to view the values of variables at one or more points of interest during the processing of request R.

[0034] Trace-based debugging innovations help overcome technical challenges that traditional methods cannot solve. For example, many traditional debuggers and debugging methods allow developers to set halt breakpoints to get information about variable values. A halt breakpoint is an instruction that pauses execution, so that the developer has time to examine the memory contents at a given point in the process and consider possible explanations for what is observed. However, in a production environment, a halt breakpoint may pause the processing of a large number of requests, which is undesirable. Even if only a single thread is paused, it may lead to unwanted request abandonment and produce unforeseen side effects that hinder debugging, or degrade performance, or both.

[0035] Some familiar debugging methods involve adding print statements at specific points in the code to print the values of specific variables, or adding other code, for example, to test the values of variables to see if they are what the developer expects at that point in the code. However, these methods may require recompiling and redeploying the code, which is not desirable in a production environment, especially if the recompiling and redeploying are to be done multiple times as part of an iterative debugging process to find and fix a single bug. Additionally, the developer may be required to identify bugs in code for which they do not have the source and therefore cannot add print statements and recompile.

[0036] Developers can inject operations into the request - handling code at execution time to make a copy of part or all of the memory related to the request. The copy can include a "snapshot" 216 (an in - memory copy of the process that shares a memory - allocation page with the original process via copy - on - write) or a "dump" file 218 (a serialized copy of the process) or both. Some traditional debuggers can read dump files or snapshots and, given appropriate metadata, present the memory contents in a specific format that shows variable values translated from binary into an informative structure that includes variable names and displays variable values based on the corresponding data types of the variables. However, dumping memory to a file takes a significant amount of time, which slows down not only request R but also the processing of all requests in the example scenario. Although making a snapshot is much faster than creating a dump file, it may require many attempts by the developer to find a useful point in the processing to obtain a memory snapshot that reveals a defect, and the snapshot takes up space in RAM. To view the memory at another point in time other than execution time captured in the dump file or snapshot, another memory copy can be created. To view the memory at any point in time in a live process, a live process is used.

[0037] In many modern computing systems, such as Figure 2 the example of the managed - process environment 200 shown, the live process 206 is a managed - code 208 process that, in addition to depending on the operating system 120, also includes a runtime 210. The managed code 208 includes or depends on the runtime 210 for garbage collection or code compilation (i.e., JIT compilation or compilation of intermediate - language code) or both, in addition to depending on the kernel 120. Garbage collection can utilize object - reachability analysis, object reference counting, or other strategies. In contrast, Figure 3 the example of the native - process environment 300 shows a native - code 308 live process 206 that lacks a runtime 210. The native code 308 interfaces directly with the kernel 120 without using a runtime 210.

[0038] The teachings provided herein can be beneficially applied in one or both of two environments 200, 300. As shown, a tool 122, such as a debugger 202 or an execution tracer 204, can inject operations into a live process 206 to make a copy 214 of some or all of the memory items 212 employed during the execution of the process 206. In an online shopping cart scenario, for example, the tracer 204 can inject operations into the request handling code to make a copy of some or all of the memory 112, 212 related to a problematic request R. Instructions 116 for effecting memory copying can be injected by the tool 122 before or during the execution of the code 208, 308. Code injection, also known as "code instrumentation", is a technical process by which the binary representation of executable code is decoded and rewritten at execution time to add additional functionality to the program.

[0039] A process that lacks a runtime can be directly controlled by a debugger by inserting a pause breakpoint. However, a process that depends on a runtime is not directly controllable by the debugger 202 because its runtime is effectively hidden from debugger details 212, such as memory locations, memory contents, and instruction pointers. To show the developer what is in memory during debugging, the debugger sends a message to the runtime asking for the current memory values, and the runtime sends those values to the debugger in a reply message, and the debugger displays in some user interface the values it received in the reply message.

[0040] The runtime 210 also controls the execution of live debug objects. In one example, to set a breakpoint at the intermediate language (IL) instruction at offset 28 in method Foo, a message is sent to the runtime asking it to set a breakpoint at Foo offset 28. Then, a thread within the runtime will receive the message, translate the Foo IL offset 28 to a machine instruction residing at memory address 0x4567123512395, and then write a breakpoint instruction at that location.

[0041] The debugger 202 user interface graphically displays to the user a representation of the debugger's program state. Some examples of program state are a list of threads, the next line of source code to execute on each thread, the call stack for each thread, a set of variables in each frame of the call stack, the values of those variables, and so on.

[0042] In some implementations, the runtime translation portion of debugger 202 is responsible for translating between low-level concepts such as memory cells and registers and runtime abstractions. Examples of runtime abstractions include a list of threads, one or more call stacks for each thread, and the IL instructions to be executed next. Note that the call stack at the abstracted runtime level is not necessarily the same as the call stack at the abstracted source code level; for example, the call stack of a virtual machine does not match the virtual call stack of the IL code being executed in the virtual machine.

[0043] Tracer 204 can create an execution trace 220 of a process. The trace can then be replayed using the emulation of hardware 102. Sometimes, the trace process is written in a high-level language that requires the execution of process 206 by runtime framework 210. The trace itself can be difficult to debug because the trace data reflects a low-level view (e.g., runtime or just-in-time compiled code or both) rather than the high-level language in which the program was written. Some tracing techniques do not provide the high-level view of the process that developer 104 might prefer. Most high-level runtimes require the runtime itself to provide information about the programs running within its framework. Thus, conventional debugging may require the process to execute within the runtime, which is not an option when debugging a trace rather than a live process.

[0044] Like any other process, the runtime can be traced. However, debugging software other than the runtime is more common, and unless otherwise stated, it is assumed here that the tracing process can exclude some or all of the code that is part of the runtime itself. Trace file 420 only traces the execution of processes that are dependent on the runtime and does not trace the runtime itself. Trace file 420 does not fully support reading the values of runtime management objects from the trace file via conventional debugging methods. Without an executing runtime for the debugger, there is no complete association of memory locations with objects and other variables to make the memory values exposed by the trace meaningful. To control the execution of a live process that is dependent on the runtime executing code, the debugger can send a message requesting an operation such as "step" or "run" to the runtime, and the runtime then executes that operation on behalf of the debugger. This functionality does not apply to trace files that do not have a currently executing runtime.

[0045] In terms of the runtime not being available, dump file 218 and snapshot 216 are similar to a trace. The runtime can be present in a dump or snapshot or trace, but it is not executing and thus cannot be invoked.

[0046] Nonetheless, the trace file 420 can be part of a debugging environment. Some trace-based debugging tools extend the power of debugging such that the debugger can read the memory 112 from the trace file at multiple points in the execution time chosen by the developer. One approach is to insert a data access layer between the trace and the high-level language debugger. The data access layer understands the runtime data structures. This allows for the inspection of high-level procedures.

[0047] In some cases, the developer can use a "time travel" debugger to control execution replay to run forward or backward in execution time when replaying the recorded trace 220, thereby leveraging the debugger's ability to present memory in a useful high-level (e.g., named and data type-based) variable representation, not only for previous snapshots but now also for successive segments of the execution time recorded during code execution. Then, the developer can inspect the memory values captured in the trace at multiple points in the high-level representation based on the low-level data recorded in the trace file. Of course, memory inspection requires reading memory cell values from the trace, or other values, and somehow obtaining useful information about the memory values sought during replay. Heuristics can help the debugger and other tools obtain useful information about the memory values even when the trace does not explicitly state the value at the desired point in execution time.

[0048] When using the data access layer as a data source for debugging with a process dump or snapshot, information about the high-level program state within the runtime can be viewed. Appropriately conditioned, the debugger 202 can apply the runtime (high-level) view of the process trace that has been recorded as machine-level operations. For the purposes of this application only, "machine-level" operations are operations specified at the assembly language or intermediate language or lower levels.

[0049] In some cases, the trace 220 records machine-level process activities, e.g., in terms of register activities and reads and writes at specific memory addresses, which are specified in binary or hexadecimal rather than by identifiers in the source code compiled to create the process. Some traces 220 can be replayed using emulation of the hardware 102.

[0050] The tracing overhead includes processor cycles and storage space (in RAM, on disk, or both). Some of the tracing overhead is caused by portions of the recording (copy 214) process 206 that are not directly relevant to the problem to be debugged. The teachings herein discuss tools and techniques for selectively choosing segments of process 206 to be recorded. A "segment" is a part of a process and can include one or more routines, threads, libraries, or other appropriate subsets of the process in the form of its underlying code or memory activity. Segment selection reduces the processing time and memory overhead of the trace, as well as the disk consumption of the trace 220. In production environments and many other environments, the process execution trace 220 is often large (hundreds or thousands of megabytes), and the trace causes a significant amount of processor overhead when tracing is enabled (execution is slowed down by a factor of ten or more). The solution presented herein helps reduce file size, memory pressure, and processor load by choosing during process execution which parts of the software should be traced.

[0051] Some may view some of the embodiments described herein in a broader context. For example, concepts such as disable, distance, enable, size, and tracing may be considered relevant to a particular embodiment. However, exclusive rights are not sought for abstract concepts in that broad context; they are not. Rather, the present disclosure is concerned with providing suitable specific embodiments whose technical effects fully or partially solve specific technical problems, such as identifying tradeoffs, pursuing a selection balance among the performance of the program being traced, the slowdown of trace execution, trace relevance, and trace size, and assisting in the implementation mechanism for pursuing the selected balance. Other media, systems, and methods involving disable, distance, enable, size, or tracing are not within the current scope. Thus, when the present disclosure is properly understood, issues of obscurity, mere abstraction, lack of technical features, and attendant proof are also avoided.

[0052] Technical features

[0053] The technical features of the embodiments described herein will be apparent to those of ordinary skill in the art and will also be apparent to various interested readers in a variety of ways. Some embodiments are directed to technical activities that are rooted in computing technology and improve the functionality of computing systems. For example, some embodiments help debug systems by making debug traces more effective. When tracing the execution of these systems, some embodiments mitigate the performance degradation in the system.

[0054] For example, some embodiments help reduce the number of irrelevant or uninteresting execution traces that developers must sift through to find defects. By reducing the storage requirements for the trace file without omitting relevant trace data, some embodiments make effective tracing feasible even when it would otherwise be infeasible due to limitations in available storage.

[0055] Moreover, by running the program being traced at full speed while it performs non-debugged operations, some embodiments give the developer more time to perform debug analysis within a given duty cycle. When the tool is tracing operations that are not of interest (such as garbage collection, JIT compilation, or standard library routines), the developer waits less time, as these operations are part of the execution but are less likely to contain the sought-after defects. The time saved by reducing irrelevant tracing can be used for code replay, inspection of variables, and other debug analysis.

[0056] Some embodiments include technical components such as computing hardware that interacts with software in a manner that goes beyond typical interactions within a general-purpose computer. For example, in addition to general interactions such as general memory allocation, general memory reads and writes, general instruction execution, and certain I / O, some embodiments described herein also use a trace-disable distance variable and one or more associated thresholds to implement selective trace algorithm steps, as disclosed herein.

[0057] Technical effects provided by some embodiments include more efficient use of debug time by the developer, reduced trace file size, and reduced slowdown of the traced program execution.

[0058] Some embodiments include technical adaptations such as trace-disable distance variables, routines, and other mechanisms that modify or inspect the trace-disable distance variable. Some adaptations include trace-selection adjustment conditions. These conditions achieve a balance between the computational cost of enabling or disabling tracing and the computational and storage costs of trace code that is not helpful for a particular debug effort.

[0059] From the description provided, other advantages of the technical features based on the teachings will also be apparent to those skilled in the art.

[0060] Acronyms and Abbreviations

[0061] The following defines some acronyms and abbreviations. Other abbreviations may be defined elsewhere in this document or may be understood by those skilled in the art without any definition.

[0062] ALU: Arithmetic and Logic Unit

[0063] API: Application Programming Interface

[0064] BIOS: Basic Input / Output System

[0065] CD: Compact Disc

[0066] CPU: Central Processing Unit

[0067] DV: Distance Variable, as in "trace-disable distance variable"

[0068] DVD: Digital Versatile Disc or Digital Video Disc

[0069] FPGA: Field Programmable Gate Array

[0070] FPU: Floating Point Processing Unit

[0071] GPU: Graphics Processing Unit

[0072] GUI: Graphical User Interface

[0073] ID: Identifier

[0074] IDE: Integrated Development Environment, sometimes called "Interactive Development Environment"

[0075] JIT: Just in Time, as in "JIT compiler" or "JIT compilation"

[0076] OS: Operating System

[0077] RAM: Random Access Memory

[0078] ROM: Read Only Memory

[0079] "==" indicates "equal to", "!=" indicates "not equal to", and "=" indicates "assigned to"; these abbreviations are Figure 10 and 13 Use in

[0080] "()" indicates a routine, for example, "trace-on()" is a routine named "trace-on"; routines can also be referenced by their name without parentheses, for example, Figure 13 The "A", "B", "B1", "C", and "C2" in the example refer to routines.

[0081] Additional terms

[0082] Reference is made herein to exemplary embodiments such as those shown in the accompanying drawings, and specific language is used herein to describe them. However, changes and further modifications of the features shown herein of the present disclosure and additional technical applications of the abstract principles illustrated by the specific embodiments herein that may occur to those skilled in the relevant art and that have the present disclosure should be considered within the scope of the claims.

[0083] The meaning of the terms is clarified in this disclosure, so these clarifications should be carefully noted when reading the claims. Specific examples are given, but those skilled in the relevant art will understand that other examples may also fall within the meaning of the terms used and fall within the scope of one or more claims. The terms here do not necessarily have the same meaning as they are in general use (especially in non-technical use), in the use of a specific industry, or in a specific dictionary or dictionary. Figure numerals can be used with various wordings to help show the breadth of the terms. Omitting a figure numeral from a given text does not necessarily mean that the text does not discuss the content of the figure. The inventor claims and exercises his right to compile his own dictionary. Quoted terms are explicitly defined, but it is also possible to define terms implicitly without using quotation marks. Terms can be explicitly or implicitly defined in the "Detailed Description" and / or elsewhere in the application document.

[0084] As used herein, a "computer system" may include, for example, one or more servers, motherboards, processing nodes, laptops, tablets, personal computers (portable or non-portable), personal digital assistants, smart phones, smart watches, smart bracelets, cellular or mobile phones, other mobile devices with at least a processor and memory, video game systems, augmented reality systems, holographic projection systems, televisions, wearable computing systems, Internet of Things nodes, and / or other devices that provide one or more processors controlled at least in part by instructions. Instructions may take the form of firmware or other software in memory and / or dedicated circuit systems.

[0085] A "multithreaded" computer system is one that supports multiple threads of execution. The term "thread" should be understood to include any code that can be or is scheduled (and possibly synchronized), and may also be referred to as, for example, a "procedure" or a "coroutine." Threads may run in parallel, sequentially, or in a combination of parallel execution (e.g., multiprocessing) and sequential execution (e.g., time-sliced).

[0086] A "processor" is a thread processing unit, such as a core in a simultaneous multithreading implementation. A processor comprises hardware. A given chip may house one or more processors. Processors may be general purpose, or may be customized for specific uses, such as vector processing, graphics processing, signal processing, floating point arithmetic processing, encryption, I / O processing, etc.

[0087] The "kernel" includes the operating system, virtual machine monitor, virtual machines, BIOS code, and similar hardware interface software.

[0088] "Code" means processor instructions, data (including constants, variables, and data structures), or both instructions and data. "Code" and "software" are used interchangeably herein. Executable code, interpreted code, and firmware are some examples of code. Code that is interpreted or compiled for execution is called "source code".

[0089] "Program" is used herein in a broad sense to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written and / or automatically generated by a programmer (also known as a developer).

[0090] "Service" means a consumable program provided in a cloud computing environment or other network environment.

[0091] "Execution time point" means a specific point in the execution of a processing unit or thread, especially as related to tracing the execution. References herein to "specific execution time" or "execution time t", etc., are references to execution time points. For example, an execution time point can be implemented as a timecode variable or value, or as a relative position in another record of a traced or executed activity. Execution time point ta being "earlier than" or "later than" execution time point tb indicates that the relative order of the two execution time points is determined. Similarly, a "younger" execution time point is a later execution time point than an "older" execution time point.

[0092] The information regarding the order of trace events in a trace may be incomplete. Thus, a trace can have enough information to establish that event A is earlier than event B, or to establish that event D is later than event C. However, in terms of considering the trace, the relative order of events may also be partially or completely undetermined. A trace can show that event E is not after event F, but this does not necessarily mean that E is before F; similarly, a trace can show that event K is not before event J, without the trace also showing that K is after J. A trace may also lack enough information to establish any order of two specific events relative to each other.

[0093] "Timecode" represents a monotonically changing value that can be used to impose an order on at least some events in an execution trace. It is expected that a timecode is typically a monotonically increasing value, but a timecode can also be implemented as a monotonically decreasing value. Some examples of timecodes include instruction counters, clock times (also known as clock ticks), and completely artificial (not register- or instruction-based) monotonically increasing values. Depending on the trace, all or some or none of the trace events may have corresponding associated timecodes. When timecodes exist, they can be unique, or they can be merely monotonic due to some timecode values repeating.

[0094] "Memory cell" refers to an addressable cell of a memory. Some examples include bytes or words in RAM or ROM, processor registers, cache lines, and other addressable memory cells.

[0095] "Emulator" performs "emulation" which provides the same functionality as the original hardware but using a different implementation or different hardware or both. An example is a CPU emulator which acts like a CPU and can be used to execute code just like the original CPU hardware but with a different implementation than the original CPU. For example, the emulator can run on completely different physical hardware.

[0096] "Record" and "trace" are used interchangeably herein to refer to the act of creating or extending a trace.

[0097] Unless otherwise specified, as used herein, "comprising" permits additional elements (i.e., comprising means including).

[0098] "Optimize" means to improve, not necessarily to perfection. For example, a program or algorithm that has been optimized can be further improved.

[0099] For example, "process" is sometimes used herein as a term in the field of computing science and in a technical sense encompasses resource users, i.e., coroutines, threads, tasks, interrupt handlers, application processes, kernel processes, procedures, and object methods. "Process" is also used herein as a term in patent law, e.g., when describing process claims as opposed to system claims or claims for an article of manufacture (a configured storage medium). Similarly, "method" is sometimes used herein as a technical term in the field of computer science (a "routine") and also as a term in the field of patent law ("process"). Those skilled in the art will understand the meaning intended in a particular context and will also understand that a given claimed process or method (in the sense of patent law) can sometimes be implemented using one or more processes or methods (in the sense of computing science).

[0100] As opposed to no automation, "automatically" means utilizing automation (e.g., general-purpose computing hardware configured by software for the particular operations and technical effects discussed herein). In particular, steps performed "automatically" can be initiated by a person or guided interactively by a person, but they are not performed manually on paper or in a person's mind. The automatic steps are performed by a machine in order to obtain one or more technical effects that could not be achieved without using the technical interaction so provided.

[0101] Those skilled in the art understand that the technical effect is the presumed purpose of the technical embodiment. For example, in an embodiment involving calculations, and the fact that some calculations can also be performed without technical components (e.g., by paper and pencil, or even as a mental step) does not eliminate the existence of the technical effect or change the specific and technical nature of the embodiment. Operations such as enabling tracking, copying tracking data, and disabling tracking should be understood herein to require and provide a speed and accuracy that cannot be achieved by human mental steps, in addition to their inherent digital nature (the human mind cannot directly interact with the execution process or the tracking file). This has been well understood by those skilled in the art, but others may sometimes benefit from the statement or reminder of the fact. Unless otherwise stated, the embodiments are assumed to be capable of operating on a large scale in a production environment or in a test laboratory of a production environment, as opposed to a mere thought experiment.

[0102] "Computationally" also means that a computing device (at least a processor plus memory) is being used, and excludes results obtained by mere human thought or mere human action. For example, as understood herein, performing arithmetic with paper and pencil is not computationally performing arithmetic. The computational results are faster, broader, deeper, more accurate, more consistent, more comprehensive, and / or provide technical effects that go beyond the scope of human performance. A "computational step" is a step performed computationally. Neither "automatically" nor "computationally" necessarily means "immediately". "Computationally" and "automatically" are used interchangeably herein.

[0103] "Proactively" means without a direct request from the user. In fact, the user may not even be aware that the proactive steps of the embodiment are possible until the results of the steps have been presented to the user. Unless otherwise stated, any computational and / or automatic steps described herein may also be performed proactively.

[0104] Throughout the document, the optional "(s)" is used to indicate the presence of one or more of the indicated features. For example, "(s) processor" means "one or more processors" or equivalently "at least one processor".

[0105] For the purposes of U.S. law and practice, the use of the term "step" herein in the claims or elsewhere is not intended to invoke means-plus-function, step-plus-function, or 35 U.S.C. § 112, ¶ 6 / § 112(f) claim construction. Any presumption to that effect is hereby expressly rebutted.

[0106] For purposes of United States law and practice, unless a claim uses the phrase "means for", it is not intended to invoke means-plus-function interpretation. Claim language that is intended to be interpreted as means-plus-function language (if any) will expressly recite that intent by using the phrase "means for". When means-plus-function interpretation is employed, whether by use of "means for" and / or by judicial construction of claim language, the means recited in the specification for a given noun or given verb should be understood as linked to the claim language and hereby linked in any of the following ways: appearing within the same box in a block diagram of the drawings, being denoted by the same or a similar name, being denoted by the same reference numeral. For example, if a claim limitation recites "zac widget" and that claim limitation is subject to means-plus-function interpretation, then all structures identified anywhere in the specification in any block, paragraph, or example as "zac widget" and / or tied together by any reference numeral assigned to the zac widget should be considered part of the structure identified in the application of the zac widget and contribute to defining the set of equivalents of the zac widget structure.

[0107] Throughout the document, unless otherwise expressly stated, any reference to a step in a process is assumed that the step can be performed directly by a party of interest, and / or indirectly by a party through an intervening mechanism and / or intervening entity and still fall within the scope of that step. That is, the step need not be performed directly by the relevant party unless expressly stated to be performed directly. For example, steps involving actions of a party of interest regarding a destination or other subject matter (such as associate, configure, confirm, connect, control, copy, decrement, designate, disable, embed, enable, enter, execute, exit, install, invoke, measure, move, record, run, satisfy, select, set, track, adjust, use (and associated, associated with, configured, configured to, etc.)) can involve intervening actions of another party such as forward, copy, upload, download, encode, decode, compress, decompress, encrypt, decrypt, authenticate, invoke, etc., but should still be understood to be performed directly by the party of interest.

[0108] Whenever data or instructions are referred to, it should be understood that, for example, these items configure a computer-readable memory and / or a computer-readable storage medium, thereby transforming it into a specific article, as opposed to simply existing on paper, in one's mind, being merely energy, or being merely a signal propagating on a wire. For the purposes of United States patent protection, and as interpreted by the United States Patent and Trademark Office (USPTO) in the re Nuijten case, a memory or other computer-readable storage medium is not a propagated signal, a carrier wave, or merely energy outside the scope of patentable subject matter. In the United States, no claim can cover a signal per se, and any claim interpretation to the contrary is unreasonable. Unless otherwise expressly stated in a claim granted outside the United States, a claim does not cover a signal per se.

[0109] Furthermore, although there are apparently contrary provisions elsewhere in this document, it should be understood that there is a clear distinction between (a) a computer-readable storage medium and a computer-readable memory and (b) a transmission medium (also referred to as a signal medium or merely energy). A transmission medium is a propagated signal or carrier wave, a computer-readable medium, or merely energy. In contrast, a computer-readable storage medium and a computer-readable memory are not propagated signal or carrier wave computer-readable media. Unless otherwise expressly stated in a claim, "computer-readable medium" refers to a computer-readable storage medium, not a propagated signal per se, nor merely energy.

[0110] "Embodiments" herein are examples. The term "embodiment" cannot be interchanged with "the present invention". Embodiments can freely share or borrow aspects to create other embodiments (so long as the result is operable), even if the resulting combination of aspects is not explicitly described herein. It is not necessary for every permissive combination to be explicitly described for those skilled in the art, which is contrary to the policy of admitting that a patent specification is written for those skilled in the art. Both formal combinatorial calculations and informal intuition regarding the number of possible combinations resulting from even a small number of combinable features will show that there are a large number of aspect combinations for the aspects described herein. Thus, requiring an explicit recitation of every combination runs counter to the policy of requiring a concise patent specification and enabling the reader to have knowledge of the relevant technical field.

[0111] List of Reference Numerals

[0112] The following list is provided for convenience and to support the drawings and as part of the specification text, which describes the innovation by reference to multiple items. Nevertheless, items not listed here can still be part of a given embodiment. To make the text clearer and more readable, some (but not all) reference items are referred to by a given reference numeral near the text. The same reference numeral can be used to refer to different examples or different instances of a given item. The list of reference numerals is:

[0113] 100: Operating environment, also known as computing environment

[0114] 102: Computer system, also known as computational system or computing system

[0115] 104: User

[0116] 106: Peripheral device

[0117] 108: Generally a network

[0118] 110: Processor

[0119] 112: Computer-readable storage medium, such as RAM, hard disk

[0120] 114: Configured to be a removable computer-readable storage medium

[0121] 116: Instructions executable by a processor; can be on a removable medium or in other memories (volatile or non-volatile or both)

[0122] 118: Data

[0123] 120: (Multiple) kernels, e.g., (multiple) operating systems, BIOS, device drivers

[0124] 122: Tools, such as antivirus software, profiler, debugger, execution tracer, editor, compiler, interpreter, security penetration tester, fuzzer, etc.; can be adapted to use the selective tracing control taught herein

[0125] 124: Applications, such as word processors, web browsers, spreadsheets

[0126] 126: Display screen

[0127] 128: Computing hardware, not otherwise associated with reference numerals 106, 108, 110, 112, 114

[0128] 200: Environment in which managed code is traced, or traced and debugged

[0129] 202: Debugger

[0130] 204: Execution tracer

[0131] 206: Real-time debugger program or process

[0132] 208: Managed code

[0133] 210: Runtime

[0134] 212: Memory item, e.g., application or system data structure

[0135] 214: Copies of some or all memory items

[0136] 216: Memory snapshot; may include additional information such as indexes or metadata

[0137] 218: Dump file, also known as memory dump; may include additional information such as indexes or metadata

[0138] 220: Execution trace; although Figure 4 the dashed lines in show that individual items may be included or omitted in a given trace, but it is assumed herein that the trace is not empty and thus the box for generally traced data 454 is shown as a solid line.

[0139] 300: Environment in which native code is traced, or traced or debugged

[0140] 420: Trace file, containing execution trace data; may include machine-level trace data, i.e., data recording assembly language or intermediate language or lower-level execution activities

[0141] 422: Trace data that is precisely in place in the trace

[0142] 424: Time code, in a trace, identifying a specific execution time point in the execution of the traced code; may be linked to or embedded in other data within the trace, e.g., in trace data that explicitly states the execution time point associated with a stated operation at a stated memory address involving a stated data value; the time code may be implemented as, for example, clock ticks or an instruction counter; for each recorded operation, some traces may contain a unique time code, but in some trace data, the time code may also be repeated or omitted

[0143] 428: Gaps in the time code in a trace, used to explicitly or implicitly indicate execution time points during which no trace is being performed (e.g., the range when tracing is disabled for a thread or processing unit). This can include any gap where adjacent time codes differ by more than a default value or a specified increment (usually 1), e.g., the gap in the time code sequence 2, 3, 4, 300, 301, 302 is between 4 and 300, and the gap in the time code sequence 250, 500, 750, 1000, 2000, 2250, 2500 is between 1000 and 2000.

[0144] 430: Index into the data in a trace file, e.g., a reverse lookup data structure for quickly identifying trace attributes, memory lifetime index information, and other searchable lists of positions in the trace data that may be of particular interest

[0145] 432: Key frames in the trace data; for example, they can exist at fixed intervals in the trace data to allow a replay to jump more quickly to (or near) a key frame during trace replay

[0146] 434: The code being executed, such as the opcodes and parameters of the machine-level code of a debug object being executed by a processor while the debug object is running and being traced

[0147] 436: Stack activity, which occurs while a debug object is running and being traced; for example, stack growth, stack shrinkage, and the execution time points at which the activity occurs

[0148] 438: Data flow; can correspond to a single thread or a group of threads, can correspond to a processor unit (e.g., a processor core); can correspond to all cores in a given processor socket; can be annotated with metadata to assist in replay

[0149] 440: Processor core activity, which occurs while a debug object is running and being traced; for example, the opcodes and parameters of the instructions executed by the core

[0150] 442: Processor socket activity, which occurs while a debug object is running and being traced; for example, the opcodes and parameters of the instructions executed by any core located in a given processor socket

[0151] 444: Thread activity, which occurs while a debug object is running and being traced; for example, the instructions executed while a thread is running, the memory unit accesses made while a thread is running, associated metadata (such as thread ID and time code)

[0152] 446: Register activity, which occurs while a debug object is running and being traced; for example, at what time code what value is read from which register, and at what time code what value is written to which register

[0153] 448: Memory address

[0154] 450: Instruction opcode

[0155] 452: Data value

[0156] 454: Generally trace data

[0157] 456: Tuple, i.e., two or more items of trace data associated in a trace, representing the same operation during trace execution; for example, a memory read operation or a memory write operation can be recorded as a tuple on a single line in the trace, the tuple containing or otherwise associating the opcode (e.g., read or write), the address (e.g., RAM address or register ID), and the data value that has been read or written

[0158] 458: Trace entry

[0159] 502: Memory cell, such as a byte or word in RAM or ROM, a processor register, a cache line, or other addressable memory cell

[0160] 504: Stack, e.g., a portion of memory into which status information is pushed when a routine is entered and then popped as control returns from the routine to the code that called the routine; typically distinguished from heap memory

[0161] 506: Stack base address, which defines the starting point from which the stack is allocated in contiguous memory; the stack is assumed to grow in a known direction with the allocation of stack memory in the system, which can be in the upward direction (i.e., the address increases as items are pushed onto the stack) in a given system, but in another system, it can also be downward (i.e., the address decreases as items are pushed onto the stack); the term "growing" here refers to the direction in which the stack grows on the system under discussion, while "shrinking" refers to the opposite direction

[0162] 508: Stack frame, i.e., an allocation record that is allocated on the stack when a routine is called; typically contains a return address that identifies the location in the code where execution will resume when the routine returns; may also contain the values passed as parameters to the routine when it was called, or the addresses of such parameter values

[0163] 510: Heap memory, which is allocated and freed as objects are constructed and released; in some cases, the heap can perform automatic garbage collection, which identifies and marks as available memory the objects that are no longer accessible during the live execution of the process; in other cases, memory allocated from the heap requires a separate explicit call to free the allocated memory.

[0164] 512: Object

[0165] 514: Cache memory; e.g., can be in the RAM working memory or on the processor chip

[0166] 516: Registers in the processor core

[0167] 518: Object property; a named value that is a component of an object; can be a function, in which case the property is usually called a method; also refers to the function that implements the object property; a function is a routine that returns a value

[0168] 520: ROM (Read-Only Memory); typically non-volatile

[0169] 522: Non-volatile memory other than on-board ROM, such as removable flash memory, disk or optical disk storage, magnetic tape storage, etc.

[0170] 524: RAM (Random Access Memory); usually volatile

[0171] 526: Local memory, e.g., memory that is local to the declared or implicit context (local to a routine during the execution of the routine and then released, or local to a thread)

[0172] 528: Global memory, e.g., memory that is global to the declared or implicit context (such as global to a set of multiple routines during the execution of any of them, or global to a set of threads)

[0173] 530: Characteristics of memory that increase or decrease the likelihood that an entity external to the thread will change the value stored in the memory cell, e.g., whether the memory cell is write-protected relative to other threads, whether it is in shared memory (such as memory that is global to multiple threads)

[0174] 602: Thread

[0175] 604: Thread ID

[0176] 606: Thread state, e.g., created, runnable, running, suspended, blocked, terminated

[0177] 608: Thread code, i.e., the code that is executed or can be executed when the thread runs

[0178] 610: Thread memory, e.g., memory that is local to the thread, or memory that is global to the thread and is accessed by the thread during thread execution

[0179] 700: Trace controller, also known as tracing controller

[0180] 702: Portion of the traced process that is designated to be traced

[0181] 704: Criteria for designating portions to be traced or not traced

[0182] 706: Portion of the traced process that is not designated to be traced, including portions explicitly designated not to be traced and portions implicitly designated not to be traced (because they are not explicitly designated to be traced)

[0183] 708: Library, containing code other than the user code being debugged, e.g., standard library or libraries for any debugging by different developers

[0184] 710: Compiler, e.g., JIT compiler

[0185] 712: Garbage collector, i.e., code that reclaims memory so that memory operation lines malloc() and free() are not required in the user code source

[0186] 714: Modification to the executable code to control tracing, e.g., calls to trace enablers, calls to trace disablers, calls to set or check trace disable distance variables

[0187] 716: Trace disabler, i.e., a routine whose call stops tracing

[0188] 718: Trace enabler, i.e., a routine whose call starts tracing

[0189] 720: Trace disable distance variable

[0190] 722: Stop tracing value; when the trace disable distance variable reaches this value, the trace disabler will be called; it is expected that this stop tracing value is typically zero

[0191] 724: Trace disable distance variable modifier, e.g., an interrupt or hardware processor mode or circuit that automatically decrements a specified register (serving as the distance variable) each time a program instruction is executed; although the examples herein discuss decrementing the distance variable until it reaches zero, those skilled in the art will recognize that functionally equivalent implementations can increment a negative distance variable until it reaches zero, or can increment or decrement the distance variable until it reaches some other stop tracing value at which the trace controller will trigger a call to the trace disabler

[0192] 726: High count threshold for the value in the distance variable, which can be used to indicate in a newly entered code unit that it is being traced

[0193] 728: Low count threshold for the value in the distance variable, which can be used to maintain the tracing state for a long time after exiting a code unit that has been traced for a sufficient long time, to encounter an indication in a newly entered code unit that is also being traced, if such an indication exists, otherwise, unless control passes (backward or downward) to code specified to be traced, tracing will be disabled

[0194] 730: Tracing state, i.e., tracing is in an enabled state or tracing is in a disabled state

[0195] 802: A variant of system 102 that lacks or does not utilize the distance variable aspect of trace controller 700, which limits the invocation of the trace disablers and trace enablers taught herein; instead, this variant explicitly invokes the trace enabler upon entry into each section of code to be traced and explicitly invokes the trace disabler upon exit from each section of code to be traced

[0196] 804: Computational cost, e.g., measured in processor cycles, instruction count, or time elapsed on the system clock, or in terms of the number of times trace 220 enters 458

[0197] 806: Computational cost that is the cost of tracing at least a specified portion of code using the distance variable aspect of trace controller 700, which limits the invocation of the trace disablers and trace enablers taught herein

[0198] 808: Computational cost that is the cost of tracing at least a specified portion of code without using the distance variable aspect of trace controller 700, which limits the invocation of the trace disablers and trace enablers taught herein

[0199] 902: The set-N() routine in some implementations of the trace controller, used to set the value of local variable N

[0200] 904: local-N, the parameter of the set-N() routine

[0201] 906: The get-N() routine in some implementations of the trace controller, used to obtain the value of local variable N

[0202] 908: Local variable N in some implementations of the trace controller

[0203] 910: The set-DV() routine in some implementations of the trace controller, used to set the value of the trace disable distance variable

[0204] 912: tracing-max, the parameter for the set-DV() routine

[0205] 914: The get-DV() routine in some implementations of the trace controller, used to obtain the value of the trace disable distance variable

[0206] 916: The try-to-trace() routine in some implementations of the trace controller, used to enable tracing if it has not already been enabled

[0207] 1000: Trace state diagram, showing the trace control behavior in some implementations

[0208] 1002: Tracking enabled state, i.e., the state in which tracking is enabled

[0209] 1004: Tracking disabled state, i.e., the state in which tracking is disabled

[0210] 1006: Instruction to execute the tracked process; can also refer to a larger part of the process, or the entire process

[0211] 1008: Call the try-to-trace() routine; 1008 also specifies the execution of the try-to-trace() routine

[0212] 1010: Call the tracking enabler; also specifies the execution of the tracking enabler

[0213] 1012: Record execution information into the trace

[0214] 1014: Decrease the tracking disable distance variable, or otherwise move the value of the distance variable closer to the stop tracking value

[0215] 1016: Call the tracking disabler; also specifies the execution of the tracking disabler

[0216] 1100: Code unit

[0217] 1102: Function

[0218] 1104: Routine

[0219] 1106: Coroutine

[0220] 1108: Exception handler, also known as exception catcher

[0221] 1110: Interrupt handler

[0222] 1112: Other code units, such as blocks, loop bodies, collections of various code units

[0223] 1114: Virtual method

[0224] 1116: Implementation of virtual method

[0225] 1118: Callback

[0226] 1120: Count ensuring code, including code for ensuring that the distance variable meets or exceeds a high count threshold, or code for ensuring that the distance variable does not exceed a low count threshold

[0227] 1122: Library

[0228] 1124: Module, such as file, component, package

[0229] 1200: Aspects of code related to using a trace-disable distance variable to control which parts of a process are logged to a trace

[0230] 1202: Entry point into a routine or other code unit

[0231] 1204: Exit point from a routine or other code unit

[0232] 1206: Caller of a routine

[0233] 1208: Current execution point within a routine or other code unit

[0234] 1210: Adjustment conditions for adjusting trade - offs when using a trace-disable distance variable to control which parts of a process are logged to a trace, e.g., adjusting how much uninteresting code to trace and how many processor cycles to spend disabling and re - enabling tracing; also refers to using such conditions to adjust trace thresholds 726, 728

[0235] 1216: Value of the trace-invalid distance variable; however, as with developers, for convenience, the value of the variable is sometimes indicated here by simply referring to the variable rather than explicitly referring to the value of the variable, e.g., referring to variable N refers to both the variable (the allocated and identified storage) and the value held in that variable, and the person skilled in the art will understand which reference is meant from the context

[0236] 1218: Information about the cost of executable code, such as the average length (number of instructions / number of processor cycles) of routines in the executable code, the distribution of routine sizes, and other information described herein

[0237] 1220: Information about the computational cost of turning tracing on or off, e.g., the length (number of instructions / number of processor cycles) of a trace - enabler or trace - disabler

[0238] 1300: Computational cost comparison examples

[0239] 1400: Method of configuring a system to control tracing by using a trace - disable distance variable

[0240] 1402: Configure a system to control tracing by using a trace - disable distance variable

[0241] 1404: Control tracing by using a trace - disable distance variable

[0242] 1406: Use a trace - disable distance variable

[0243] 1408: Embed count - ensuring code in a process

[0244] 1410: High - count ensuring code

[0245] 1412: Location in the code

[0246] 1414: Low count to ensure code

[0247] 1416: Associate distance variable modifier with a procedure or its code

[0248] 1418: Instruction counter

[0249] 1420: Connect an execution tracer to a procedure or its code

[0250] 1422: Install a callback to pass control to the execution tracer

[0251] 1424: Configure the trace controller

[0252] 1426: Disable tracing, for example by involving a trace disabler

[0253] 1428: Reach zero or other stop-tracing value due to a change in the value of the distance variable (e.g., due to decrement of the distance variable)

[0254] 1430: Enable tracing, for example by involving a trace enabler

[0255] 1500: Method for controlling tracing by using a trace-disable distance variable

[0256] 1502: Set the distance variable to a relatively high value

[0257] 1504: Set the distance variable to a relatively low non-zero value

[0258] 1600: Flowchart

[0259] 1602: Designate a code unit as part of a procedure (e.g., program) to be traced

[0260] 1604: Designate a code unit as part of a procedure (e.g., program) that will not be traced, or as part not required (optionally included) in the tracing

[0261] 1606: Confirm that the trace-disable distance variable is not at the stop-tracing value, e.g., the distance variable is non-zero

[0262] 1608: Measure computational cost, for example, in processor cycle 1610, instruction count 1612, or system clock elapsed time 1614

[0263] 1616: Run (also known as execute) the managed code

[0264] 1618: Run (also known as execute) the native code

[0265] 1620: As part of trace control, use set-N(), get-N(), local variable N, or equivalent but differently named functions

[0266] 1622: Use try-to-trace(), or equivalent but differently named functions as part of trace control

[0267] 1624: Use logical infinity as a relatively high value in the trace disable distance variable

[0268] 1626: Logical infinity, i.e., a value LI that satisfies at least the following conditions: LI minus any other integer value equals LI, and LI is further from zero than any other integer value

[0269] 1628: Use information 1218 about the size of the executable routine when controlling tracing

[0270] 1630: Select a low count threshold

[0271] 1632: Select a high count threshold

[0272] 1634: Satisfy adjustment condition 1210

[0273] 1636: Sample the execution of a process into tracing

[0274] 1638: Call a routine

[0275] 1640: Enter a routine

[0276] 1642: Exit a routine

[0277] 1646: Compile code

[0278] 1648: Redirect a function call

[0279] 1650: Identify a routine or other code unit as being designated for tracing

[0280] Operating environment

[0281] Reference Figure 1 , The operating environment 100 for the embodiments includes at least one computer system 102. The computer system 102 may or may not be a multiprocessor computer system. The operating environment may include one or more machines in a given computer system, and these machines may be clustered in the cloud, client-server networked, and / or peer-to-peer networked. An individual machine is a computer system, and a group of cooperating machines is also a computer system. A given computer system 102 may be configured for, e.g., end users with applications, for administrators, as a server, as a distributed processing node, and / or otherwise.

[0282] The human user 104 can interact with the computer system 102 by using a display, keyboard, and other peripheral devices 106 via typed text, touch, voice, movement, computer vision, gestures, and / or other forms of I / O. The screen 126 can be a removable peripheral device 106 or can be an integral part of the system 102. The user interface can support the interaction between the embodiments and one or more human users. The user interface can include a command-line interface, a graphical user interface (GUI), a natural user interface (NUI), a voice command interface, and / or other user interface (UI) presentations, which can be presented as different options or can be integrated.

[0283] System administrators, network administrators, software developers, engineers, and end users are all specific types of users 104. Automated agents, scripts, playback software, etc. representing one or more persons can also be users 104. Storage devices and / or network devices can be considered peripheral devices in some embodiments and part of the system 102 in other embodiments, depending on their separability from the processor 110. For example, Figure 1 Other computer systems not shown can interact with the computer system 102 or with another system embodiment in a technical manner using one or more connections to the network 108 via a network interface device.

[0284] Each computer system 102 includes at least one processor 110. Like other suitable systems, the computer system 102 also includes one or more computer-readable storage media 112. The media 112 can be of different physical types. The media 112 can be volatile memory, non-volatile memory, fixed-in-place media, removable media, magnetic media, optical media, solid-state media, and / or other types of physically persistent storage media (as opposed to merely propagating media signals). Specifically, when inserted or otherwise installed, the configured media 114 (such as a portable (i.e., external) hard drive, CD, DVD, storage stick, or other removable non-volatile storage media) can functionally become a technical part of the computer system, making its content accessible for interaction with and use by the processor 110. The removable configured media 114 is an example of the computer-readable storage media 112. Some other examples of the computer-readable storage media 112 include built-in RAM, ROM, hard drives, and other memory storage devices that are not readily removable by the user 104. For compliance with current U.S. patent requirements, under any pending or approved claims in the United States, a computer-readable medium, a computer-readable storage medium, or a computer-readable memory is not a signal itself or just energy.

[0285] For example, the medium 114 is configured with binary instructions 116 executable by the processor 110; "executable" is used herein in a broad sense to include, for example, machine code, interpretable code, byte code, and / or code running on a virtual machine. The medium 114 is also configured with data 118, which is created, modified, referenced, and / or otherwise used for a technical effect by the execution of the instructions 116. The instructions 116 and the data 118 configure the memory or other storage medium 114 in which they reside; when the memory or other computer-readable storage medium is a functional part of a given computer system, the instructions 116 and the data 118 also configure the computer system. In some embodiments, a portion of the data 118 represents real-world items, such as product characteristics, inventory, physical measurements, settings, images, readings, targets, volumes, and so on. Such data may also be transformed by backup, restore, commit, abort, reformatting, and / or other technical operations.

[0286] Although embodiments may be described as implemented by software instructions executed by one or more processors in a computing device (e.g., a general-purpose computer, a server, or a cluster), such a description does not represent an exhaustive list of all possible embodiments. Those skilled in the art will understand that the same or similar functionality may generally also be implemented, in whole or in part, directly in hardware logic to provide the same or similar technical effect. Alternatively, or in addition to software implementation, the technical functionality described herein may be performed, at least in part, by one or more hardware logic components. For example, and without excluding other implementations, embodiments may include hardware logic components 110, 128, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-chip components (SOCs), complex programmable logic devices (CPLDs), and similar components. For example, components of an embodiment may be grouped into interactive functional modules based on their inputs, outputs, and / or their technical effects.

[0287] In addition to the processor 110 (e.g., CPU, ALU, FPU, and / or GPU), the memory / storage medium 112, and the display 126, the operating environment may also include other hardware 128, such as, for example, batteries, buses, power supplies, wired and wireless network interface cards. The terms "screen" and "display" may be used interchangeably herein. The display 126 may include one or more touchscreens, a screen responsive to input from a pen or tablet, or a screen for output only. In some embodiments, peripheral devices 106, such as human user I / O devices (screen, keyboard, mouse, tablet, microphone, speaker, motion sensor, etc.), will communicate operably with one or more processors 110 and the memory. A software process may be the user 104.

[0288] In some embodiments, the system includes multiple computers connected by network 108. The network interface device can provide access to network 108 using components such as a packet-switched network interface card, a wireless transceiver, or a telephone network interface. For example, the components can be present in a given computer system. However, embodiments can also communicate technical data and / or technical instructions by direct memory access, removable non-volatile media, or other information storage retrieval and / or transmission methods.

[0289] Those skilled in the art will understand that the foregoing aspects and other aspects presented herein under "Operating Environment" can form part of a given embodiment. The headings of this document are not intended to strictly classify features into sets of embodiment and non-embodiment features.

[0290] One or more items are shown in the drawings in dashed lines or listed in parentheses to emphasize that they are not necessarily part of the shown operating environment or of all embodiments, but can interoperate with items in the operating environment or with some embodiments discussed herein. In any drawing or any embodiment, items in non-dashed or non-parenthetical form are not necessarily required. In particular, Figure 1 is provided for convenience; including an item in Figure 1 does not imply that the item or its described use was known prior to the present invention.

[0291] Tracking environment

[0292] Figure 2 and 3 respectively show real-time process environments; Figure 2 shows managed code 208, while Figure 3 shows native code 308. These environments 200, 300 were also discussed in detail above. Of particular interest here are tracker 204 and trace 220 generated by tracker 204. Tracker 204 and trace 220 can include familiar aspects, but they will also reflect and benefit from the selective tracking innovations taught herein.

[0293] In each of the environments 200, 300, there is a tracker 204. Tracker 204 was initially designed and implemented or has been adapted to perform selective tracking as taught herein. A debugger 202 can also be present in one or both of the environments 200, 300. If present, the debugger can be integrated with the tracker to perform tracking during debugging, or the debugger can only read trace 220 previously created by the tracker.

[0294] Tracking

[0295] As Figure 4As shown, the trace 220 can be stored in one or more files 420 and can include various kinds of trace data, as well as metadata that supports or defines a search of the trace data. Part or all of the trace 220 can also reside in the RAM. Some examples of trace data include in-place accurate trace data 422 (such as copies of low-level instructions and their operands), time codes 424 that can be used to sort trace data items relative to each other, memory snapshots 216 or dumps 218, indexes 430 into the original trace data, key frames 432 inserted into the original trace data at specified intervals, copies of code 434 executed by a debug object during the trace, stack activity 436, data streams 438 read or written by the debug object during the trace, processor activity on a per-core 440 or per-socket (multiple cores) 442 basis, thread activity 444 during the trace, register reads and writes 446 during the trace, tuples 456 that associate a memory address 448 with an instruction 450 and one or more values 452 and optionally also with a time code 424, and other 454 reads or writes or values or opcodes captured in the trace. In some embodiments, an instance of any one of the items 216, 422, 434, 436, 438, 440, 442, 444, 446, 456 conforms to a trace "entry" 458. In some, any minimal portion of the trace data 454 that itself represents a state change of the tracing program conforms to a trace "entry" 458. The absence of certain data in the trace can also be considered state information, such as a gap 428 in the time code sequence.

[0296] Some tracing processes record only two kinds of data. One kind of data recorded is the execution of code instructions 116 that potentially execute in parallel on multiple threads. The other kind of data recorded is a snapshot 216 of a particular block of memory taken at discrete points in execution time, e.g., to capture a portion of the stack when selective recording is initiated. However, other tracing processes record different or additional kinds of data, such as Figure 4As shown. In some cases, the trace contains a valid representation of all the recorded instructions and all their inputs and outputs. By relying on the determinism of the processor(s) 110 and mainly recording information that cannot be inferred based on that determinism and information that has already been recorded in the trace 220, the recording of the trace 220 can be made efficient. Most of the trace 220 is data in some implementations rather than the executed code instructions; such data is usually non-deterministic. The trace can mainly be seed data plus non-deterministic information. In some cases, only information that hits the traced processor(s) is recorded into the trace 220. For example, the read of the value V in the processor register is entered into the trace, but the write of the value V from the register to the memory location X does not have to be entered into the trace. If the write operation to X is different in the behavior of the traced program, it is because, at some point, the written value returns from X to the processor register, and at that point, if the trace is still enabled, an entry in the trace 220 can be made.

[0297] Figure 5 Illustrated are various memories 112 that can be traced and thus subject to inspection in accordance with the teachings herein. Examples of the illustrated memory cells 502 include a stack 504 (including data such as its base address 506 and the allocated stack frames 508), heap contents 510 such as an object 512, or metadata such as garbage collection data, a cache 514, processor registers 516, object members such as attributes 518, addressable units in a ROM 520 or RAM 524, removable or tertiary memory 522, local memory 526, and global memory 528. The memory cells can have one or more characteristics 530 that increase or decrease the accessibility of the memory cells. For example, the memory can be in kernel space, can be shared, can be subject to DMA, and so on.

[0298] Figure 6 Illustrated is thread 602 activity information 444 that can be captured in a given trace 220. Illustrated are a thread identifier 604, a thread status indication 606, the executable code 608 of the thread, and memory cell 502 status information 610 (such as thread local variables and their identifiers).

[0299] More about the system

[0300] Examples are provided herein to help illustrate various aspects of the technology, but the examples given within this document do not describe all possible embodiments. The embodiments are not limited to the specific implementations, arrangements, displays, features, methods, or scenarios provided herein. A given embodiment can include, for example, additional or different technical features, mechanisms, sequences, or data structures and can otherwise depart from the examples provided herein.

[0301] Figure 7 FIG. 2 shows a system 102 configured for selective tracing as taught herein. One or more portions 702 of code are designated for tracing using one or more specified criteria 704. For example, the criteria 704 can include a list of file names, object names, method names, module names, routine names, or other identifiers of portions 702 that a developer wishes to include in the tracing. The criteria can also or alternatively include attributes or special instructions located within the code of a procedure that can be identified by a runtime or debugger during procedure execution and used to trigger tracing. "Included in the tracing" and like phrases herein mean that tracing is enabled or will be enabled when the code in the designated portion is executed. In particular, the criteria 704 can specify "user code" such that tracing is substantially limited to software considered to be "user code", where "substantially" means that 90% (or other specific administrator-selected value) of the traced code is user code. Conforming user code can be defined by the developer of the software being traced as a configured "include list", defined as a set of module, namespace, or class names. It can also be determined automatically by excluding well-known standard libraries. After a thread of execution exits "user code", tracing is temporarily paused and resumes when user code is re-entered. Some embodiments support tracing based on a user-configured scope. The user can configure the tracing to be enabled for a short period of time, e.g., for the execution of a single function, the execution of a single web request, or between user-defined points in the procedure code.

[0302] Other portions 706 of the procedure can be implicitly or explicitly designated for exclusion from the tracing. For example, a developer can set the specified criteria 704 to exclude any one or all of the following from the tracing: non-user code libraries 708 (such as standard libraries or third-party libraries), kernel 120 code, compiler 710 code (including, e.g., preprocessors, the compiler itself, assemblers, linkers, interpreters), or garbage collection code 712.

[0303] Unless otherwise stated, excluding portions 706 from the tracing is a goal or preference, but not required. That is, relative to under-inclusion, many (if not all) implementations of the teachings herein will tend to over-include in the tracing. By design, these implementations will operate on the basis that including more in the tracing than specified is better than omitting what is designated for tracing from the tracing. However, the teachings herein can also be applied in other implementations.

[0304] The system 102 shown includes a tracker 204 configured with a tracking controller 700. Some aspects of the tracker 204 may be familiar, while other aspects include or use selective tracking modifications 714. Familiar trackers can have a tracking enabler 718, a tracking disabler 716, and a tracking status 730, for example, although they have not been used for selective tracking previously according to the teachings herein. Some examples of the innovative selective tracking modifications 714 that can be included in or used by the tracking controller 700 include a distance variable 720 coordinated with a distance variable modifier 724 and a stop tracking value 722, thresholds 726 and 728, code whose routine is functionally equivalent to those described in conjunction with Figure 9 described, code that changes the tracking status 730 described in conjunction with Figure 10 described, count assurance code 1120, code that implements one or more adjustment conditions 1210, and code that operates as described in one or more of the figures in Figures 13 - 16 .

[0305] In particular, the selective tracking modification 714 includes or uses a distance variable 720. There can be a single distance variable during the tracking process, or there can be multiple distance variables, for example, one per thread. For clarity, the discussion herein assumes that each process has a single distance variable, but those skilled in the art will readily apply these teachings when selective tracking is implemented using two or more distance variables that can independently disable tracking. Those skilled in the art will also understand that various names can be given to the distance variable in a given implementation. Here, it is called the "distance variable" just as a description to remind people of its usage: one way to describe the appropriate use is to interpret the distance variable as a measure of the computational distance from the operation where tracking is to be turned off. The larger the value in the distance variable, the more tracking will be performed. Conversely, when the distance variable reaches zero (or some other stop tracking value 722), tracking will be disabled.

[0306] Figure 8 Two contrasting systems are shown to emphasize the innovative computational advantages described herein. On the left is the system 102 configured with a distance variable 720, and on the right is a variant 802 lacking a distance variable and other selective tracking modifications 714. In each system, tracking is performed on at least a specified portion 702 of the process 206. In each case, the tracking has an associated computational cost 804, such as the number of processor cycles executed. As Figure 13As shown in the example in, the computational cost 806 of tracking in a system with a distance variable will tend to be less than the computational cost 808 of a system 802 without a distance variable and other selective tracking modifications 714, because there are fewer calls that enable tracking and fewer calls that disable tracking. One trade-off is that when selective tracking modifications 714 are used, the tracking 220 will tend to be larger compared to when they are not used. However, by setting thresholds 726, 728, control can be exerted over the size of the tracking to balance the increase in tracking size with the reduction in tracking computational cost.

[0307] Figure 9 FIG. shows a specific design of the tracking controller 700. It should be understood that other designs can also utilize the teachings presented herein and operate according to Figure 10 , 13 the various methods shown in FIGS. -16. Figure 9 The routines and parameters shown are generalizations of specific implementation examples. This specific implementation example includes a selective tracking interface 714 with the functions described below, which runs on top of the base execution tracking technique 204. The base tracking technique 204 can provide, for example, Windows Event Tracing (ETW) (also known as "time travel tracing" or part of what is called "time travel debugging") for tracking on a system running the environment (a trademark of Microsoft Corporation), for tracking on a system running environments (trademarks of Efficios Inc. and Linus Torvalds respectively), for tracking on a system similar to environments (trademarks of Oracle America, Inc. and X / Open Company Ltd.Corp. respectively),

[0308] and other tracking techniques 204.

[0309] SetThreadInstructionsToRecord(threadInstructions): Caches the number of global instructions that should be recorded on a thread. This cache is thread-local and has no direct impact on recording. The value of threadInstructions can logically be infinite.

[0310] GetThreadInstructionsToRecord(): Returns the value cached by SetThreadInstructionsToRecord().

[0311] SetMaxInstructionsToRecord(maxInstructions): Instructs the underlying tracing technique to stop recording after maxInstructions instructions have been executed in the current thread.

[0312] GetRemainingInstructionsToRecord(): Returns the number of instructions that the underlying tracing technique will record on the current thread before stopping recording.

[0313] TryStartRecordingCurrentThread(): Instructs the underlying tracing technique to start recording the execution of the current thread (if it is not already being recorded).

[0314] In this example, configuration information 704 is provided to system 102 to specify which functions in a process are considered "user code". Specifically, in this example, user code is specified for tracing, and all code in the process that is not explicitly specified for tracing is implicitly specified as not for tracing.

[0315] In operation according to this example, each routine considered to be "user code" is decoded at execution time. At a convenient early execution point in the thread, SetThreadInstructionsToRecord(threadInstructions) is called with a sufficiently large number of threadInstructions. Administrator 104 can determine what constitutes the early, convenient, sufficiently large, sufficiently small, and similar characteristics referred to herein in view of the trade-off between the tracing size and computational cost mentioned above, as well as the capabilities of the decoding, injection, and recording technique 204.

[0316] At each entry point 1202 of a function (the beginning of the function, return points from calls, catch handlers, etc.), insert 1408 code to:

[0317] Call SetMaxInstructionsToRecord(GetThreadInstructionsToRecord()), and

[0318] Call CallTryStartRecordingCurrentThread().

[0319] Before each exit point 1204 of a function (return, function call, exception throw, etc.), insert 1408 code to:

[0320] Call SetThreadInstructionsToRecord(GetThreadInstructionsToRecord() - GetRemainingInstructionsToRecord()), and call SetMaxInstructionsToRecord(e), where e is a sufficiently small number.

[0321] Note that, for example, if GetThreadInstructionsToRecord() returns a logically infinite number, the call can cache the specified infinity value.

[0322] Recompile each newly instrumented function 1646 into machine-executable binary code. Calls to user code functions are redirected 1648 to execute the newly compiled executable code.

[0323] When the resulting code is executed, the distance from the stop recording event or call 716 changes as the distance variable maxInstructions changes value. When entering the specified section 702, the distance increases and then decreases when exiting. If the exit passes control to another specified section, the distance increases again. If the exit does not pass control to another specified section, one of two things tends to happen (in this example, the possibility of another call in the call is ignored for simplicity).

[0324] One possibility is that the entered section 706 not specified for tracing can be small enough (few enough instructions) to pass control back to the specified section before maxInstructions reaches zero and tracing is turned off; after re-entering the specified section, maxInstructions will increase again. In this case, additional tracing (i.e., tracing of code not specified for tracing) will include traversal of the entered section 706 not specified for tracing.

[0325] Another possibility is that the entered section 706 not specified for tracing is large enough that maxInstructions will run continuously until it reaches zero. If this happens while control is still within the entered section 706, the tracing controller 700 turns off tracing when maxInstructions reaches zero. In this case, the additional tracing will include recording of the initial part but not all of the traversal of the entered section 706.

[0326] Control can eventually return to another designated section 702, in which case tracing will be enabled again and maxInstructions will be given a relatively large value, although not necessarily the same large value as given last time. Or the process can end or terminate without the control being passed back to another designated section 702 again, in which case tracing will remain off or at least not be re-enabled by the selective tracing mechanism 700. Some other mechanism can re-enable tracing, but in this case, it is better to use the other mechanism in conjunction with the tracing controller 700 to avoid unexpected or undesirable effects on the tracing 220.

[0327] In view of the foregoing and refocusing Figure 9 , the SetThreadInstructionsToRecord() routine is an example of the set-N routine 902, the parameter threadInstructions is an example of the local-N parameter 904, and the thread cache variable is an example of the local variable N 908. The GetThreadInstructionsToRecord() routine is an example of the get-N routine 906. The SetMaxInstructionsToRecord() routine is an example of the set-DV routine 910, and its parameter maxInstructions is an example of the tracing-max parameter 912. The GetRemainingInstructionsToRecord() routine is an example of the get-DV routine 914. The TryStartRecordingCurrentThread() routine is an example of the try-to-trace routine 916. Here, in addition to the specific examples already given, the general terms 902 - 916 are provided to emphasize that the teachings provided herein are not limited to any particular naming convention, capitalization scheme, programming language, operating system, API, or other implementation peculiarities.

[0328] Figure 10 A tracing state diagram 1000 is shown, which shows the operations of some embodiments. The tracing state diagram 1000 shows tracing in the context of a given thread, and it is to be understood that the teachings herein can be applied to an environment with only a single thread and to a multi-threaded environment. Figure 10 Instances of the state machine can be used independently between threads with corresponding thread-local distance variables DV. As in Figure 10As shown near the center to the right, the execution of process 206 to be traced begins with tracing in the off state 1004, which can also be referred to as a tracing disabled state or a non-tracing state or a non-recording state, for example. One or more instructions 116 of the process are executed 1006 without changing the tracing state. At some point, in this example, after executing 1006 one or more instructions, the execution of the process reaches the try-to-trace() routine 916. The execution 1008 of the try-to-trace() routine 916 determines that the distance variable 720 (also referred to as "DV" in the figure) is equal to zero. In this example, zero is the stop tracing value 722. Thus, the try-to-trace() routine sets the distance variable to a non-zero value and calls 1010 the trace-on routine() of the tracing enabler 718, which is implemented or called in this example. As Figure 10 shown, the tracing state 730 then transitions to the tracing on state 1002, which can also be referred to as a tracing enabled state or a recording state, for example.

[0329] Control is passed to Figure 10 the execute-record-decrement-test loop shown in the upper left. One or more instructions 116 of the process are executed 1006, and corresponding recording 1012 is performed using the underlying tracing technique 204. The correspondence between individual instructions 116 and entries in the trace 220 can be one-to-one or not one-to-one. For example, the tracing technique 204 can perform sampling 1636 by recording every M instructions, where the integer M > 1 is a previously specified sampling period. For example, the sampling period M is set by the administrator 104 or by default or configuration parameters of the underlying tracing technique 204. When performing the recording 1012, the distance to record disable is correspondingly decreased by decrementing 1014 the distance variable. If the distance variable reaches zero, the tracing state transitions back to the tracing off state 1004, and the tracing disabler 716 is called 1016. If the process ends normally or is terminated, the tracing state 730 remains the same as the state at the end of the process.

[0330] When tracing is on, the process may encounter a try-to-trace() call. As Figure 10 shown in the lower left part of, in this state 1002, the execution 1008 of try-to-trace() will determine that the distance variable is non-zero and thus will not change the distance variable. Control will return to Figure 10 the execute-record-decrement-test loop shown in the upper left, which executes 1006 parts of the process, records 1012 the corresponding trace data, decrements 1014 the distance variable, and tests the distance variable to see if it has reached the stop tracing value (zero in this example).

[0331] As Figure 7 shown, some portions 702 of the code of the process to be traced can be specified, and other portions 706 can be implicitly or explicitly specified as not currently of interest and thus not traced, unless perhaps incidentally marked as a byproduct of the use of distance variable 720. Portions 702, 706 can be code units such as threads, libraries, etc. That is, the tracing specification 704 can be implicitly or explicitly applied to portions 702, 706, and the boundaries of portions 702, 706 are the boundaries of certain code units 1100, some of which are shown in Figure 11 it.

[0332] As Figure 11 shown, the code unit 1100 can be one or more of the following, or a collection of one or more of the following: a thread 602, a function 1102, or other routine 1104, a coroutine 1106, an exception handler 1108, an interrupt handler 1110, an implementation 1116 of a virtual method 1114, a callback 1118, a library 1122, a module 1124, or another code unit 1112. For the purposes of tracing, the entire kernel 120 can be a code unit.

[0333] In Figure 11 it is also shown the count-ensuring code 1120, but this is for convenience and completeness when listing ways in which the code can be classified. The count-ensuring code 1120 includes code such as the set-DV routine 910, which exists to implement tracing control, as opposed to being part of the process before the injection of the tracing modification 714.

[0334] Figure 12 Some aspects 1200 of the process code that may be of interest in the discussion of selective tracing are shown. The process 206 code includes instructions 116 and data 118. The process can include routines 1104 and other code units 1100, which have one or more entry points 1202 where control can enter the 1640 code unit, and one or more exit points 1204 where control can exit the 1642 code unit. Control can enter the 1640 code unit, for example, at the top of a routine 1104 after a caller 1206 calls 1638 the routine, and can exit the 1642 routine after reaching the end of the routine or when calling 1638 another routine. "Control" refers to the current execution point 1208, that is, the point in the execution of the process 206 that indicates to the technician or the system or both at least one of the following: what instruction was most recently completed, what instruction is currently being executed, and what instruction will be executed next. For example, the control point can be recorded by recording the execution time point along with its context as a time code 424 (such as the current thread ID 604).

[0335] Figure 12 Also shown are some items that affect or determine one or more adjustment conditions 1210. The adjustment conditions represent and implement a balance of the computational cost 804 of tracing, the size of the trace 220, and the specification 704 of what the developer wants to trace or not to trace. For example, the adjustment conditions 1210 can be adjusted by an administrator or by default settings. They can be determined based on experimental data, such as profile information providing the computational cost, or static analysis data providing statistics on the length and length distribution of routines. The adjustment conditions 1210 can be constant or variable throughout a particular execution of the traced process. Items involved in selectively tracing the execution of the adjustment process can include one or more of the following: a low count threshold 728 for the value of a distance variable, a high count threshold 726 for the value of a distance variable, the current value 1216 of the distance variable 720, information 1218 about the computational cost of routines and other code units 1100 in the traced process, and information 1220 about the computational cost of turning tracing off or on.

[0336] As a further illustration of adjusting the thresholds 726, 728 of 1210, consider the following. Suppose that stopping tracing to not record the computational cost 804, 1220 of a particular function (and then and then later restarting) is equivalent to recording 1000 instructions. The instruction count distribution of the functions that the developer does not want to record is also a consideration. For example, suppose that 90% of the functions that the developer would exclude from recording require 100 or fewer instructions to record. The adjustment can ask whether setting the low threshold 728 (or another count of instructions before automatically stopping recording) to 101 instead of 1 makes sense in terms of computational cost. In some architectures, if the marker to continue recording must be after the function prolog, it may not be possible to set the number lower than the threshold, so at least the low one must be high enough to fit any function prolog and the calls to continue recording, to avoid stopping recording before the instrumentation has a chance to tell the framework to move on (set it back to high). Except for those architectures, recording 90% of the functions that the developer actually wants to exclude is computationally cheaper than excluding all functions. Thus, the relevant adjustment information 1218 includes the possibility that recording the functions designated for exclusion will be cheaper than excluding them, and this information can be used to reduce or minimize the overhead of recording.

[0337] In the context of this tuning discussion, it is estimated that reducing the cost of 101 is the average cost per function (100 * 0.9 + 1101 * 0.1) which equals 200.1 instructions per function. If any of the recorded functions designated for exclusion has fewer than 100 instructions (which seems likely), then this number will actually be lower. The actual number is the recorded average instruction count per function designated for exclusion, and the cost of 1001 is 1001 instructions per function. Thus, the probability 1218 of using functions designated for exclusion below a given number is used to support choosing low as the preferred number.

[0338] Assume that after setting the number to 101, the embodiment finds that actually 89% of the functions fit within 80 instructions. Then, the embodiment can dynamically lower the low to 81 (which is actually a better choice for this data). It is also possible to dynamically increase the number of instructions. For example, if an embodiment observes that for 3% of the functions (30% of those which were not recorded), the recording stops at the end of the function, then the embodiment can increase the low value to account for these.

[0339] The distribution of the probability 1218 can be collected in a variety of ways. One way is previous executions within the same recording session. Other sources of tuning information can be available in the form of general statistics of instruction distributions of functions across industries, functions in code libraries, or functions from previous recordings in the area.

[0340] Reference Figures 1 - 12 Some embodiments use or provide a selective execution tracing system that includes: at least one processor 110 and a digital memory 112 operably communicable with the processor. Executable code 208, 308 is configured to perform a computer-implemented process 206 when executed. The executable code has a plurality of sections 702 designated for tracing and a plurality of other sections 706 not designated for tracing. The system also includes an execution tracer 204 having a tracing disabler 716 configured to disable the tracing of the execution tracer during execution and a tracing enabler 718 configured to enable the tracing of the execution tracer during execution. The system also includes a tracing controller 700. The tracing controller 700 includes a distance variable 720 having a value that indicates the current computed distance from the execution of the tracing disabler. The tracing controller 700 is configured to call the tracing disabler during execution in combination with the distance variable having a stop tracing value 722 and subsequently call the tracing enabler in combination with the distance variable not having the stop tracing value. The distance variable modifier 724 of the system is configured to incrementally move the distance variable 720 closer to the stop tracing value as the executable code of the process 206 is executed.

[0341] In some embodiments, the system is further characterized in that the system's distance-variable cost 806 is less than the system's distance-invariable cost 808. The distance-variable cost 806 is the total computational cost 804 of executing the executable code configured with the tracking controller 700, including: an initial call to execute the tracking enabler 718, execution of the modification of the distance variable 714, one or more calls to execute the tracking disabler 716 when the distance variable reaches the stop-tracking value 722, and any subsequent calls to execute the tracking enabler, and including the computational cost of tracking when tracking is enabled. The distance-invariable cost 808 is the total computational cost 804 of executing a variant of the executable code 208, 308 configured without the tracking controller 700, where the distance variable 720 is not used, where the tracking enabler 718 is called with each entry into the executable code section designated for tracking, and the tracking disabler 716 is called with each exit from the executable code section designated for tracking, and including the computational cost of tracking when tracking is enabled. The computational costs 806 and 808 are measured by at least one of the following: the total number of instructions executed, the total number of processor cycles executed, the total system clock time elapsed, the number of tracking 220 entries 458.

[0342] In some embodiments, the portion 702 of the executable code designated for tracking includes managed code 208, i.e., code configured to run under the control of a runtime 210 that implements memory garbage collection or code compilation, or both. In some embodiments, at least a portion 702 of the executable code designated for tracking consists of native code 308, i.e., code configured to run without a runtime 210 that implements memory garbage collection or code compilation.

[0343] In some embodiments, the tracking controller 700 includes the following: a set-N routine 902 having a local-n parameter 904 and configured to set a thread-local variable 908 (denoted herein as N) to the value of the parameter local-n upon execution; a get-N routine 906 configured to return the current value of the thread-local variable N upon execution; a set-DV routine 910 having a tracing-max parameter 912 and configured to set the distance variable 720 to the value of the parameter tracing-max upon execution; a get-DV routine 914 configured to return the current value of the distance variable 720 upon execution; and a try-to-trace routine 916 configured to: if tracking is not yet enabled, enable tracking of the current thread 602 by the execution tracker 204 upon execution.

[0344] In some embodiments, the distance variable 720 represents the maximum number of instructions 116 to be traced, and the distance variable modifier 724 is configured to decrement the distance variable as the executable code is executed. Additionally, the trace controller 700 is configured to, upon execution, call the trace disabler 716 in conjunction with the distance variable reaching zero as the stop trace value 722, and subsequently call the trace enabler 718 in conjunction with the distance variable being positive. The executable code of the traced process is configured to (e.g., via the injection of the trace modification 714) perform at least one of the following upon execution to ensure that the distance variable is not equal to the stop trace value upon entry into any portion of the executable code designated for tracing: confirm that the distance variable is non-zero, or set the distance variable to a positive high count threshold 726.

[0345] In some of these embodiments, the high count threshold 726 satisfies at least one of the following criteria: the high count threshold indicates logical infinity, the high count threshold exceeds the number of instructions in any code unit 1100, 702 of the executable code designated for tracing, the high count threshold exceeds the number of instructions in any routine 1104, 702 of the executable code designated for tracing, the high count threshold exceeds the number of instructions in routines 1104 that are ninety percent of the executable code, the high count threshold exceeds the average number of instructions in routines 1104 of the executable code. The number of instructions in a particular percentage of routines and the average number of instructions in routines are examples of information 1218 regarding the computational cost of the code.

[0346] In some embodiments, the trace controller 700 includes external high count assurance code 1120 in the executable code at the entry point 1202 of the code unit 1100. The high count assurance code is configured to, upon execution, set the distance variable 720 to a value not less than the high count threshold 726. The code unit includes at least one of the following: a thread 602, a function 1102, a routine 1104, a coroutine 1106, an exception handler 1108, or an interrupt handler 1110. In some embodiments of these embodiments, the trace controller 700 includes low count assurance code 1120 in the executable code prior to a call to a virtual method 1114 within the code unit. The low count assurance code is configured to, upon execution, set the distance variable 720 to a non-zero value not greater than a non-zero low count threshold 728, the low count threshold being less than the high count threshold. The internal high count assurance code 1120 in the executable code of the first implementation 1116 of the virtual method is configured to set the distance variable to a value not less than the high count threshold upon execution, and the code of the second implementation 1116 of the virtual method does not have any code that sets the distance variable. Thus, one or more implementations of the virtual method 1114 can be traced while one or more other implementations of the virtual method are not traced, or at least not designated to be traced.

[0347] In some embodiments, the trace controller 700 includes high count assurance code 1120 in the exception handler 1108. The high count assurance code is configured to set a distance variable to a value not less than a high count threshold 726 when executed. Thus, it can be ensured that tracing continues while handling an exception without incurring the computational cost of invoking and executing the trace enabler 718 inside the exception handler. Instead, tracing continues by setting the distance variable high enough to trace the desired portion (usually all) of the exception handler 1108.

[0348] Those skilled in the art will understand that other systems are also within the scope of the teachings presented herein. In particular, in some cases, other systems may use trace controller code that performs selective tracing, while in some cases not using a particular API, variable, threshold, trace file content, or the specified criteria in the examples described herein. Systems or devices that use any aspect or implementation of the provided selective tracing teachings are within the scope of this disclosure, regardless of whether they are in the examples herein. Any claims consistent with the following should be understood to be within the claims taught herein: selective tracing systems that include trace modification or other trace controller code configured to perform selective tracing operations when executed with a processor, the selective tracing operations replacing or reducing calls to a trace disabler by using a distance variable as taught herein.

[0349] Figure 13 A cost comparison 1300 is shown, which is one of many possible examples of replacing or reducing calls to a trace disabler by using a distance variable. Utilizing the distance variable (indicated as "DV"), only one trace enabler call and one trace disabler call are used to trace routines A and C2, as shown on the left side of Figure 13 Without utilizing the distance variable, four trace enabler calls and four trace disabler calls are used to trace the same routines A and C2, as shown on the right side of Figure 13

[0350] Method

[0351] Methods related to the selective tracing tools and techniques taught herein can be divided into two distinct but closely related categories: methods for configuring a system for selective tracing and methods for performing selective tracing in a properly configured system. Below and elsewhere in this document, for example in connection with Figure 9 , 10 and 13, each method is discussed.

[0352] Figure 14 ​It is a flowchart showing an example of the selective tracing configuration method 1400 category. This method configures 1402 the system 102 for selective tracing. That is, the method 1400 configures the system 102 to control 1404 the tracing 1012 by using 1406 a distance variable 720 and other tracing modifications 714 (such as a stop-tracing value 722, a distance-variable modifier 724, thresholds 726, 728, and routines for setting and testing the distance variable and enabling or disabling tracing based on the value of the distance variable). These can include, for example, a set-DV routine 910, a get-DV routine 914, and a try-to-trace routine 916.

[0353] The method 1400 shown embeds (also known as "inserts" or "injects") a high-count assurance code 1410 at a first location 1412 in the code 208, 308 of the process. The high-count assurance code 1410 is shown as "DV = HIGH" after the TRACE-ON() call in Figure 13 and is shown as a call to SetThreadInstructionsToRecord(threadInstructions) with a relatively large value for threadInstructions in the discussion of Figure 9 In some but not all cases, the method 1400 also embeds 1408 a low-count assurance code 1414 at a second location 1412 in the code 208, 308 of the process. The low-count assurance code 1414 is shown as "DV = LOW" before the call to enter B1 in Figure 13 and is shown as a call to SetMaxInstructionsToRecord(e), where e is a relatively small number, in the discussion of Figure 9 By the way, some embodiments make tracing decisions at runtime of the process via code injection. One technical result of this is that the same code and binaries can be used for recording during development and production without any changes to the source code to permit tracing.

[0354] The method 1400 shown associates 1416 the code 208, 308 of the process with an instruction counter 1418, or other hardware 128, or a combination of a hardware clock or register or circuit and decrementing software. Thus, as discussed, for example, in connection with the execution record of the decrementing test loop in

[0355] the distance variable is automatically modified as the process code executes by bringing the distance variable closer to the stop-tracing value. Figure 10 The DV decrement is not explicitly stated to avoid Figure 13 Figure 13 ​Readability is reduced. On the contrary, it can be understood that DV decreases as the code executes.

[0356] The method 1400 shown connects 1420 the execution tracer 204 to the executable code. For example, this can be done by using familiar methods to connect to ETW tools, tools (a trademark of Efficios Inc.), tools (a trademark of Oracle America, Inc.) or other familiar tracing capabilities. Some embodiments also install 1422 callbacks 1118 to the tracer 204, for example as part of what is implemented as the try-to-trace() routine 916.

[0357] The method 1400 shown configures 1424 the trace controller 700 to disable 1426 tracing when the distance variable reaches the stop trace value 1428 and enable 1430 tracing at another execution time. For example, this step can be done by inserting code that configures the process to perform state 730 transitions and otherwise operate as Figure 10 shown. Figure 13 and Figure 9 The discussion of provides additional examples of configuring 1424 the system to cause enabling and disabling of tracing in conjunction with the state of the distance variable 720 (whether it is the stop trace value).

[0358] Figure 15 is a flowchart showing an example of a selective tracing method 1500 that controls 1404 tracing 1012 in a system configured by method 1400 or another suitable method. As taught herein, any method of configuring the system for selective tracing is a suitable alternative to method 1400.

[0359] Figure 15 The method shown includes: as the process executes, setting 1502 the distance variable to a high value near the entry point 1202 and calling 1008 the try-to-trace routine 916. For example, this is illustrated by performing Figure 13 the following items shown on the left:

[0360] Enter C2: designated

[0361] DV = high

[0362] TRY-TO-TRACE()[already on]

[0363] Figure 15 The method shown includes: as the process executes, setting 1504 the distance variable to a low value near the exit point 1204. At Figure 13On the left side, for example, execute DV = LOW just before each exit from routine A to illustrate the setup 1504 step, where the exits are indicated by ENTER B1: NOT DESIGNATED and ENTER C2: DESIGNATED.

[0364] Figure 15 The method shown includes: executing 1006 instructions and decrementing 1014 the distance variable as the process executes. At Figure 13 the left hand side, this is illustrated by any one of them, as they are all executed and the distance variable DV is implicitly decremented as these are executed.

[0365] Figure 15 The method shown includes: when the distance variable is non-zero and tracing is enabled, recording 1012 execution information into the trace 220. At Figure 13 the left side, this is shown by any one between TRACE-ON() and TRACE-OFF(), as they are all executed when DV is non-zero and tracing is enabled. To help emphasize the difference in behavior with DV ( Figure 13 the left side) and without DV ( Figure 13 the right side), an explicit RECORD operation is also shown in Figure 13 . Thus, when there is DV, B1 is recorded (indicated by RECORD B1), while when there is no DV, B1 is not recorded (before ENTER B1: NOT DESIGNATED, tracing is turned off by a TRACE-OFF() call).

[0366] Figure 15 The method shown includes: disabling 1426 tracing when the distance variable reaches 1428 zero or another stop-tracing value. For example, this is illustrated by the following items shown on Figure 13 the left side:

[0367] EXECUTE UNTIL D == 0

[0368] TRACE-OFF()

[0369] Unless otherwise indicated, the technical methods shown in the figures or otherwise disclosed will be automatically performed by, for example, the tracking controller 700 or the system 102 configured 1402 with tracking modification 714. To the extent that the actions involve a human administrator or other humans, the method can also be performed partially automatically and partially manually. For example, a person can enter the specified criteria 704 into the tool user interface and then initiate the execution of the process 206 being tracked, which causes the tool 122 to configure 1402 the process for tracking and then execute the configured process. However, a method that is completely manual is not considered innovative here. In a given embodiment, zero or more example steps of the method can be repeated, possibly with different parameters or data to be operated on. The steps in the embodiment can also be performed in an order different from that shown in the figures. The steps can be performed sequentially, in a partially overlapping manner, or completely in parallel. The order in which the steps are performed during a given method can vary from one execution of the method to another. If the method being performed is operable and meets at least one claim, the steps can also be omitted, combined, renamed, regrouped, or otherwise deviate from the shown flow.

[0370] Some embodiments use or provide a computer-implemented process for selectively performing tracking. This process uses a distance variable 720, the value of which indicates the relative distance in computational cost to disabling tracking. The memory check process includes embedding 1408 in the executable code at a first location a non-zero high count assurance code 1410, which is configured to set 1502 the distance variable to a value not less than a high count threshold 726 when executed, associating 1416 an instruction count decrement mechanism 724 or other decrement mechanism 724 with the executable code, which is configured to decrement 1014 the distance variable as the executable code is executed, connecting 1420 an execution tracker 204 to the executable code, configuring 1424 the tracking controller 700 to: when the distance variable reaches a stop tracking value (such as zero), disable 1426 the tracking using the execution tracker, and configuring 1424 the tracking controller to: when the distance variable is different from the stop tracking value, enable 1430 the tracking using the execution tracker during at least a portion of the execution of the executable code.

[0371] Some embodiments also include embedding 1408 in the executable code at a second location a low count assurance code 1414, which is configured to set 1504 the distance variable to a non-zero value not greater than a non-zero low count threshold 728 when executed. The low count threshold is less than the high count threshold.

[0372] Various criteria can be used to determine thresholds and other constraints regarding the value of the distance variable. In some embodiments, at least one of the following criteria is met: the number of instructions in the trace disabler configured to disable the trace of the execution tracer is greater than a low count threshold; the number of instructions in the trace disabler configured to disable the trace of the execution tracer is greater than the value of the distance variable at a second location; the computational cost of invoking the trace disabler at the second location to disable the trace of the execution tracer is greater than the computational cost of executing a sequence of M instructions starting from the second location, where M is equal to the value of the distance variable at the second location; the value of the distance variable at the second location is not greater than the average number of instructions per routine in the executable code; the low count threshold is not greater than the average number of instructions per routine in the executable code; the statistical execution cost of tracing a routine not designated for tracing is less than the computational cost of invoking the trace disabler at the second location to disable the trace of the routine.

[0373] In some embodiments, connecting 1420 the execution tracer 204 to the executable code 208, 308 includes installing 1422 in the executable code a callback 1118 for the execution tracer. The callback is configured to determine at execution whether to perform one or more of the following: continue recording, change the value of the distance variable, stop recording. The determined inputs are the value of the distance variable and the trace state 730, as shown, for example, Figure 10 as shown.

[0374] Those skilled in the art will understand that other methods are also within the scope of the teachings presented herein. In particular, in some cases, other methods can perform selective tracing without using the specific APIs, variables, thresholds, state diagram 1000, or designated criteria in the examples described herein. Any method that uses any aspect or implementation of the provided selective tracing teachings is within the scope of this disclosure, regardless of whether they are in the examples herein. Any claim consistent with the following should be understood to be within the claims taught herein: a selective tracing method, including configuring a system with trace modifications or a system that performs such a configuration, i.e., configuring or performing a selective tracing operation that replaces or reduces calls to a trace disabler by using a distance variable as taught herein.

[0375] Configured medium

[0376] Some embodiments include a configured computer-readable storage medium 112. The medium 112 can include a disk (magnetic, optical, or otherwise), RAM, EEPROMs or other ROMs, and / or other configurable memories, particularly including computer-readable media (which are not merely propagated signals or energy). The configured storage medium can particularly be a removable storage medium 114, such as a CD, DVD, or flash memory. General memory (which can be removable or non-removable, and can be volatile or non-volatile) can be configured into embodiments such as distance variable 720 having a stop-tracking value 722 and a modifier 724 that automatically moves the distance variable towards the stop-tracking value as the process executes, routines 910, 914, 916, and adjustment conditions 1210 having constitution thresholds 726, 728 and information 1218, 1220, read in the form of data 118 and instructions 116 from the removable medium 114 and / or other sources (such as a network connection) to form the configured medium. As disclosed herein, the configured medium 112 is capable of causing a computer system to perform technical processing steps for selectively tracking portions of computer process execution. Thus, the figures help illustrate configured storage medium embodiments and process embodiments, as well as system and process embodiments. In particular, Figure 10 , 14 , 15, 16, or any process steps otherwise taught herein can be used to help configure the storage medium to form the configured medium embodiments.

[0377] Some embodiments use or provide a computer-readable storage medium 112, 114 configured with code that, when executed by a computer processor 110, performs a selective execution tracking method. The method includes the following. At an entry point of a code unit, a distance variable 720 is set 1502 to a value not less than a non-zero high count threshold 726, which distance variable measures a relative distance at which tracking is disabled in terms of computational cost. In conjunction with setting the distance variable to a value not less than the high count threshold, a call is made that, if tracking has not been enabled, supports 1430 the execution of up to the number of instructions of the tracker 204 that the value of the distance variable counts, and if tracking has already been enabled, enables tracking to continue. At an exit point of the code unit, the distance variable is set 1504 to a non-zero low count threshold 728 that is less than the high count threshold. The distance variable is automatically decremented 1014 as the computer processor executes the instructions of a computer process that includes the code unit. When the value of the distance variable is positive and the execution tracker is enabled, the execution tracker tracks 1012 the execution of the computer process, and disables 1426 the tracking of the execution of the computer process in response to the value of the distance variable reaching 1428 zero.

[0378] In some embodiments, the selective execution tracing method includes identifying the routines designated by 1650, i.e., the routines designated for tracing. The identification is based on at least one of the following criteria 704: the author of the routine, the time the routine was written, whether the routine is marked as confidential, whether the routine is part of the runtime, whether the routine is part of a designated library, whether the routine is part of a designated namespace, whether the routine has designated parameters, whether the routine is part of the just-in-time compiler, whether the routine is part of the garbage collector, whether the routine is part of the kernel, the name of the routine, the name of the module containing the routine, the direct caller of the routine, or the indirect caller of the routine. The selective execution tracing method also includes at least tracing 1012 the designated routines or other identified 1650 code units 1100.

[0379] In some embodiments, at an early execution point of a code unit, the selective execution tracing method sets 1502 a variable, here represented as N, to a value not less than a high count threshold. The variable N is local to the code unit. The early execution point is a point in the execution of the code unit at which at least one of the following criteria is met: no more than ten instructions of the code unit have been executed since the code unit received control, no more than one-tenth of the instructions of the code unit have been executed since the code unit received control. The exemplary selective execution tracing method also modifies the code at the exit point of the code unit to subtract 1504 the value of a distance variable at that exit point from the value of N, thereby setting the distance variable to a non-zero low count threshold less than the high count threshold.

[0380] In some embodiments, the selective execution tracing method includes generating 1012 an execution trace 220 that has trace data corresponding to the execution of at least five designated routines 702, 1104 and has at least three gaps 428 in the trace data, where the tracing is disabled 1426 as a result of a distance variable reaching 1428 zero.

[0381] In some embodiments, the selective execution tracing method disables 1426 tracing K times during the execution of a computer process 206, where K is positive. In particular, in this example, the tracing is disabled at least half of the above K times because the value of a distance variable reaches 1428 zero.

[0382] In some embodiments, in response to designating a portion 706 as a criterion for not being traced, the selective execution tracing method does not trace at least one of the following: code that is at least part of a library 1122 explicitly identified as being excluded from tracing, code that is at least part of the kernel 120, code that is at least part of a compiler 710, code that is at least part of a garbage collector 712.

[0383] In some embodiments, the high count threshold 726 or the low count threshold 728 or both thresholds change during the execution of a computer process. For example, the threshold change can be made in response to an adjustment condition 1210 specific to a portion of code.

[0384] Those skilled in the art will understand that other configured media embodiments are also within the scope of the teachings presented herein. In particular, other embodiments may include statutory media configured to perform selective tracing in some cases without using a particular API, variable, threshold, state diagram 1000, or the specified criteria in the examples illustrated herein. Any aspect or implementation method of using the provided selective tracing teachings is within the scope of this disclosure, regardless of whether they are in the examples herein. Any claim consistent with the following claims should be understood to be within the claims taught herein: A computer-readable storage medium configured with code that, when executed by a processor, performs a selective tracing method that replaces or reduces calls to a tracing disabler by using a distance variable as taught herein.

[0385] Some additional combinations and variations

[0386] Any combination of these combinations of code, variables, data types and data structures, logic, components, assumptions, communications, and / or their functional equivalents can also be combined with any of the above systems and their variations. A process can include any of the steps described herein in any subset or combination or sequence that is operable. Each variation can occur alone or in combination with any one or more other variations. Each variation can occur with any process, and each process can be combined with any one or more other processes. Each process or process combination (including variations) can be combined with any one of the above media combinations and variations.

[0387] Conclusion

[0388] Although specific embodiments are explicitly shown and described herein as processes, configured media, or systems, it should be understood that the discussion of one type of embodiment generally extends to other embodiment types as well. For example, the process description in conjunction with Figure 9 、 10 、14 - 16 also helps to describe the configured media and helps to describe the technical effects and operations of systems and manufacturing similar to those discussed in conjunction with other figures. It is not necessarily the case that the limitations from one embodiment must be read into another embodiment. In particular, a process need not be limited to the data structures and arrangements presented when discussing systems or manufacturing such as configured memories.

[0389] Those skilled in the art will understand that implementation details can be related to specific code, such as a specific API, a specific type of trace data, and specific values, and thus may not necessarily occur in every embodiment. Those skilled in the art will also understand that the program identifiers and some other terms used when discussing details are specific to the implementation and thus may not necessarily be relevant to every embodiment. Nevertheless, although they are not necessarily required to be present here, such details can help some readers by providing context, and / or can illustrate some of the many possible implementations of the techniques discussed herein.

[0390] References herein to embodiments having some feature X and references elsewhere herein to embodiments having some feature Y do not exclude embodiments that have both feature X and feature Y, unless such an exclusion is explicitly stated herein. All possible negative claim limitations are within the scope of the present disclosure because any feature that is specified as part of an embodiment can be explicitly deleted from other embodiments even if a particular exclusion is not given in any example herein. The term "embodiment" is used herein only as a more convenient form for "process, system, article, computer-readable medium of configuration, and / or other example of the teachings herein applied in a manner consistent with applicable law". Thus, a given "embodiment" can include any combination of the features disclosed herein, so long as the embodiment is consistent with at least one claim.

[0391] In each embodiment, not every item shown in the figures must be present. Instead, an embodiment can include items that are not explicitly shown in the figures. Although some possibilities are shown herein by specific examples in the text and drawings, an embodiment can depart from these examples. For example, a particular technical effect or technical feature of an example can be omitted, renamed, differently grouped, repeated, differently instantiated in hardware and / or software, or be a mixture of effects or features that appear in two or more examples. In some embodiments, a function shown in one location can also be provided in a different location; for example, those skilled in the art recognize that functional modules can be defined in various ways in a given implementation without necessarily ignoring the required technical effects from a set of interacting modules considered as a whole.

[0392] Throughout the text, the drawings are referenced by reference numerals. Any apparent inconsistencies in the wording associated with a given reference numeral in the drawings or text should be understood as simply broadening the scope of what that numeral references. Even when the same reference numeral is used, different instances of a given reference numeral can refer to different embodiments. Similarly, a given reference numeral

[0393] can be used to refer to a verb, a noun, and / or the corresponding instances of each, e.g., processor 110

[0394] The 110 instruction can be processed by executing an instruction.

[0395] As used herein, terms such as "a" and "the" include one or more of the indicated items or steps. In particular, in a claim, a reference to an item generally indicates the presence of at least one such item, and a reference to a step indicates at least one instance of performing the step.

[0396] The headings are for convenience only; information about a given topic may be found outside of the section where the heading indicates the topic.

[0397] All of the claims and abstracts submitted are part of the specification.

[0398] Although the exemplary embodiments have been shown in the drawings and described above, it will be apparent to those of ordinary skill in the art that various modifications can be made without departing from the principles and concepts set forth in the claims, and such modifications do not necessarily encompass the entire abstract concept. Although the subject matter has been described in language specific to structural features and / or procedural acts, it should be understood that the subject matter defined in the appended claims need not be limited to the specific technical features or acts described in the claims. Each means or aspect or technical effect identified in a given definition or example need not be present or utilized in every embodiment. Rather, the specific features and acts and effects described are disclosed as examples to be considered in implementing the claims.

[0399] To the maximum extent permitted by law, all changes that fall within the entire abstract concept but within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A selective execution tracing system, comprising: at least one processor including registers; a digital memory operably communicable with the processor; executable code configured to perform a computer-implemented process when executed, the executable code having: one or more first portions designated for tracing, and one or more second portions not designated for tracing; an execution tracer that traces the executed code when tracing is enabled; a tracing disabler configured to disable the tracing of the execution tracer; a tracing enabler configured to enable the tracing of the execution tracer; a tracing controller that references the registers, the registers being configured to store a distance variable representing a maximum amount of computational cost incurred before invoking the tracing disabler, the tracing controller being configured to: invoke the tracing disabler in combination with the distance variable reaching a stop-tracing value, and subsequently invoke the tracing enabler conditioned on the distance variable not having the stop-tracing value; and a distance variable modifier configured to, incrementally move the distance variable closer to the stop-tracing value when the one or more second portions of the executable code are executed, and move the distance variable away from the stop-tracing value when the one or more first portions of the executable code are executed, wherein during the execution of at least one subset of the one or more second portions, the value of the distance variable causes the execution tracer to trace the at least one subset of the one or more second portions.

2. The selective execution tracing system according to claim 1, wherein the amount of computational cost is measured by at least one of: the number of instructions executed, the number of processor cycles executed, the elapsed system clock time, or the number of tracing entries.

3. The selective execution tracing system according to claim 1, wherein the one or more first portions of the executable code designated for tracing include managed code, i.e., code configured to run under the control of a runtime that performs at least one of memory garbage collection or code compilation.

4. The selective execution tracing system according to claim 1, wherein at least one first portion of the executable code designated for tracing includes native code, i.e., code configured to run without a runtime.

5. The selective execution tracing system according to claim 1, wherein the tracing controller comprises: a set-N routine having a local-n parameter and configured to set a thread-local variable to the value of the parameter local-n when executed, the thread-local variable being represented herein as N; a get-N routine configured to return the current value of the thread-local variable N when executed; a set-DV routine having a tracing-max parameter and configured to set the distance variable to the value of the parameter tracing-max when executed; The get-DV routine, configured to return the current value of the distance variable upon execution; and the try-to-trace routine, configured to: if tracing has not been enabled, enable tracing of the current thread by the execution tracer upon execution.

6. The selective execution tracing system according to claim 1, wherein: the distance variable modifier is configured to: move the distance variable closer to the stop tracing value upon execution of the one or more second portions of the executable code by decrementing the distance variable as the executable code executes; and the tracing controller is configured to: upon execution, call the tracing disabler in conjunction with the distance variable reaching zero as the stop tracing value, and subsequently call the tracing enabler in conjunction with the distance variable being positive, the executable code being configured to: upon execution, perform at least one of the following to ensure that the distance variable is not equal to the stop tracing value upon entering any first portion of the one or more first portions of the executable code designated for tracing: confirm that the distance variable is non-zero, or set the distance variable to a positive high count threshold.

7. The selective execution tracing system according to claim 6, wherein the high count threshold meets at least one of the following criteria: the high count threshold indicates logical infinity; the high count threshold exceeds a first number of instructions in any code unit of the one or more first portions of the executable code designated for tracing; the high count threshold exceeds a second number of instructions in any routine of the one or more first portions of the executable code designated for tracing; the high count threshold exceeds a third number of instructions in routines that are ninety percent of the executable code; or the high count threshold exceeds the average number of instructions in the routines of the executable code.

8. The selective execution tracing system according to claim 6, wherein the tracing controller comprises: external high count ensuring code in the executable code at the entry point of a code unit, the high count ensuring code being configured to: upon execution, set the distance variable to a value not less than the high count threshold, wherein the code unit comprises at least one of the following: a thread, a function, a routine, a coroutine, an exception handler, or an interrupt handler; low count ensuring code in the executable code before a call to a virtual method within the code unit, the low count ensuring code being configured to: upon execution, set the distance variable to a non-zero value not greater than a non-zero low count threshold, the low count threshold being less than the high count threshold; and internal high count ensuring code in the executable code in a first implementation of the virtual method, configured to set the distance variable to a value not less than the high count threshold upon execution; and wherein a second implementation of the virtual method does not have any code for setting the distance variable.

9. The selective execution tracing system according to claim 6, wherein the tracing controller includes a high count assurance code in an exception handler, and the high count assurance code is configured to set the distance variable to a value not less than the high count threshold when executed.

10. The selective execution tracing system according to claim 1, wherein the tracing enabler is invoked conditioned on the distance variable not having the stop tracing value. comprising: invoking the tracing enabler after the distance variable has been modified to not have the stop tracing value.

11. A selective execution tracing method implemented at a computer system, the computer system including at least one processor, the at least one processor including a register configured to store a distance variable that represents a maximum computational cost amount incurred before invoking a tracing disabler, the method comprising: executing executable code at the at least one processor, the executable code having: one or more first portions designated for tracing, and one or more second portions designated not for tracing; managing the distance variable based at least on the execution of the executable code includes: incrementally moving the distance variable closer to a stop tracing value when the one or more second portions of the executable code are executed, and moving the distance variable away from the stop tracing value when the one or more first portions of the executable code are executed; and managing tracing of the distance executable code based at least on the value of the distance variable includes: invoking the tracing disabler in conjunction with the distance variable reaching the stop tracing value, and after invoking the tracing disabler, invoking a tracing enabler conditioned on the distance variable not having the stop tracing value, wherein during execution of at least one subset of the one or more second portions of the executable code, the value of the distance variable causes tracing of the at least one subset of the one or more second portions of the executable code.

12. The selective execution tracing method according to claim 11, wherein the computational cost amount is measured by at least one of: the number of instructions executed, the number of processor cycles executed, the elapsed system clock time, or the number of tracing entries.

13. The selective execution tracing method according to claim 11, wherein the one or more first portions of the executable code designated for tracing include managed code, i.e., code configured to operate under the control of a runtime that performs at least one of memory garbage collection or code compilation.

14. The selective execution tracing method according to claim 11, wherein at least one first portion of the executable code designated for tracing includes native code, i.e., code configured to operate without a runtime.

15. The selective execution tracing method according to claim 11, wherein the tracing enabler is invoked conditioned on the distance variable not having the stop tracing value. comprising: Call the tracking enabler after the distance variable has been modified to not have the stop tracking value.

16. A computer-readable storage medium configured with code that, when executed by a computer processor, the computer processor including a register configured to store a distance variable that represents the maximum amount of computational cost incurred before calling a tracking disabler, causes a computer system to at least perform the following: Execute executable code at the at least one processor, the executable code having: One or more first portions designated for tracking, and One or more second portions not designated for tracking; Managing the distance variable based at least on the execution of the executable code includes: Incrementally moving the distance variable closer to a stop tracking value when the one or more second portions of the executable code are executed, and Moving the distance variable away from the stop tracking value when the one or more first portions of the executable code are executed; and Managing tracking of the distance executable code based at least on the value of the distance variable includes: Calling the tracking disabler when the distance variable reaches the stop tracking value, and After calling the tracking disabler, calling the tracking enabler conditioned on the distance variable not having the stop tracking value, wherein during execution of at least one subset of the one or more second portions of the executable code, the value of the distance variable causes tracking of the at least one subset of the one or more second portions of the executable code.

17. The computer-readable storage medium of claim 16, wherein the amount of computational cost is measured by at least one of: the number of instructions executed, the number of processor cycles executed, the elapsed system clock time, or the number of tracking entries.

18. The computer-readable storage medium of claim 16, wherein the one or more first portions of the executable code designated for tracking include managed code, i.e., code configured to run under the control of a runtime that performs at least one of memory garbage collection or code compilation.

19. The computer-readable storage medium of claim 16, wherein at least one first portion of the executable code designated for tracking includes native code, i.e., code configured to run without a runtime.

20. The computer-readable storage medium of claim 16, wherein calling the tracking enabler conditioned on the distance variable not having the stop tracking value includes calling the tracking enabler after the distance variable has been modified to not have the stop tracking value.

Images