Selective tracking portion of computer process execution

Abstract

Embodiments disclosed relate to selective tracking of computer process execution. 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. The creation task function is modified to include settings of an indicator that indicates that a newly created task is to be tracked if a current task or thread is being tracked. The execution task function is modified to request tracking of the newly created task when the newly created task is executed based on the indicator, thereby enabling selective tracking that operates across process boundaries and tracks asynchronous code execution.

Description

[0001] Related Applications

[0002] This application is a divisional application of an invention patent application with an international application date of April 13, 2019, which entered the Chinese national stage on October 27, 2020, with Chinese national application number 201980028662.0, and invention name “Selective tracking portion of computer process execution”. Background Art

[0003] Computer software is often complex. Part of the complexity may come from the nature of the work that the program is designed to perform, such as tracking a large number of real-world items or ongoing transactions over hours or longer, coordinating activities with other complex software, controlling complex hardware, and so on. Complexity also arises in almost any real-world use of software, because many details are introduced and should be managed correctly to instruct computer hardware how to perform real-world work, which is much less precise when originally described in English or another natural language. That is, the conversion from a high-level description to a low-level implementation executable by a computer system inevitably introduces complexity. Even programming language source code that is more precise than natural language is still at a relatively high level and is therefore vague and open to various understandings and implementations. The source code is converted into low-level instructions that are directly executable by computational hardware, and many details are introduced and choices are made during the conversion.

[0004] Complexity introduces the possibility of programming errors (also called "defects", bugs) that are usually not often recognized. The process of identifying the cause of the defect and attempting to modify the program to remedy or remove the effect of the defect is called "debugging". Specialized software tools that assist in debugging are called "debuggers". The program being debugged is called a "debugee".

[0005] Debugging may be the easiest when the developer can arbitrarily run the debug object slowly or at full speed, or arbitrarily suspend the execution of the debug object, and can check all the state information of the debug object at any time during the execution of the debug object. This is referred to as "real-time process debugging". However, such full access to the debug object is usually unavailable. For example, the debug object may be production software, and real-time debugging cannot be performed to the production software without violating the service agreement or damaging the reputation, security or financial status of the interested party. If the real-time process debug object is suspended for a few seconds at a time when the developer checks the variable value, checks which functions are called using which parameter values, views the source code, considers the possible explanation of the defect, and designs the test that may help to identify, remedy or eliminate the defect, it may cause unacceptable harm.

[0006] Thus, sometimes state information is recorded while the debuggee is executing so that it can be examined later without substantially pausing the execution of the debuggee. For example, some or all of the memory values ​​associated with the execution of the debuggee and the operations on these values ​​can be recorded over time in an execution trace. In the case where the debuggee is not a real-time process, some debuggers support the use of such traces to replay the execution of the debuggee being traced. With some debuggers, the execution of the debuggee captured in the trace can be replayed forward or backward, thereby permitting "time travel", "reverse" or "historical" debugging.

[0007] Tracing typically slows down the debuggee. Therefore, tracking the progress of software program execution while avoiding undue impact on software performance helps improve the information available for debugging, and will therefore tend to improve the functionality of the debuggee computer system by supporting the mediation and elimination of their defects. To be useful for software programs that rely on asynchronous execution, these advances must be able to continue to track execution across multiple threads of execution. Summary of the invention

[0008] Some of the techniques described herein relate to technical activities for creating execution traces that focus on the parts of a program that are most likely to contain defects of interest, thereby improving debugging based on tracing, while also being able to continue execution tracing across multiple threads of execution. Some teachings relate to specific computational mechanisms that balance the computational cost of enabling or disabling tracing with the computational and storage costs of tracing code that is not helpful for specific debugging work. Other teachings relate to specific computational mechanisms for tracing tasks, annotating and tracking these tasks as they are executed in different threads of execution. A technical mechanism for adapting the environment to create a trace of interest from a native process or a managed process is described. In response to the challenge of focusing tracing on user code of interest, specific technical tools and techniques are described herein to reduce the undesirable performance degradation and trace size increase caused by tracing non-user code (such as kernel, compiler, garbage collector, or standard library code), while being able to trace execution across multiple threads. Other technical activities related to the teachings herein will also become clear to those skilled in the art.

[0009] Some selective execution tracing embodiments described herein include a processor, a digital memory in operable communication with the processor, and executable code for a computer-implemented process. The executable code has a portion implicitly or explicitly designated for tracing and other portions not designated for tracing. There is an execution tracer, a trace disabler is used to disable the tracing of the execution tracer, and a trace enabler is used to enable the tracing of the execution tracer. The tracing controller includes a trace disable distance variable, the value of which indicates the current calculated distance from the execution trace disabler. That is, the larger the distance variable is when tracing is enabled, the more executable code execution will be tracked before tracing is disabled. The tracing controller calls the tracing disabler in conjunction with a distance variable having a stop tracing value (e.g., zero). The tracing controller may then call the tracing enabler in conjunction with a distance variable that does not have a stop tracing value. As the executable code executes, the distance variable modifier incrementally moves the distance variable to get closer to the stop tracing value. For example, the distance variable modifier may decrement the positive value in the distance variable, thereby moving the distance variable to approach zero, and when the distance variable reaches zero, tracing will be disabled.

[0010] By using a distance variable to control trace disabling, rather than explicitly calling a trace disabler each time execution exits a portion of executable code designated for tracing, an embodiment can reduce the computational cost of tracing. This can be beneficial in various situations because tracing is used for a variety of purposes, such as during debugging, to assist in code understanding, for statistical analysis, and to support other goals. This reduction in computational cost is in exchange for tracing some code that is not of interest. The trace file may be larger than if only the code of interest was traced, but the performance impact of tracing is often smaller than if only the code of interest was traced. For example, in a debugging context, when code is outside of a suspicious portion of the code, the code is considered "uninteresting" relative to a particular defect, which makes it less likely to help identify and mitigate or remove the defect. For example, code in an item (such as a kernel, compiler, system library, or garbage collector) is not interesting for identifying defects in user code outside of these items.

[0011] Some embodiments described herein relate to configuring an environment to perform computer-implemented selective execution tracing. Some embodiments particularly relate to executable code configured for tracing, which is controlled using a tracing disable distance variable (i.e., a variable whose value indicates a relative distance from disabling tracing in terms of computational cost). A method embeds a non-zero high count ensuring code in the executable code, which 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 decrementing mechanism with the executable code, which is configured to decrement the distance variable as the executable code executes. The method also connects an execution tracker to the executable code. The method configures the tracing controller to disable tracing when the distance variable reaches a stop tracing value, and also configures the tracing 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 disabling distance variable at the 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 from disabling tracing in terms of computational cost. In conjunction with setting the distance variable to a value not less than the high count threshold, the embodiment makes a call that enables the execution tracer to trace instructions up to the number of values ​​of the distance variable if tracing has not yet been enabled, and that enables tracing to continue to be enabled if tracing has already been enabled. At the exit point of the code unit, the embodiment sets the distance variable to a non-zero low count threshold that is less than the high count threshold. As the computer processor executes instructions of a computer process containing the code unit, the distance variable is automatically decremented. 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 tracing of the execution of the computer process.

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

[0014] A more detailed description will be given with reference to the accompanying drawings, which illustrate only selected aspects and are therefore not intended to be exhaustive in terms of coverage or scope.

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

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

[0017] Figure 3 is a block diagram illustrating aspects of tracing a native code process;

[0018] Figure 4 is a block diagram illustrating aspects of execution tracing;

[0019] Figure 5 is a block diagram showing some kinds of memory cells that may be referenced in tracing;

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

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

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

[0023] Fig. 9 is a block diagram illustrating aspects of using a tracking disable distance variable to control a tracking controller that performs tracking;

[0024] Fig.10 It is a tracking state diagram;

[0025] Fig.11 is a block diagram showing some of the various code units and associated items that may be traced;

[0026] Fig.12 is a block diagram illustrating some aspects of the code that may be associated with tracing and some conditioning conditions that may be employed when tracing the code under control of a trace disable distance variable;

[0027] Fig.13 is a computational cost comparison of side-by-side tracking control implementations in tracking scenarios;

[0028] Fig.14 is a flow chart illustrating an example method for configuring a system for selective execution tracing using a trace disable distance variable;

[0029] Fig.15 is a flow chart illustrating an example method for selective execution tracing using a trace disable distance variable;

[0030] Fig.16is a flow chart further illustrating a method related to selective execution tracing using a trace disable distance variable; and

[0031] Fig.17 is a flow chart illustrating a method related to execution tracking of asynchronously executed tasks. DETAILED DESCRIPTION

[0032] Overview

[0033] Software developers are often responsible for investigating software defects that are difficult to reproduce, or that occur on machines that they do not have access to for direct debugging purposes. In these cases, it is helpful to have a system that automatically logs the execution of a procedure to a file so that the problem can be debugged later, or to debug without interrupting the execution of the procedure. However, such logging can result in significant overhead and extremely large file sizes.

[0034] In particular, debugging in a production cloud environment presents serious technical challenges. For example, suppose a particular request R to 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 in the processing of request R? To find the defect, 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.

[0035] Innovations in debugging based on tracing help overcome technical challenges that traditional methods cannot solve. For example, many traditional debuggers and debugging methods allow developers to set halt breakpoints to obtain information about variable values. Halt breakpoints are instructions that suspend execution so that developers have time to examine memory contents at a given point in the process and consider possible explanations for the observations. However, in a production environment, halt breakpoints may suspend the processing of a large number of requests, which is undesirable. Even if only a single thread is paused, it may result in undesirable abandonment of requests and produce unpredictable side effects that hinder debugging, or reduce performance, or both.

[0036] Some familiar debugging methods involve adding print statements at specific points in the code to print the value of a specific variable, or adding other code, for example, to test the value of a variable to see if it is the value the developer expects at this point in the code. However, these methods may require recompiling and redeploying the code, which is unwelcome in a production environment, especially if recompiling and redeploying are to be done multiple times as part of an iterative debugging process to find and fix a single defect. In addition, the developer may be required to identify defects in code for which the developer does not have the source and therefore cannot add print statements and recompile.

[0037] Developers can inject operations into request processing code at execution time to make copies of some or all of the memory related to the request. The copy can include a "snapshot" 216 (an in-memory copy of a process that shares memory allocation pages 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 memory contents in a specific format that shows variable values ​​translated from binary into an informative structure including variable names and displays variable values ​​based on the corresponding data types of the variables. However, dumping memory to a file takes a lot of time, which slows down the processing of not only request R but all requests in the example scenario. Although making a snapshot is much faster than creating a dump file, this may require a lot of attempts by the developer to find a useful point in the process to obtain a memory snapshot that reveals the defect, and the snapshot takes up space in RAM. In order to view the memory at another point in time other than execution time captured in a dump file or snapshot, another memory copy can be created. In order to view the memory from any point in time of a real-time process, a real-time process is used.

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

[0039] The teachings provided herein may be beneficially applied in one or both of the two environments 200, 300. As shown, a tool 122 (such as a debugger 202 or an execution tracer 204) may inject operations into a real-time 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 may inject operations into the request handling code to make a copy of some or all of the memory 112, 212 associated with the problematic request R. The instructions 116 to implement the memory copy may 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 a binary representation of executable code is decoded and rewritten at execution time to add additional functionality to the program.

[0040] Processes that lack a runtime can be controlled directly by the debugger by inserting breakpoints to pause. However, processes that rely on the runtime are not directly controlled by the debugger 202 because their 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 current memory values, the runtime sends these values ​​in a reply message to the debugger, and the debugger displays the values ​​it received in the reply message in some user interface.

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

[0042] 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 be executed on each thread, a call stack for each thread, a set of variables in each frame of the call stack, the values ​​of these variables, etc.

[0043] In some implementations, the runtime translation portion of the 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 abstract runtime layer is not necessarily the same as the call stack at the abstract 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.

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

[0045] Like any other process, the runtime can be tracked. However, debugging software other than the runtime is more common than debugging the runtime, and unless otherwise stated, it is assumed that the tracking process can exclude some or all of the code as a part of the runtime itself. The tracking file 420 only tracks the execution of the process that depends on the runtime and does not track the runtime itself. The tracking file 420 does not fully support reading the value of the runtime management object from the tracking file by conventional debugging methods. There is no runtime for the debugger to fully associate the memory location with the object and other variables, so that the memory value disclosed by the tracking is meaningful. In order to control the execution of the real-time process that depends on the code being executed at the runtime, the debugger can send a message requesting an operation to the runtime, and the requested operation is such as "step" (step) or "run" (run), and then the debugger performs the operation on behalf of the debugger at the runtime. This functionality is not applicable to the tracking file without the current execution runtime.

[0046] Dump files 218 and snapshots 216 are similar to traces in that the runtime is not available. The runtime may be present in a dump or snapshot or trace, but it is not executing and therefore cannot be called.

[0047] Nevertheless, the trace file 420 can be used as part of the debugging environment. Some trace-based debugging tools extend the power of debugging so that the debugger can read the memory 112 from the trace file at multiple points in execution time selected 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 data structures at runtime. This allows inspection of high-level procedures.

[0048] In some cases, a developer may use a "time travel" debugger to control execution replay to run forward in execution time or run backward in execution time when replaying a recorded trace 220, thereby taking advantage of the debugger's ability to present memory in a useful high-level (e.g., named and data type-based) variable presentation form, not only for snapshots as before, but now for continuously replaying segments of execution time recorded during code execution. The memory values ​​captured in the trace can then be inspected by the developer in a high-level presentation at multiple points based on the low-level data recorded in the trace file. Of course, memory inspection requires reading memory cell values ​​from the trace, or reading other values, and somehow obtaining useful information from them about the memory values ​​sought during replay. Heuristics can help debuggers and other tools obtain useful information about memory values, even when the trace does not explicitly declare the value at the desired point in execution time.

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

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

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

[0052] Some may view some of the embodiments described herein in a broader context. For example, concepts such as disabling, distance, enabling, size, and tracking may be considered relevant to a particular embodiment. However, exclusivity is not sought from the broad context in which abstract concepts are sought; they are not. Rather, the present disclosure is focused on providing appropriate specific embodiments whose technical effects fully or partially address specific technical problems, such as identifying tradeoffs, pursuing a selected balance between tracked program performance, tracking execution slowdown, tracking relevance, and tracking size, and implementation mechanisms that assist in the pursuit of the selected balance. Other media, systems, and methods involving disabling, distance, enabling, size, or tracking are not within the current scope. Therefore, with a proper understanding of the present disclosure, ambiguity, mere abstraction, lack of technical features, and attendant proof problems are also avoided.

[0053] Technical features

[0054] 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 attentive readers in a variety of ways. Some embodiments are devoted to technical activities rooted in computing technology and improving the functionality of computing systems. For example, some embodiments help debug systems by making debug tracing more efficient. Some embodiments mitigate performance degradation in systems when tracing the execution of these systems.

[0055] For example, some embodiments help reduce the amount of irrelevant or uninteresting execution traces that developers must sift through to find bugs. By reducing storage requirements for trace files without omitting relevant trace data, some embodiments make efficient tracing possible even when it would not otherwise be possible due to limitations on available storage.

[0056] Furthermore, some embodiments allow developers more time to perform debugging analysis in a given work cycle by allowing the traced program to run at full speed when it performs undebugged operations. Developers spend less time waiting when the tool traces uninteresting operations (such as garbage collection, JIT compilation, or standard library routines) that are part of the execution but are unlikely to contain the defect being sought. The time saved by reducing irrelevant tracing can be used for code replay, inspection of variables, and other debugging analysis.

[0057] Some embodiments include technical components, such as computing hardware, that interact with software in ways that go 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 use a trace disable distance variable and one or more associated thresholds to implement the selective tracking algorithm steps as disclosed herein.

[0058] Some embodiments provide technical effects including more efficient use of debugging time by developers, reduced trace file sizes, and reduced slowdown of trace program execution.

[0059] Some embodiments include technical adaptations, such as trace disable distance variables, routines, and other mechanisms to modify or check trace disable distance variables. 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 tracing code that is not helpful for a particular debugging effort.

[0060] Other advantages of the technical features based on the teachings will also be clear to those skilled in the art from the description provided.

[0061] Acronyms and Abbreviations

[0062] Some acronyms and abbreviations are defined below. Other abbreviations may be defined elsewhere herein or may be understood by those skilled in the art without any definition.

[0063] ALU: Arithmetic and Logic Unit

[0064] API: Application Programming Interface

[0065] BIOS: Basic Input / Output System

[0066] CD: Compact Disc

[0067] CPU: Central Processing Unit

[0068] DV: Distance variable, as in Track Disable Distance Variable

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

[0070] FPGA: Field Programmable Gate Array

[0071] FPU: Floating Point Processing Unit

[0072] GPU: Graphics Processing Unit

[0073] GUI: Graphical User Interface

[0074] ID: Identifier

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

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

[0077] OS: Operating System

[0078] RAM: Random Access Memory

[0079] ROM: Read Only Memory

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

[0081] "()" 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, Fig.13 The "A", "B", "B1", "C", and "C2" in the example refer to routines.

[0082] Additional terms

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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).

[0087] 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.

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

[0089] "Code" refers to processor instructions, data (including constants, variables, and data structures), or both. "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."

[0090] "Program" is used broadly herein to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by a programmer (also called a developer) and / or automatically generated.

[0091] "Services" means consumable programs provided in a cloud computing environment or other network environment.

[0092] "Execution time point" refers to a specific point in the execution of a processing unit or thread, especially in relation to tracking execution. References to "specific execution time" or "execution time t" and the like in this document are references to execution time points. For example, the execution time point can be implemented as a time code variable or time code value, or as a relative position in other records of tracking or execution activities. An execution time point ta being "earlier than" or "later than" an execution time point tb means that the relative order of the two execution time points is determined. Similarly, a "younger" execution time point is an execution time point that is later than an "older" execution time point.

[0093] The information in a trace about the order of traced events may be incomplete. Thus, a trace may have enough information to establish that event A is earlier than event B, or that event D is later than event C. But the relative order of events may also be partially or completely uncertain with respect to the trace. A trace may show that event E does not follow event F, but this does not necessarily mean that E precedes F; similarly, a trace may show that event K does not follow event J, but no trace also shows that K follows J. A trace may also lack sufficient information to establish any order of two specific events relative to each other.

[0094] "Timecode" means a monotonically varying value that can be used to impose an order on at least some events in an execution trace. It is expected that timecodes are typically monotonically increasing values, but timecodes can also be implemented as monotonically decreasing values. Some examples of timecodes include instruction counters, clock times (a.k.a. clock ticks), and completely artificial (not register or instruction based) monotonic values. Depending on the trace, all, some, or no trace events may have corresponding associated timecodes. When timecodes exist, they may be unique, or they may simply be monotonic because some timecode values ​​repeat.

[0095] A "memory cell" refers to an addressable unit of memory. Some examples include a byte or word in RAM or ROM, a processor register, a cache line, and other addressable memory cells.

[0096] An "emulator" performs an "emulation" that provides the same functionality as the original hardware, but uses 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 has a different implementation than the original CPU, e.g., the emulator may run on completely different physical hardware.

[0097] "Logging" and "tracing" are used interchangeably herein to refer to the action of creating or extending a trace.

[0098] As used herein, "comprising" allows for additional elements (ie, comprising means including) unless stated otherwise.

[0099] "Optimization" means improvement, not necessarily perfection. For example, a program or algorithm that has already been optimized can be further improved.

[0100] For example, "process" is sometimes used herein as a term in the field of computer science and in a technical sense covers 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, for example, when describing a process claim as opposed to a system claim or an article (configured storage medium) claim. Similarly, "method" is sometimes used herein as a technical term in the field of computer science (a "routine") and as a term in the field of patent law ("process"). Those skilled in the art will understand the meaning intended to be used in a particular case, and will also understand that a given claimed process or method (in the patent law sense) can sometimes be implemented using one or more processes or methods (in the computer science sense).

[0101] In contrast to no automation, "automatically" means utilizing automation (e.g., general-purpose computing hardware configured by software for the specific operations and technical effects discussed herein). In particular, the steps performed "automatically" are not performed manually on paper or in a person's mind, although they may be initiated by a person or guided interactively by a person. The automated steps are performed by a machine in order to obtain one or more technical effects that would not be achievable without utilizing the technical interactions so provided.

[0102] The skilled person understands that the technical effect is the presumed purpose of the technical embodiment. For example, in one embodiment, calculations are involved, and some calculations can also be performed without a technical component (for example, by paper and pencil, or even as a mental step), and this fact 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 in this article as requiring and providing speed and accuracy that human thinking steps cannot obtain in addition to their inherent digital nature (human thinking cannot directly interact with the execution process or tracking files). This is well understood by those skilled in the art, but others may sometimes benefit from being informed or reminded of the fact. Unless otherwise stated, contrary to a simple thought experiment, the embodiments are assumed to be able to operate on a large scale in a production environment or in a test laboratory in a production environment.

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

[0104] "Actively" means without direct request from the user. In fact, the user may not even be aware that active steps of the embodiments are possible until the results of the step have been presented to the user. Unless otherwise stated, any computational and / or automatic steps described herein may also be performed actively.

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

[0106] For purposes of U.S. law and practice, use of the word "step" herein, in the claims or elsewhere, is not intended to invoke means-plus-function, step-plus-function, or 35 U.S.C. 112(f) requirements. Any presumption to such effect is hereby expressly rebutted.

[0107] For purposes of U.S. law and practice, unless claims use the phrase “means for,” they are not intended to invoke a means-plus-function interpretation. Claim language that is intended to be interpreted as means-plus-function language, if any, will expressly recite that intent through the use of the phrase “means for.” When a means-plus-function interpretation is employed, whether through the use of “means for” and / or through a court’s legal interpretation of the claim language, the means enumerated in the specification for a given noun or a given verb should be understood to be linked to the claim language and are linked hereto by any of the following: appearing in the same box in a block diagram of the accompanying drawings, being represented by the same or similar name, being represented by the same figure number. For example, if a “zac widget” is recited in a claim limitation, and that claim limitation is subject to a means-plus-function interpretation, then all structure identified anywhere in the specification where “zac widget” is mentioned, or bound together by any figure number assigned to the zac widget, at least in any block, paragraph, or example, should be considered part of the structure identified in the zac widget application and help define the set of equivalents for the zac widget structure.

[0108] Throughout this document, unless explicitly stated otherwise, any reference to a step in a process assumes that the step may be performed directly by the interested party, and / or performed indirectly by a party through an intervening mechanism and / or intervening entity, and still fall within the scope of the step. That is, unless explicitly stated to be performed directly, the step need not be performed directly by the interested party. For example, steps involving actions related to a destination or other subject matter of the interested party (such as associating, configuring, confirming, connecting, controlling, copying, decrementing, specifying, disabling, embedding, enabling, entering, executing, exiting, installing, calling, measuring, moving, recording, running, satisfying, selecting, setting, tracking, adjusting, using (and associating, associated, configuring, configured, etc.) may involve intervening actions of another party, such as forwarding, copying, uploading, downloading, encoding, decoding, compressing, decompressing, encrypting, decrypting, authenticating, calling, etc., but should still be understood to be performed directly by the interested party.

[0109] Whenever reference is made to data or instructions, it should be understood that these items configure computer-readable memory and / or computer-readable storage media, for example, to transform it into a specific article, as opposed to simply existing on paper, in one's mind, as energy alone, or as a signal propagating on a wire. For purposes of U.S. patent protection, memory or other computer-readable storage media are not propagating signals, carrier waves, or mere energy outside the scope of patentable subject matter, as interpreted by the U.S. Patent and Trademark Office (USPTO) in re Nuijten. In the United States, no claim covers the signal itself, and any claim interpretation asserting the contrary is unreasonable. Unless expressly stated otherwise in a claim issued outside the United States, the claim does not cover the signal itself.

[0110] Furthermore, despite explicit provisions to the contrary elsewhere herein, the distinct distinction between (a) computer-readable storage media and computer-readable memory and (b) transmission media (also known as signal media or energy only) should be understood. Transmission media are propagating signals or carrier wave computer-readable media or energy only. In contrast, computer-readable storage media and computer-readable memory are not propagating signals or carrier wave computer-readable media. Unless otherwise expressly stated in the claims, "computer-readable medium" means computer-readable storage media, not propagating signals per se, nor energy only.

[0111] The "embodiments" herein are examples. The term "embodiments" is not interchangeable with "the present invention." The embodiments may freely share or borrow aspects to create other embodiments (as long as the result is operable), even if the resulting combination of aspects is not explicitly described herein itself. It is not necessary for every permissible combination to be clearly described to a person skilled in the art, contrary to the policy of recognizing that patent specifications are written for those skilled in the art. Formal combinatorial calculations and informal intuition about the number of possible combinations resulting from even a small number of combinable features will indicate that there are a large number of aspect combinations of the aspects described herein. Therefore, requiring an explicit recitation of each combination runs counter to the policy of requiring concise patent specifications and making the reader knowledgeable about the relevant technical field.

[0112] Reference numerals list

[0113] The following list is provided for the convenience and support of the drawings and as part of the specification text, which describes the innovation by reference to multiple items. Nevertheless, items not listed here may still be part of a given embodiment. In order to make the text clearer and easier to read, reference is made to given reference numerals near some (but not all) reference items in the text. The same reference numerals may be used to refer to different examples or different instances of a given item. The list of reference numerals is:

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

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

[0116] 104: User

[0117] 106: Peripheral devices

[0118] 108: Usually the Internet

[0119] 110: Processor

[0120] 112: Computer-readable storage media, such as RAM, hard disk

[0121] 114: Configured as a removable computer-readable storage medium

[0122] 116: Instructions executable by a processor; may be on removable media or in other memory (volatile or nonvolatile or both)

[0123] 118: Data

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

[0125] 122: Tools, such as antivirus software, profilers, debuggers, execution tracers, editors, compilers, interpreters, security penetration testers, fuzzers, etc.; can be adapted to use the selective tracing controls taught herein

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

[0127] 126: Display

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

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

[0130] 202: Debugger

[0131] 204: Execution Tracer

[0132] 206: Real-time debugging of a program or process

[0133] 208: Managed Code

[0134] 210: Runtime

[0135] 212: Memory items, such as application or system data structures

[0136] 214: Duplicates of some or all storage items

[0137] 216: Storage snapshot; may include additional information such as indexes or metadata

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

[0139] 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 so solid lines are shown for the boxes of generally trace data 454 .

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

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

[0142] 422: Accurate tracking data in tracking

[0143] 424: Time code, in a trace, identifying a particular 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 an execution time point associated with a declared operation at a declared memory address involving a declared data value; the time code may be implemented, e.g., as clock ticks or an instruction counter; some traces may contain a unique time code for each recorded operation, but time codes may also be repeated or omitted in some trace data

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

[0145] 430: Indexes into the data in the trace file, such as reverse lookup data structures for quickly identifying trace attributes, memory life index information, and other searchable lists of locations in the trace data that may be of particular interest

[0146] 432: Keyframes in tracking data; for example, may be present at fixed intervals in the tracking data to permit playback to jump to a tracking playback at (or near) a keyframe more quickly.

[0147] 434: Executed code, e.g., opcodes and parameters of the debuggee's machine-level code executed by the processor while the debuggee is running and being traced

[0148] 436: Stack activity, which occurs when the debuggee is running and being traced, such as stack growth, stack shrinkage, and the execution time at which the activity occurs

[0149] 438: data stream; may correspond to a single thread or a group of threads, may correspond to a processor unit (e.g., a processor core); may correspond to all cores in a given processor socket; may be annotated with metadata to aid replay

[0150] 440: Processor core activity, which occurs while the debuggee is running and being traced, for example, the opcodes and parameters of the instructions executed by the core

[0151] 442: Processor socket activity, which occurs while the debuggee is running and being traced, e.g., the opcodes and parameters of instructions executed by any core located in a given processor socket

[0152] 444: Thread activity, which occurs while the debuggee is running and being traced, e.g., instructions executed while the thread is running, memory unit accesses made while the thread is running, and associated metadata (such as thread ID and time code)

[0153] 446: Register activity, which occurs when the debuggee is running and being traced, for example, what value is read from which register at what time code, and what value is written to which register at what time code

[0154] 448: memory address

[0155] 450: instruction opcode

[0156] 452: Data value

[0157] 454: General tracking data

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

[0159] 458: Tracking entry

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

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

[0162] 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 using the allocation of stack memory in the system, which in a given system may be an upward direction (i.e., addresses increase as items are pushed onto the stack), but in another system it may also be downward (i.e., addresses decrease as items are pushed onto the stack); the term "growing" herein refers to in the direction of stack growth on the system in question, while "shrinking" refers to in the opposite direction

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

[0164] 510: Heap memory, which is allocated and released as objects are constructed and released; in some cases, the heap can be automatically garbage collected, which identifies and marks as free memory that holds objects that are no longer accessible during the real-time execution of the process; in other cases, memory allocated from the heap requires a separate explicit call to release the allocated memory.

[0165] 512: Object

[0166] 514: Cache memory; for example, it can be in RAM working memory or on the processor chip

[0167] 516: Registers in the processor core

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

[0169] 520: ROM (read-only memory); usually nonvolatile

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

[0171] 524: RAM (random access memory); usually volatile

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

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

[0174] 530: Characteristics of the 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 with respect to other threads, whether it is in shared memory (such as memory that is global with respect to multiple threads)

[0175] 602: Thread

[0176] 604: Thread ID

[0177] 606: thread status, for example, created, runnable, running, suspended, blocked, terminated

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

[0179] 610: Thread memory, for example, memory that is local to a thread or memory that is global to a thread and is accessed by the thread while the thread is executing.

[0180] 700: trace controller, also known as tracing controller

[0181] 702: The part of the traced process that is specified to be traced

[0182] 704: Criteria for specifying which parts to track or not track

[0183] 706: Portions of the tracked process that are not specified to be tracked, including portions that are explicitly specified not to be tracked and portions that are implicitly specified not to be tracked (because they are not explicitly specified to be tracked)

[0184] 708: Libraries containing code other than the user code being debugged, for example, standard libraries or libraries for any debugging that are the responsibility of a different developer

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

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

[0187] 714: Modifications to executable code to control tracing, for example, calls to trace enablers, calls to trace disablers, calls to set or check trace disable distance variables

[0188] 716: Trace disabler, that is, the routine that it calls to stop tracing

[0189] 718: Trace enabler, that is, the routine that is called to start tracing

[0190] 720: Tracking disabled distance variable

[0191] 722: stop tracking value; when the tracking disable distance variable reaches this value, the tracking disabler will be called; it is expected that this stop tracking value is usually zero

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

[0193] 726: A high count threshold for the value in the distance variable that can be used to indicate in a newly entered code unit that it is being tracked

[0194] 728: A low count threshold for the value in the distance variable can be used to maintain the trace state long after exiting a code unit that was traced long enough to encounter an indication in a newly entered code unit that was also traced, and if such an indication exists, otherwise cause tracing to be disabled unless control passes (backward or downward) to the code that was specified to be traced.

[0195] 730: Tracking status, that is, tracking is enabled or disabled

[0196] 731: Create Task modifier, which may inject code, patch code, insert breakpoints, or control the selection of an alternative version of code, so that the Create Task function includes the setting of a value indicating that the created task will be recorded under certain circumstances, such as if the currently executing task or thread itself is being recorded, which task or thread called the Create Task function in its context

[0197] 732: An execution task modifier that can inject code, patch code, insert breakpoints, or control the selection of different codes so that the execution task function includes instructions, calls, or other triggers that result in recording of the tasks performed by the execution task function if the recording indicator indicates that the tasks performed by the execution task function should be recorded.

[0198] 740: Task recording indicator, i.e., a value in the form of a variable or stored in a table or database, which indicates whether the task is recorded, including whether it is currently being recorded, will be recorded in the future, or has been recorded in the past

[0199] 802: is a variation of system 102 that lacks or does not utilize the distance variable aspect of trace controller 700 that limits the invocation of the trace disabler and trace enabler taught herein; instead, the variation explicitly calls the trace enabler upon entry into each portion of code to be traced, and explicitly calls the trace disabler upon exit from each portion of code to be traced

[0200] 804: Computational cost, measured, for example, in processor cycles, instruction counts, or system clock time, or in the number of trace 220 entries 458

[0201] 806: Computational cost, which is the computational cost of tracing at least a specified portion of the code using the distance variable aspect of the trace controller 700, which limits the invocation of the trace disabler and trace enabler taught herein

[0202] 808: Computational cost, which is the computational cost of tracing at least a specified portion of the code without using the distance variable aspect of the trace controller 700, which limits the calling of the trace disabler and trace enabler taught herein

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

[0204] 904: local-N, parameters to set-N() routines

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

[0206] 908: Local variables N in some implementations of the tracking controller

[0207] 910: The set-DV() routine in some implementations of the tracking controller is used to set the value of the tracking disable distance variable

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

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

[0210] 916: try-to-trace() routine in some implementations of the trace controller to enable tracing if it is not already enabled

[0211] 1000: Tracking state diagram showing the tracking control behavior in some implementations

[0212] 1002: Trace-on state, that is, a state in which tracing is enabled

[0213] 1004: Trace-off state, that is, a state in which tracing is disabled

[0214] 1006: Execute the instructions of the process being traced; it can also refer to executing a larger part of the process, or the entire process

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

[0216] 1010: Calling trace enabler; also specifying execution trace enabler

[0217] 1012: Record execution information into the trace

[0218] 1014: Decremented the tracking disabled distance variable, or otherwise moved the value of the distance variable to approach the stop tracking value

[0219] 1016: Trace disabler called; execution trace disabler also specified

[0220] 1100: Code unit

[0221] 1102: Function

[0222] 1104: Routine

[0223] 1106: Coroutine

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

[0225] 1110: Interrupt handler

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

[0227] 1114: Virtual Methods

[0228] 1116: Implementation of Virtual Methods

[0229] 1118: Callback

[0230] 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

[0231] 1122: Library

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

[0233] 1200: Aspects of the code related to using the trace disable distance variable to control which parts of the process are recorded into the trace

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

[0235] 1204: Exit point of a routine or other unit of code

[0236] 1206: The caller of the routine

[0237] 1208: Current execution point in a routine or other code unit

[0238] 1210: Tuning condition for tuning the tradeoffs when using a trace disable distance variable to control which parts of a process are recorded in a trace, e.g., tuning how much uninteresting code is traced and how many processor cycles are spent disabling and re-enabling trace; also refers to using such a condition to tune the trace thresholds 726, 728

[0239] 1216: Track the value of the invalid distance variable; however, as with developers, for convenience, the value of a variable is sometimes indicated here by simply referencing the variable rather than explicitly referring to the value of the variable, for example, a reference to a variable N refers to both the variable (the allocated and identified storage) and the value held in the variable, and the technician will understand from the context which reference is intended.

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

[0241] 1220: Information about the computational cost of turning tracing on or off, for example, the length of a trace enabler or trace disabler (in instructions / processor cycles)

[0242] 1300: Computational Cost Comparison Example

[0243] 1400: Method to configure the system to control tracking by using the tracking disable distance variable

[0244] 1402: Configure the system to control tracking by using the tracking disable distance variable

[0245] 1404: Control tracking by using the tracking disable distance variable

[0246] 1406: Use tracking to disable distance variables

[0247] 1408: Embed count-ensure code in procedures

[0248] 1410: High Count Ensure Code

[0249] 1412: Location in code

[0250] 1414: Low Count Assurance Code

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

[0252] 1418: Instruction counter

[0253] 1420: Connect an execution tracer to a process or its code

[0254] 1422: Install callback to pass control to execution tracer

[0255] 1424: Configuring Tracking Controller

[0256] 1426: Disable tracking, for example by involving a tracking disabler

[0257] 1428: The tracking value reached zero or otherwise stopped due to a change in the value of the distance variable (e.g., due to a decrement of the distance variable).

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

[0259] 1500: Method to control tracking by using tracking disable distance variable

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

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

[0262] 1600: Flowchart

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

[0264] 1604: Designate a code unit as part of a process (e.g., program) that is not to be traced, or as part of a process that is not required (optionally included) in the trace

[0265] 1606: Verify that the tracking disabled distance variable is not at a stop tracking value, e.g. the distance variable is non-zero

[0266] 1608: Computational cost measured, for example, in processor cycles 1610, instruction counts 1612, or system clock elapsed time 1614

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

[0268] 1618: Run (aka execute) native code

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

[0270] 1622: Use try-to-trace(), or an equivalent but differently named function, as part of a trace control

[0271] 1624: Using logical infinity as a relatively high value in the tracking disabled distance variable

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

[0273] 1628: Use information about executable routine size when controlling tracing 1218

[0274] 1630: Select low count threshold

[0275] 1632: Select high count threshold

[0276] 1634: Meet the adjustment conditions 1210

[0277] 1636: Sample the execution of a procedure into a trace

[0278] 1638: Calling routine

[0279] 1640: Entering routine

[0280] 1642: Exit routine

[0281] 1646: Compile code

[0282] 1648: Redirect function call

[0283] 1650: Identifies a routine or other unit of code as one that is designated for tracing

[0284] 1700: Method for configuring a system to control tracking by using a task record indicator 1702: System configured to control tracking by using a task record indicator

[0285] 1704: Controlling tracing by using task record indicators

[0286] 1706: Using Task Record Indicator

[0287] 1708: Detect the call of the create task function

[0288] 1710: Modify the create task function

[0289] 1712: Set task record indicator

[0290] 1714: Detect calls to the execute task function

[0291] 1716: Modify the execution task function

[0292] 1718: Call task tracking

[0293] Operating Environment

[0294] refer to Figure 1 , an operating environment 100 for an embodiment includes at least one computer system 102. 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, which may be clustered in a cloud, client-server networked, and / or peer-to-peer networked. An individual machine is a computer system, as is a group of cooperating machines. A given computer system 102 may be configured, for example, for end users with applications, for administrators, as a server, as a distributed processing node, and / or in other ways.

[0295] Human users 104 can interact with computer system 102 via typed text, touch, voice, movement, computer vision, gestures, and / or other forms of I / O using displays, keyboards, and other peripherals 106. Screen 126 can be a movable peripheral 106, or can be an integral part of system 102. A user interface can support interaction between an embodiment and one or more human users. A 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.

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

[0297] Each computer system 102 includes at least one processor 110. As with 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, local fixed media, removable media, magnetic media, optical media, solid-state media, and / or other types of physical persistent storage media (as opposed to only propagating media signals). Specifically, when inserted or otherwise installed, the configured media 114 (such as a portable (i.e., external) hard drive, CD, DVD, memory 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 the processor 110 and use by the processor 110. The removable configured media 114 is an example of a computer-readable storage medium 112. Some other examples of computer-readable storage media 112 include built-in RAM, ROM, hard disk, and other memory storage devices that are not readily removable by the user 104. For purposes of compliance with current US patent requirements, under any claim pending or issued in the US, neither the computer-readable medium, computer-readable storage medium, nor the computer-readable memory is a signal per se, or merely energy.

[0298] For example, the medium 114 is configured with binary instructions 116 executable by the processor 110; "executable" is used in a broad sense herein 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 technical effect by the execution of the instructions 116. The instructions 116 and 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 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 is also converted through backup, restore, submission, suspension, reformatting, and / or other technical operations.

[0299] Although the embodiments can be described as being 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), this description does not represent an exhaustive list of all possible embodiments. It will be appreciated by those skilled in the art that the same or similar functions can also be implemented in whole or in part directly in hardware logic to provide the same or similar technical effects. Alternatively, or in addition to software implementations, the technical functionality described herein can be at least partially performed by one or more hardware logic components. For example, and without excluding other implementations, the 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, they can be grouped into interactive functional modules based on the input, output, and / or their technical effects of the components of the embodiments.

[0300] In addition to the processor 110 (e.g., CPU, ALU, FPU and / or GPU), memory / storage medium 112, and display 126, the operating environment may also include other hardware 128, such as batteries, buses, power supplies, wired and wireless network interface cards. The terms "screen" and "display" are used interchangeably herein. The display 126 may include one or more touch screens, a screen that responds to input from a pen or tablet computer, or a screen that is only used for output. In some embodiments, peripheral devices 106 such as human user I / O devices (screens, keyboards, mice, tablet computers, microphones, speakers, motion sensors, etc.) will be in operable communication with one or more processors 110 and memory. The software process may be a user 104.

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

[0302] Those skilled in the art will appreciate that the foregoing aspects and other aspects presented herein in the context of an "operating environment" may form part of a given embodiment. The headings of this document are not intended to strictly categorize features into embodiment and non-embodiment feature sets.

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

[0304] Tracking Environment

[0305] Figure 2 and 3 The real-time process environment is shown respectively; Figure 2 shows managed code 208, and Figure 3 Native code 308 is shown. These environments 200, 300 are also discussed in detail above. Of particular interest here are the tracer 204 and the traces 220 produced by the tracer 204. The tracer 204 and the traces 220 may include familiar aspects, but they will also reflect and benefit from the selective tracing innovations taught herein.

[0306] In each environment 200, 300, there is a tracer 204. The tracer 204 is originally designed and implemented or has been adapted to perform selective tracing as taught herein. A debugger 202 may also be present in one or both of the environments 200, 300. If present, the debugger may be integrated with the tracer to perform tracing during debugging, or the debugger may only be able to read traces 220 previously created by the tracer.

[0307] track

[0308] like Figure 4As shown, trace 220 may be stored in one or more files 420, and may include various kinds of trace data, as well as metadata that supports or defines searches on the trace data. Part or all of trace 220 may also reside in RAM. Some examples of trace data include bit-accurate trace data 422 (such as a copy of low-level instructions and their operands), a time code 424 that can be used to order trace data items relative to each other, a memory snapshot 216 or dump 218, an index 430 into the raw trace data, key frames 432 inserted into the raw trace data at specified intervals, a copy of the code 434 executed by the debuggee during the trace, stack activity 436, data streams 438 read or written by the debuggee while tracing, processor activity on a per-core 440 or per-socket (multiple cores) 442 basis, thread activity 444 while tracing, register reads and writes 446 while tracing, a tuple 456 associating a memory address 448 with an instruction 450 and one or more values ​​452 and optionally also 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 of items 216, 422, 434, 436, 438, 440, 442, 444, 446, 456 qualifies as a trace "entry" 458. In some, any minimal portion of trace data 454 that by itself represents a state change of the trace program qualifies as 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.

[0309] Some tracing processes record only two kinds of data. One kind of data recorded is the execution of code instructions 116, potentially executed in parallel on multiple threads. Another kind of data recorded is snapshots 216 of specific blocks of memory taken at discrete points in execution time, for example, 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 recorded instructions and all of their inputs and outputs. The recording of the trace 220 can be made efficient by relying on the determinism of the (multiple) processors 110 and recording primarily information that cannot be inferred based on that determinism and information that has already been recorded in the trace 220. Most of the trace 220 in some implementations is data, rather than the executed code instructions; such data is typically non-deterministic. The trace can be primarily seed data plus non-deterministic information. In some cases, only information that hits the (multiple) processors being traced is recorded in the trace 220, for example, a read of a value V in a processor register is entered in the trace, but a write of the value V from the register to a memory location X does not have to be entered in the trace. If the write operation to X makes a difference in the behavior of the program being traced, it is because, at some time, the written value is returned from X to the processor register, at which time, if tracing is still enabled, an entry in the trace 220 can be made.

[0310] Figure 5 Various memories 112 are shown that may be tracked and therefore amenable to inspection according to the teachings herein. Examples of memory units 502 shown include a stack 504 (including data such as its base address 506 and allocated stack frames 508), heap contents 510 such as objects 512, or metadata such as garbage collection data, caches 514, processor registers 516, object members such as attributes 518, addressable units in ROM 520 or RAM 524, removable or third-level memory 522, local memory 526, and global memory 528. A memory unit may have one or more characteristics 530 that increase or decrease the accessibility of the memory unit, for example, the memory may be in kernel space, may be shared, may be amenable to DMA, etc.

[0311] Figure 6 Thread 602 activity information 444 is shown that may be captured in a given trace 220. Thread identifier 604, thread state indication 606, executable code 608 for the thread, and memory unit 502 state information 610 (such as thread local variables and their identifiers) are shown.

[0312] More about the system

[0313] Examples are provided herein to help illustrate various aspects of the technology, but the examples given in 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 may include, for example, additional or different technical features, mechanisms, sequences, or data structures, and may otherwise depart from the examples provided herein.

[0314] Figure 7 A system 102 configured for selective tracing as taught herein is shown. One or more portions 702 of code are designated for tracing using one or more specified criteria 704. For example, the criteria 704 may include a list of function names or identifiers, file names, object names, method names, module names, routine names, or other identifications of portions 702 that the developer wishes to include in tracing. The criteria may also or alternatively include attributes or special instructions located within the code of the process that may be identified by a runtime or debugger during the execution of the process and used to trigger tracing. "Included in tracing" and similar phrases herein mean that tracing is enabled or will be enabled when the code in the specified portion is executed. In particular, the criteria 704 may specify "user code" so that execution tracing is substantially limited to software that is considered "user code", where "substantially" means that 90% (or other specific administrator-selected value) of the traced code is user code. Compliant user code may 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 may also be determined automatically by excluding well-known standard libraries. After a thread of execution exits "user code", tracing is temporarily suspended and resumed when the user code is re-entered. Some embodiments support execution tracing based on user-configured scopes. A user can configure tracing to be enabled for short periods of time, for example, for the execution of a single function, the execution of a single web request, or between user-defined points in the process code.

[0315] Other parts of the process 706 may be implicitly or explicitly specified for exclusion from tracing. For example, a developer may set specified criteria 704 to exclude any or all of the following from tracing: non-user code libraries 708 (such as standard libraries or third-party libraries), kernel 120 code, compiler 710 code (including, for example, a preprocessor, the compiler itself, an assembler, a linker, an interpreter), or garbage collection code 712.

[0316] Unless otherwise noted, excluding portion 706 from the trace is a goal or preference, but not a requirement. That is, it is expected that many (if not all) implementations of the teachings herein will tend to over-include in the trace relative to under-inclusion. By design, these implementations will operate on the basis that including more traces than specified is better than omitting from the trace what is specified for tracing. However, the teachings herein may also be applied in other implementations.

[0317] The illustrated system 102 includes a tracker 204 configured with a tracking controller 700. Aspects of the tracker 204 may be familiar, while other aspects include or use selective tracking modifications 714. Familiar trackers may have a tracking enabler 718, a tracking disabler 716, and a tracking state 730, for example, although they have not been previously used for selective tracking in accordance with the teachings herein. Some examples of innovative selective tracking modifications 714 that may 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, a task record indicator 740 for one or more tasks, a create task modifier 731 that may change how a create task function operates, an execute task modifier 732 that may change how an execute task function operates, routines that are functionally equivalent to combining Fig. 9 The code and changes described above are combined Fig.10 The code for tracking state 730, counting guarantee code 1120, and implementing one or more adjustment conditions 1210 described above, such as in combination with Figure 13-16 Code to operate as described in one or more of the figures, and as combined Fig.17 Code that operates as described.

[0318] According to one aspect, the selective tracing modification 714 includes or uses a distance variable 720. There may be a single distance variable in the tracing process, or there may be multiple distance variables, such as one for each 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 tracing is implemented using two or more distance variables that can independently disable tracing. Those skilled in the art will also understand that in a given implementation, the distance variable may be given a variety of names. Here, it is referred to as a "distance variable" simply to remind people of a description of its usage: One way to describe a suitable use is to interpret the distance variable as a measure of the computational distance from the operation for which tracing is to be turned off. The larger the value in the distance variable, the more tracing will be performed, and conversely, when the distance variable reaches zero (or some other stop tracing value 722), tracing will be disabled.

[0319] According to another aspect, the selective tracking modification 714 includes or uses a flag, Boolean value or other identifier to indicate that a task is being tracked, such as a task record indicator 740. More specifically, a function identified as being to be tracked (such as a function explicitly enumerated or identified by the (multiple) parts designated for tracking 702, or a function that meets the specified criteria 704) can create and execute one or more tasks, including asynchronously executing tasks across different processes and / or threads at indeterminate times. As used herein, the term "asynchronously executing tasks" or "asynchronous tasks" refers to executing enumerated code at different and indeterminate times and within different processes and / or threads. The creation of a task can be performed by a create task function, which can be modified by a create task modifier 731 to include a check as to whether the task or thread itself is being tracked, and the create task function is being called in the execution context of the task or thread. If so, even if such a newly created task will be executed asynchronously, the task record indicator 740 can also be updated to include an indication that the newly created task will also be tracked. Subsequently, when the newly created task is executed (such as asynchronously in a different execution process or execution thread), the execute task function that triggers its execution may have been or is currently modified by the execute task modifier 732 to include a check as to whether the task to be executed is marked for tracking, such as by checking one or more values ​​that are indicated by the task record indicator 740 in the task record indicator 740. Figure 7 If the execute task function modified by the execute task modifier 732 detects that the task is marked for tracing, the modified execute task function may trigger tracing, such as by the trace enabler 718, as described herein.

[0320] As utilized herein, the term "record" is synonymous with "track" at least in the sense of naming a variable identifier. Thus, for example, the term "task record indicator" is used because the corresponding variable is typically labeled with the word "record" (such as a variable named "shouldRecord") instead of the word "track." Thus, there is no patentable distinction between code that refers to "recording" and code that is "tracked," although in order to maintain specificity, the description herein primarily uses the verb "to track" to refer to the described mechanism.

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

[0322] Fig. 9 A specific design of tracking controller 700 is shown, and it should be understood that other designs may also utilize the teachings presented herein and according to Fig.10 , 13 -16 to perform the operations shown in various methods. Fig. 9 The routines and parameters shown are generalizations of a specific implementation example. The specific implementation example includes a selective tracing interface 714 having the functions described below, which runs on top of the basic execution tracing technology 204. The basic tracing technology 204 can provide: for example, Windows Event Tracing (ETW) (also called "time travel tracing" or "time travel debugging") on a system running Environment (trademarks of Efficios Inc. and Linus Torvalds, respectively) For similar Environment (trademarks of Oracle America, Inc. and X / Open Company Ltd. Corp., respectively) Tracking, and other tracking technologies 204.

[0323] The tracking control functions cited in this article include the following.

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

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

[0326] SetMaxInstructionsToRecord(maxInstructions): Instructs the underlying tracing technology to stop recording after executing maxInstructions instructions in the current thread.

[0327] GetRemainingInstructionsToRecord(): Returns the number of instructions that will be recorded on the current thread by the underlying tracing technology before stopping recording.

[0328] TryStartRecordingCurrentThread(): Instructs the underlying tracing technology to start recording the execution of the current thread (if it is not already recording).

[0329] IsRecordingCurrentThread(): Returns a value (such as a Boolean) indicating whether the current thread is being tracked, such as by using the TryStartRecordingCurrentThread() function, which calls this function in its execution context.

[0330] StopRecordingCurrentThread(): Instructs the underlying tracing technology to stop recording the execution of the current thread, if the current thread is currently being traced.

[0331] IsTaskRecording(task): Returns a value (such as a Boolean value) indicating whether the task specified by the task identifier is being tracked.

[0332] SetTaskIsRecording(shouldRecord, task): Stores a value (such as a Boolean value) into the variable shouldRecord, which indicates whether the task specified by task is set to be tracked.

[0333] In this example, configuration information 704 is provided to system 102 to specify which functions in a procedure are considered “user code.” Specifically, in this example, user code is designated for tracing, and all code of a procedure that is not explicitly designated for tracing is implicitly designated as not for tracing.

[0334] In operation according to this example, each routine that is considered "user code" is decoded at execution time. At a convenient early execution point of the thread, SetThreadInstructionsToRecord(threadInstructions) is called with a sufficiently large number of threadInstructions. The administrator 104 can determine what constitutes early, convenient, large enough, small enough, and the like as referenced herein in light of the above-mentioned tradeoffs between trace size and computational cost, and the capabilities of the decoding, injection, and recording techniques 204.

[0335] At each entry point 1202 of a function (beginning of a function, return point from a call, catch handler, etc.), insert 1408 code to:

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

[0337] CallCallTryStartRecordingCurrentThread().

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

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

[0340] Note that, for example, if GetThreadInstructionsToRecord() returns a logically infinite number, the call may cache the value specifying infinity.

[0341] Each newly inserted function is recompiled 1646 into machine executable binary code. Calls to user code functions are redirected 1648 to execute the newly compiled executable code.

[0342] When the result code is executed, the distance from the stop recording event or call 716 changes with the distance variable maxInstructions. 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 will increase again. If the exit does not pass control to another specified section, one of the two tends to occur (in this example, for simplicity, the possibility of another call in the call is ignored).

[0343] One possibility is that the entered portion 706 that is not designated for tracing may be small enough (few instructions) to pass control back to the designated portion before maxInstructions reaches zero and tracing is turned off; upon reentering the designated portion, maxInstructions will be increased again. In this case, the additional tracing (i.e., tracing of code that is not designated for tracing) will include a traversal of the entered portion 706 that is not designated for tracing.

[0344] Another possibility is that the entered portion 706 is not designated for tracing sufficiently large that maxInstructions will continue to run until it reaches zero. If this happens while control is still in the entered portion 706, then when maxInstructions reaches zero, the tracing controller 700 turns off tracing. In this case, the additional tracing will include recording of the initial portion of the entered portion 706, but not the entire traversal.

[0345] Control may eventually return to another designated portion 702, in which case tracing will be enabled again and maxInstructions will be given a relatively large value, though not necessarily the same large value given last time. Or the process may end or terminate without control being passed again to another designated portion 702, in which case tracing will remain off, or at least not be re-enabled by the selective tracing mechanism 700. Some other mechanism may re-enable tracing, but in such cases it is still best to use that other mechanism in conjunction with the tracing controller 700 to avoid unexpected or undesirable effects on the tracing 220.

[0346] Considering the above, and refocusing on Fig. 9, the SetThreadInstructionsToRecord() routine is an example of a set-N routine 902, the parameter threadInstructions is an example of a local-N parameter 904, and the thread cache variable is an example of a local variable N 908. The GetThreadInstructionsToRecord() routine is an example of a get-N routine 906. The SetMaxInstructionsToRecord() routine is an example of a set-DV routine 910, and its parameter maxInstructions is an example of a tracing-max parameter 912. The GetRemainingInstructionsToRecord() routine is an example of a get-DV routine 914. The TryStartRecordingCurrentThread() routine is an example of a try-to-trace routine 916. Here, in addition to the specific examples already given, summary items 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 specificity.

[0347] Fig.10 A trace state diagram 1000 is shown illustrating the operation of some embodiments. The trace state diagram 1000 illustrates tracing in the context of a given thread, and it is understood that the teachings herein can be applied to environments with only a single thread and to multi-threaded environments. Fig.10 Instances of the state machine can be used independently between threads with corresponding thread-local distance variables DV. Fig.10 As shown near the center of the right side of , execution of the process 206 to be traced begins with tracing in an off state 1004, which may also be referred to as a trace 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 a change in the tracing state. At some point, in this example, after executing 1006 one or more instructions, execution of the process reaches a try-to-trace() routine 916. 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. Therefore, the try-to-trace() routine sets the distance variable to a non-zero value, and calls 1010 the trace-on routine () which implements or calls the trace enabler 718 in this example. As shown in FIG. Fig.10 As shown, the trace state 730 then transitions to a trace-on state 1002, which may also be referred to as a trace-enabled state or a recording state, for example.

[0348] Control is passed to Fig.10 The execution record decrement test loop shown in the upper left. One or more instructions 116 of the process are executed 1006, and corresponding records 1012 are performed using the underlying tracing technology 204. The correspondence between individual instructions 116 and entries in the trace 220 may or may not be one-to-one. For example, the tracing technology 204 may 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 a default or configuration parameter of the underlying tracing technology 204. As the recording 1012 is performed, a corresponding decrease in distance to recording disablement is performed by decrementing 1014 a distance variable. If the distance variable reaches zero, the tracing state transitions back to the trace-off state 1004, and the trace disabler 716 is called 1016. If the process ends normally or is terminated, the tracing state 730 remains the same as when the process ended.

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

[0350] like Figure 7 As shown, some portions 702 of the code of a process may be designated to be traced, and other portions 706 may be implicitly or explicitly designated as not currently of interest and therefore not to be traced, except perhaps accidentally as a byproduct of the use of a distance variable 720. The portions 702, 706 may be code units, such as threads, libraries, etc. That is, the trace designation 704 may be implicitly or explicitly applied to the portions 702, 706, the boundaries of which are the boundaries of certain code units 1100, some of which are in Fig.11 Shown in.

[0351] like Fig.11As shown, a code unit 1100 may 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 that performs one or more tasks (including asynchronously, such as by marking the relevant code with an "async" modifier or other similar identifier in one or more other threads of execution), 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 tracing purposes, the entire kernel 120 may be a code unit.

[0352] exist Fig.11 Counting ensure code 1120 is also shown in , but this is for convenience and completeness when listing the ways in which code can be categorized. Counting ensure code 1120 includes code such as set-DV routine 910, which exists to implement tracking control, as opposed to being part of the process before the injection of tracking modification 714.

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

[0354] Fig.12Also shown are some items that affect or determine one or more adjustment conditions 1210. Adjustment conditions represent and implement a balance between the computational cost 804 of tracing, the size of tracing 220, and the designation 704 of what the developer wants to track or does not want to track. For example, adjustment conditions 1210 can be set by an administrator or by default. They can be determined based on experimental data, such as providing profile information of computational costs, or providing static analysis data of statistics about the length and length distribution of routines. Adjustment conditions 1210 can be constant throughout a particular execution of the process being tracked, or they can vary. The items involved in the selective tracking of 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, a current value 1216 of a distance variable 720, information 1218 about the computational cost of routines and other code units 1100 in the process being tracked, and information 1220 about the computational cost of turning off or turning on tracking.

[0355] As further illustration of adjusting 1210 the thresholds 726, 728, consider the following. Assume that the computational cost 804, 1220 of stopping tracing to not record a particular function (and then and then later restarting) is the equivalent of recording 1000 instructions. The distribution of instruction counts of the functions that the developer does not want to record is also a consideration. For example, assume that 90% of the functions that the developer would exclude from recording require 100 or fewer instructions to record. Adjustment can ask whether it makes sense in computational cost to set the low threshold 728 (or another count of instructions before automatically stopping recording) to 101 instead of 1. In some architectures, if the marker to continue recording must be after the function prolog, it may not be possible to set this number below the threshold, so at least the low must be high enough to fit any function prolog and 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 reconciliation information 1218 includes the likelihood 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.

[0356] In the context of this regulation discussion, the estimated reduction of 101 cost is the average cost per function (100*0.9+1101*0.1) equal to 200.1 instructions per function. If any of the recorded functions designated for exclusion had fewer than 100 instructions (which seems likely), then this number would actually be lower. The actual number is the recorded average instruction count for each function designated for exclusion, and the cost of Low being 1 is 1001 instructions per function. Therefore, the probability of a function being designated for exclusion being less than a given number, 1218, is used to support the selection of Low as the preferred number.

[0357] Assume that after setting the number to 101, an embodiment discovers that in fact 89% of the functions fit into 80 instructions. The embodiment may then dynamically lower the low value to 81 (which is actually a better choice for this data). The number of instructions may also be dynamically increased, e.g., if an embodiment observes that for 3% of the functions (30% of those are not recorded), the recording stops at the end of the function, the embodiment may increase the low value to complete these.

[0358] The distribution of probabilities 1218 can be collected in a variety of ways. One way is previous executions in the same recording session. Other sources of tuning information may be available in the form of general statistics of instruction distribution across functions in an industry, functions in a code base, or functions from previous recordings in the area.

[0359] refer to Figure 1-12 Some embodiments use or provide a selective execution tracing system, the system comprising: at least one processor 110 and a digital memory 112 in operable communication with the processor. The executable code 208, 308 is configured to perform a computer-implemented process 206 when executed. The executable code has a plurality of portions 702 designated for tracing and a plurality of other portions 706 not designated for tracing. The system also includes an execution tracer 204 having a trace disabler 716 configured to disable tracing of the execution tracer when executed, and a trace enabler 718 configured to enable tracing of the execution tracer when executed. The system also includes a trace controller 700. The trace controller 700 includes a distance variable 720 having a value indicating a currently calculated distance of execution from the trace disabler. The trace controller 700 is configured to call the trace disabler in conjunction with the distance variable having a stop trace value 722 at execution time, and subsequently call the trace enabler in conjunction with the distance variable not having a stop trace value. The distance variable modifier 724 of the system is configured to incrementally move the distance variable 720 closer to the stop tracking value as the executable code of the process 206 executes.

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

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

[0362] In some embodiments, the tracing 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 (represented herein as N) to the value of the parameter local-n when executed; a get-N routine 906 configured to return the current value of the thread local variable N when executed; 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 when executed; a get-DV routine 914 configured to return the current value of the distance variable 720 when executed; and a try-to-trace routine 916 configured to enable tracing of the current thread 602 by the execution tracer 204 when executed if tracing is not already enabled.

[0363] In some embodiments, the distance variable 720 represents a 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 executes. In addition, the trace controller 700 is configured to: call the trace disabler 716 in conjunction with the distance variable reaching zero as the stop trace value 722 when executing, and then 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., through the injection of the trace modification 714) perform at least one of the following when executing to ensure that the distance variable is not equal to the stop trace value when entering any executable code portion designated for tracing: confirm that the distance variable is non-zero, or set the distance variable to a positive high count threshold 726.

[0364] In some of these embodiments, the high count threshold 726 satisfies at least one of the following criteria: the high count threshold indicates a 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 ninety percent of the routines 1104 of the executable code, and the high count threshold exceeds the average number of instructions in the routines 1104 of the executable code. The number of instructions in a particular percentage of routines and the average number of instructions in a routine are each examples of information 1218 about the computational cost of the code.

[0365] In some embodiments, the trace controller 700 includes: external high count ensuring code 1120 in executable code at an entry point 1202 of the code unit 1100. The high count ensuring code is configured to: set the distance variable 720 to a value that is not less than the high count threshold 726 when executed. The code unit includes at least one of: a thread 602, a function 1102, a routine 1104, a coroutine 1106, an exception handler 1108, or an interrupt handler 1110. In some of these embodiments, the trace controller 700 includes low count ensuring code 1120 in executable code before a call is made to a virtual method 1114 within the code unit. The low count ensuring code is configured to: set the distance variable 720 to a non-zero value that is not greater than a non-zero low count threshold 728 when executed, the low count threshold being less than the high count threshold. The internal high count ensure code 1120 in the executable code in 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 when executed, 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 may be traced while one or more other implementations of the virtual method are not traced, or at least are not specified to be traced.

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

[0367] Those skilled in the art will appreciate that other systems are within the scope of the teachings presented herein. In particular, in some cases, other systems may use tracking controller code that performs selective tracking without using specific APIs, variables, thresholds, tracking file contents, or specified criteria in the examples described herein. Systems or devices that use any aspect or implementation of the provided selective tracking teachings are within the scope of the present disclosure, whether or not they are in the examples herein. Any claim consistent with the following should be understood to be within the claims taught herein: a selective tracking system including tracking modification or other tracking controller code that is configured to perform selective tracking operations when executed with a processor that replaces or reduces calls to a tracking disabler by using a distance variable as taught herein.

[0368] Fig.13 Cost comparison 1300 is shown, which is one of many possible examples of replacing or reducing calls to trace disablers by using distance variables. Using the distance variable (indicated by "DV"), routines A and C2 are traced using only one trace enabler call and one trace disabler call, as shown in FIG. Fig.13 Without using the distance variable, four trace enabler calls and four trace disabler calls are used to trace the same routines A and C2, as shown in Fig.13 as shown on the right.

[0369] method

[0370] Methods involving the selective tracking tools and techniques taught herein can be divided into two distinct but closely related categories: methods for configuring a system for selective tracking, and methods for performing selective tracking in a suitably configured system. Fig. 9 , 10 and 13, discussing each approach.

[0371] Fig.1414 is a flow chart illustrating an example of a selective tracing configuration method 1400 category. The method configures 1402 the system 102 for performing selective tracing. That is, the method 1400 configures the system 102 to control 1404 tracing 1012 by using 1406 the distance variable 720 and other tracing modifications 714 (e.g., stop tracing value 722, 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 may include, for example, a set-DV routine 910, a get-DV routine 914, and a try-to-trace routine 916.

[0372] The illustrated method 1400 embeds (also referred to as "inserts" or "injects") a high count guarantee code 1410 at a first location 1412 in the code 208, 308 of the process. The high count guarantee code 1410 is Fig.13 is shown as "DV = HIGH" after the TRACE-ON() call, while in Fig. 9 In the discussion of , the method 1400 is shown as a call to SetThreadInstructionsToRecord(threadInstructions) with a relatively large value for threadInstructions. In some but not all cases, the method 1400 also embeds 1408 a low count ensuring code 1414 at a second location 1412 in the code 208, 308 of the process. The low count ensuring code 1414 is Fig.13 is shown as "DV = LOW" before the call into B1, while in Fig. 9 is shown in the discussion as calling SetMaxInstructionsToRecord(e), where e is a relatively small number.

[0373] By the way, some embodiments make tracing decisions at process runtime via code injection. One technical result of this is that the same code and binary files can be used for recording during development and production without making any changes to the source code to allow tracing. Other mechanisms for implementing the above-mentioned tracing are also considered. As an example, code patches can be utilized so that the code to be traced can be modified before runtime according to the mechanism described herein. As another example, breakpoints can be inserted into the appropriate part of the code being traced. When detected, the code can be modified in the manner described herein, and then the execution of the modified code can be restored. As another example, two or more different code bases can be utilized, one of which is instrumented and modified as described herein, while the other lacks such instrumentation and modification. Then, according to the mechanism described herein, selecting which code base is executed can trigger whether tracing is executed. As another example, the tracing of code can be triggered based on conditional or other similar branches, which can remain untriggered during normal operation and have little or no effect on the execution of the code unless triggered to initiate tracing according to the mechanism described herein.

[0374] The illustrated method 1400 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 decrement software. Thus, for example, in conjunction with Fig.10 As discussed in the Execution Record Decrement Test Loop, as the procedural code executes, the distance variable is automatically modified by bringing it closer to the stop tracking value. Fig.13 No explicit description of DV decrement is given to avoid Fig.13 Readability decreases. Conversely, it can be understood that DV decreases as the code executes.

[0375] The illustrated method 1400 connects 1420 the execution tracer 204 to the executable code. For example, this can be accomplished using familiar methods to connect to ETW tools, Tools (trademark of Efficios), Tools (trademark of Oracle Corporation of America) or other familiar tracing capabilities. Some embodiments also install 1422 callbacks 1118 to the tracer 204, for example as part of a try-to-trace() routine 916 implementation.

[0376] The illustrated method 1400 configures 1424 the tracking controller 700 to disable 1426 tracking when the distance variable reaches 1428 a stop tracking value, and to enable 1430 tracking at another execution time. This step may be accomplished, for example, by inserting code that configures the process to perform a state 730 transition and otherwise operate, such as Fig.10 shown. Fig.13 and Fig. 9 The discussion of provides additional examples of configuring 1424 the system to cause enabling and disabling of tracking to occur in conjunction with the state of the distance variable 720 (whether it is a stop tracking value).

[0377] Fig.15 1400 or another suitable method. As taught herein, any method of configuring a system for selective tracking is a suitable alternative to method 1400.

[0378] Fig.15 The method shown includes setting 1502 a distance variable to a high value near the entry point 1202 as the process executes, and calling 1008 a try-to-trace routine 916. This is done, for example, by executing Fig.13 The following items are shown on the left:

[0379] Entering C2: Designated

[0380] DV = High

[0381] TRY-TO-TRACE()[enabled]

[0382] Fig.15 The illustrated method includes setting 1504 a distance variable to a low value near the exit point 1204 as the process executes. Fig.13 The setup 1504 step is illustrated by, for example, executing DV=LOW just before each exit from routine A, the exits being indicated by ENTER B1: NOT DESIGNATED and ENTER C2: DESIGNATED.

[0383] Fig.15 The method shown includes executing 1006 instructions and decrementing 1014 a distance variable as the process executes. Fig.13 This is illustrated, for example, by any of the terms on the left hand side, as they are all executed and the distance variable DV is implicitly decremented as these terms are executed.

[0384] Fig.15The illustrated method includes recording 1012 execution information into the trace 220 when the distance variable is not zero and the trace is enabled. Fig.13 This is shown, for example, by any of the terms between TRACE-ON() and TRACE-OFF(), since they are all executed when DV is non-zero and tracing is enabled. To help emphasize the behavior with DV ( Fig.13 ) and the behavior without DV ( Fig.13 The right side of Fig.13 An explicit RECORD operation is also shown in . Thus, when there is DV, B1 is recorded (indicated by RECORD B1 ), while when there is no DV, B1 is not recorded (tracing is turned off by a TRACE-OFF() call before ENTER B1 : NOT DESIGNATED).

[0385] Fig.15 The method shown includes disabling 1426 tracking when the distance variable reaches 1428 zero or another stop tracking value. This is accomplished, for example, by Fig.13 The following items shown on the left are explained:

[0386] EXECUTE UNTIL D==0

[0387] TRACE-OFF()

[0388] Fig.17 1 is a flowchart showing an example of a selective tracking configuration method 1700 that can adapt to asynchronous execution. As previously described, the execution of one or more libraries (such as library 1122) can be selectively skipped to provide the efficiency and speed advantages described herein. However, skipping such library execution may result in no tracking of asynchronously executed tasks. For example, a function being tracked can create and execute multiple tasks. Some of these tasks can be executed in different execution contexts or threads, such as if the relevant code is marked with an "asynchronous" identifier or other identifier indicating that it can be executed asynchronously. In such an example, the library 1122 code can be called, and the library-provided function (such as a create task function) can be used by the function being tracked to create a task that can be executed asynchronously. Continuing with such an example, the library 1122 code can be called again, and the library-provided function (such as an execute task function) can be used to execute the newly created task in a separate execution thread. Because, as previously described, such execution of the library-provided function can be skipped, the task being executed in a separate execution thread will not have been tracked, even if it is part of the user code specified to be tracked.

[0389] Thus, the method 1700 can configure 1702 the system 102 to control 1704 tracking 1012 by using 1706 the task recording indicator 740. The illustrated method 1700 detects 1708 a call or other trigger of a create task function by the currently executing code (such as the currently executing task or thread). Subsequently, the create task function can be modified 1710 to include a check on whether the current task or thread is being tracked. Such a modification 1710 can be performed by the create task modifier 731 via code injection. Alternatively, the create task modifier 731 can present different versions of the created task executed and include a check on whether the current task or current thread is being tracked. As another example, the create task modifier 731 can detect 1708 and interrupt the execution of the create task function using a breakpoint. Therefore, as used herein, the term "modify the create task function" refers to changing the execution of the create task function by the insertion of additional code, the execution of alternative code, or the interruption of the execution of the create task function, such as via a hardware or software breakpoint.

[0390] The check as to whether the current task or thread is being tracked may include a check of a logging indicator 740. According to one aspect, each executing task or thread may have a logging indicator 740 associated therewith, which may be a Boolean value, or a flag or other similar indicator. Alternatively, the logging indicator may be stored in a table or database per task. If the check indicates that the current task or thread is being tracked, a similar indication, such as a Boolean value, a flag, an entry in a database, etc., may be set 1712 for the new task created by the create task function.

[0391] Subsequently, the call of the execution task function 1714 can be detected, and the execution task modifier 732 can be used to modify the execution task function 1716 to check whether the new task being executed is to be tracked. Similarly, such modification can be performed via code injection, the execution of different versions of the execution task, the use of breakpoints, and other similar "modifications". Therefore, as used in this article, the term "modify the execution task function" refers to the interruption of the execution of the execution task function by the insertion of additional code, the execution of the replacement code, or the execution of the execution task function, such as via hardware or software breakpoints. As for whether to track the inspection of the new task being executed, such inspection can be performed with reference to the record indicator 740, which can be a separate record indicator associated with the new task, such as a separate Boolean value or flag. For example, the checked record indicator 740 can be a record indicator set 1712 based on the record indicator of the previous task being checked, in the context of the previous task, the new task was previously created and is now being executed. If the recording indicator 740 indicates that the new task being executed is to be traced, the trace enabler 718 may be called 1718 to trace the new task being executed. In this manner, the recording indicator 740 may be used to mark tasks for tracing across process or execution boundaries so that asynchronously executed tasks may still be traced even though the library code supporting the execution of such tasks in an asynchronous manner may not itself be traced, in order to obtain the technical advantages detailed above.

[0392] Unless otherwise specified, the technical methods shown in the drawings or otherwise disclosed will be automatically executed by, for example, a tracking controller 700 or a system 102 configured 1402 with tracking modifications 714. In the scope of the actions of a human administrator or other human, the method can also be partially automatically and partially manually executed, for example, a person can enter the specified standard 704 into the tool user interface, and then start the execution of the process 206 being tracked, which makes the tool 122 configure 1402 process for tracking, and then the configured process is executed. However, it is not considered here that the method as an innovation is completely manual. In a given embodiment, zero or more example steps of the method can be repeated, possibly with different parameters or data to be operated. The steps in the embodiment can also be performed in a different order than shown in the figure. 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 change from the execution of one method to the execution of another method. If the method performed is operable and meets at least one claim, the steps can also be omitted, combined, renamed, regrouped, or otherwise deviate from the flow shown.

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

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

[0395] Various criteria may be used to determine thresholds and other constraints on the value of the distance variable. In some embodiments, at least one of the following criteria is satisfied: the number of instructions in a trace disabler configured to disable tracing of the execution tracer is greater than a low count threshold; the number of instructions in a trace disabler configured to disable tracing of the execution tracer is greater than the value of the distance variable at the second location; the computational cost of calling the trace disabler at the second location to disable tracing of the execution tracer is greater than the computational cost of executing a sequence of M instructions starting at 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 that is not designated for tracing is less than the computational cost of calling the trace disabler at the second location to disable tracing of the routine.

[0396] In some embodiments, connecting 1420 the execution tracer 204 to the executable code 208, 308 includes installing 1422 a callback 1118 to the execution tracer in the executable code. The callback is configured to determine, when executed, whether to perform one or more of the following: continue recording, change the distance variable value, stop recording. The inputs to the determination are the distance variable value and the tracking state 730, such as Fig.10 shown.

[0397] Those skilled in the art will appreciate that other methods are within the scope of the teachings presented herein. In particular, in some cases, other methods may perform selective tracing without using the specific APIs, variables, thresholds, state diagrams 1000, or specified criteria in the examples described herein. Methods using any aspect or implementation of the provided selective tracing teachings are within the scope of the present disclosure, whether or not 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, comprising configuring a system with tracing modifications or a system performing such a configuration, i.e., configuring or performing a selective tracing operation by replacing or reducing calls to a tracing disabler using a distance variable as taught herein.

[0398] Configured Media

[0399] Some embodiments include a configured computer readable storage medium 112. The medium 112 may include a disk (magnetic, optical or otherwise), RAM, EEPROMS or other ROM and / or other configurable memory, particularly including a computer readable medium (which does more than just propagate signals or energy). The configured storage medium may particularly be a removable storage medium 114, such as a CD, DVD or flash memory. General purpose memory (which may be removable or non-removable, and may be volatile or non-volatile) may be configured into embodiments using, for example, a distance variable 720 with a stop tracking value 722 and a modifier 724 that automatically moves the distance variable toward the stop tracking value as the process executes, routines 910, 914, 916, and conditioning conditions 1210 with constituent thresholds 726, 728 and information 1218, 1220, in the form of data 118 and instructions 116, read from the removable medium 114 and / or other sources (such as a network connection) to form a configured medium. As disclosed herein, the configured medium 112 can cause a computer system to perform technical processing steps for selectively tracking portions of a computer process execution. Thus, the accompanying drawings help illustrate the configured storage medium embodiments and process embodiments, as well as system and process embodiments. In particular, Fig.10 , 14, 15, 16, or any process steps otherwise taught herein may be used to help configure the storage medium to form a configured medium embodiment.

[0400] 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 tracing 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, the distance variable measuring a relative distance at which tracing 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 tracing is not already enabled, supports 1430 an instruction to execute a tracer 204 to trace up to the number of values ​​of the distance variable, and, if tracing is already enabled, causes tracing to continue to be enabled. 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 instructions of a computer process that includes the code unit. The execution tracer traces 1012 execution of the computer process when the value of the distance variable is positive and the execution tracer is enabled, and disables 1426 tracing of execution of the computer process in response to the value of the distance variable reaching 1428 zero.

[0401] In some embodiments, the selective execution tracing method includes identifying 1650 a specified routine, i.e., a routine that is designated for tracing. The identification is based on at least one of the following criteria 704: the author of the routine, the time when 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 specified library, whether the routine is part of a specified namespace, whether the routine has specified parameters, whether the routine is part of a just-in-time compiler, whether the routine is part of a garbage collector, whether the routine is part of a kernel, the name of the routine, the name of the module containing the routine, a direct caller of the routine, or an indirect caller of the routine. The selective execution tracing method also includes tracing 1012 at least the specified routine or other identified 1650 code unit 1100.

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

[0403] In some embodiments, the selective execution tracing method includes generating 1012 an execution trace 220 having trace data corresponding to execution of at least five specified routines 702, 1104 and having at least three gaps 428 in the trace data, with tracing being disabled 1426 at the gaps as a result of a distance variable reaching 1428 zero.

[0404] In some embodiments, the selective execution tracing method disables 1426 tracing K times, K being positive, during execution of the computer process 206. In particular, in this example, tracing is disabled at least half of the K times due to the value of the distance variable reaching 1428 zero.

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

[0406] In some embodiments, high count threshold 726 or low count threshold 728 or both thresholds are changed during execution of a computer process. For example, a change in a threshold may be made in response to a conditioning condition 1210 specific to a portion of code.

[0407] Those skilled in the art will appreciate that other configured media embodiments are also within the scope of the teachings presented herein. In particular, other embodiments may include a legal medium configured to perform selective tracking in some cases without using specific APIs, variables, thresholds, state diagram 1000, or specified criteria in the examples illustrated herein. Methods using any aspect or implementation of the provided selective tracking teachings are within the scope of the present disclosure, whether or not 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 tracking method that replaces or reduces calls to a tracking disabler by using a distance variable as taught herein.

[0408] Some additional combinations and variations

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

[0410] in conclusion

[0411] Although specific embodiments are explicitly shown and described herein as processes, configuration media, or systems, it should be understood that a discussion of one type of embodiment also generally extends to other types of embodiments. Fig. 9 , 10 The process descriptions described in 14-16 also help describe the configured media and help describe the technical effects and operations of systems and manufacturing similar to those discussed in conjunction with other figures. It is not necessary to read limitations from one embodiment into another embodiment. In particular, the process is not necessarily limited to the data structures and arrangements presented when discussing systems or manufacturing such as configured memory.

[0412] Those skilled in the art will appreciate that implementation details may be related to specific code, such as specific APIs, specific kinds of tracking data, and specific values, and therefore may not necessarily appear in every embodiment. Those skilled in the art will also appreciate that program identifiers and some other terms used when discussing the details are implementation specific and therefore may not necessarily be related to every embodiment. Nevertheless, although their presence is not necessarily required here, such details may help some readers by providing context, and / or may illustrate some of the many possible implementations of the techniques discussed herein.

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

[0414] In each embodiment, not every item shown in the figure must be present. On the contrary, an embodiment may include items that are not explicitly shown in the figure. Although some possibilities are shown in the text and drawings by specific examples herein, an embodiment may depart from these examples. For example, a specific technical effect or technical feature of an example may be omitted, renamed, grouped differently, repeated, instantiated differently in hardware and / or software, or a mixture of effects or features that appear in two or more examples. In some embodiments, a function shown at one location may also be provided at a different location; for example, those skilled in the art recognize that functional modules may be defined in various ways in a given implementation without having to ignore the desired technical effects from a set of interactive modules that are viewed as a whole.

[0415] Reference is made to the drawings throughout the text by reference numerals. Any apparent inconsistency in the wording associated with a given reference numeral in the drawings or text should be understood to simply expand the scope to which the numeral refers. Even if the same reference numeral is used, different instances of a given reference numeral may refer to different embodiments. Similarly, a given reference numeral may refer to a different embodiment.

[0416] can be used to refer to verbs, nouns, and / or corresponding instances of each, e.g., processor 110

[0417] The instructions may be processed 110 by executing the instructions.

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

[0419] Headings are for convenience only; information on a given topic may be found outside the section whose heading indicates that topic.

[0420] All claims and the abstract as filed are part of the specification.

[0421] Although exemplary embodiments have been shown in the drawings and described above, it is clear to those skilled in the art that various modifications may 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 is described in language specific to structural features and / or program actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific technical features or actions described in the claims. Each means or aspect or technical effect identified in a given definition or example does not necessarily exist or is utilized in every embodiment. Instead, the specific features, actions, and effects described are disclosed as examples to be considered when implementing the claims.

[0422] To the maximum extent permitted by law, all changes that come within the general abstract concept and within the meaning and range of equivalency of the claims are intended to be embraced within their scope.

Claims

1. A selective execution tracking system, comprising: at least one processor including registers; digital memory in operable communication with said processor; An executable code configured to perform a computer-implemented process upon execution, the executable code having: one or more first parts, which are designated for tracking, and one or more second portions that are not designated for tracking; an execution tracer, which traces the code being executed when tracing is enabled; a trace disabler configured to disable tracing by the execution tracer; a trace enabler configured to enable tracing by the execution tracer; A trace controller with reference to the register, the register being configured to store a distance variable representing a maximum amount of computational cost incurred before invoking the trace disabler, the trace controller being configured to: calling the tracking disabler in conjunction with the distance variable reaching a stop tracking value; as well as then calling the tracking enabler conditional on the distance variable not having the stop tracking value; as well as Distance Variable Modifier, configured as: As the one or more second portions of the executable code execute, incrementally moving the distance variable closer to the stop tracking value; and when the one or more first portions of the executable code are executed, moving the distance variable away from the stop tracking value, Wherein during execution of at least a subset of the one or more second portions, a value of the distance variable causes said tracking of at least a subset of the one or more second portions.

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

3. A 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, the managed code being code configured to run under the control of a runtime, the runtime implementing at least one of memory garbage collection and code compilation. 4 . The selective execution tracing system of claim 1 , wherein the at least one first portion of the executable code designated for tracing comprises native code, the native code being code configured to run without requiring a runtime.

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

6. The selective execution tracking system of claim 1, wherein: The distance variable modifier is configured to move the distance variable closer to the stop tracking value when the one or more second portions of the executable code execute by decrementing the distance variable when the executable code executes; and The tracing controller is configured to, upon execution, call the tracing disabler in conjunction with the distance variable reaching the stop tracing value of zero, and subsequently call the tracing enabler in conjunction with the distance variable being positive, and the executable code is 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 after 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, set the distance variable to a positive high count threshold.

7. The selective execution tracking system of claim 6, wherein the high count threshold satisfies 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 ninety percent of routines of the executable code; The high count threshold exceeds an average number of instructions in the routine of the executable code.

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

9. The selective execution tracing system of claim 6, wherein the trace controller includes a high count ensuring code in an exception handler, the high count ensuring code configured to set the distance variable to a value not less than the high count threshold after execution.

10. The selective execution tracing system of claim 1, wherein invoking the trace enabler conditional on the distance variable not having the stop tracing value comprises invoking the trace enabler after the distance variable has been modified to not have the stop tracing value.

11. A selective execution tracing method implemented on a computer system, the computer system comprising at least one processor, the at least one processor comprising a register, the register configured to store a distance variable, the distance variable representing a maximum amount of computational cost incurred before invoking a trace disabler, the method comprising: Executing executable code at the at least one processor, the executable code having: one or more first parts, which are designated for tracking, and one or more second parts that are not designated for tracking; Managing the distance variable based at least on the execution of the executable code comprises: As the one or more second portions of the executable code execute, incrementally moving the distance variable closer to the stop tracking value; and When the one or more first portions of the executable code execute, moving the distance variable away from the stop tracking value; and Managing tracking of the distance executable code based at least on the value of the distance variable includes: calling the tracking disabler in conjunction with the distance variable reaching the stop tracking value; and subsequent to calling the trace disabler, calling a trace enabler conditional upon the distance variable not having the stop trace value, Wherein during execution of at least a subset of the one or more second portions of the executable code, the value of the distance variable causes tracing of the at least a subset of the one or more second portions of the executable code.

12. The selective execution tracing method of claim 11, wherein the amount of computational cost is measured by at least one of: number of instructions executed, number of processor cycles executed, elapsed system clock time, number of trace 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, the managed code being code configured to run under the control of a runtime, the runtime implementing at least one of memory garbage collection and code compilation.

14. The selective execution tracing method of claim 11, wherein the at least one first portion of the executable code designated for tracing is composed of native code, the native code being code configured to run without a runtime. 15 . The selective execution tracing method of claim 11 , wherein invoking the trace enabler conditional on the distance variable not having the stop tracing value comprises invoking the trace enabler after the distance variable has been modified to not have the stop tracing value.

16. A computer readable storage medium configured with code that, when executed by a computer processor comprising a register, causes a computer system to perform at least the following: Executing executable code at the at least one processor, the executable code having: one or more first parts, which are designated for tracking, and one or more second parts that are not designated for tracking; Managing the distance variable based at least on the execution of the executable code comprises: As the one or more second portions of the executable code execute, incrementally moving the distance variable closer to the stop tracking value; and When the one or more first portions of the executable code execute, moving the distance variable away from the stop tracking value; and Managing tracking of the distance executable code based at least on the value of the distance variable includes: calling the tracking disabler in conjunction with the distance variable reaching the stop tracking value; and subsequent to calling the trace disabler, calling the trace enabler conditional upon the distance variable not having the stop trace value, Wherein during execution of at least a subset of the one or more second portions of the executable code, the value of the distance variable causes tracing of the at least a 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: a number of instructions executed, a number of processor cycles executed, a system clock time elapsed, a number of trace entries.

18. A computer-readable storage medium according to claim 16, wherein the one or more first portions of the executable code designated for tracking include managed code, which is code configured to run under the control of a runtime, and the runtime implements at least one of memory garbage collection and code compilation.

19. The computer-readable storage medium of claim 16, wherein the at least one first portion of the executable code designated for tracing consists of native code, which is code configured to run without a runtime.

20. The computer-readable storage medium of claim 16, wherein invoking the trace enabler conditional on the distance variable not having the stop trace value comprises invoking the trace enabler after the distance variable has been modified to not have the stop trace value.

Images