Selective tracking of computer process execution

Abstract

The disclosed embodiments relate to selective tracking of computer process execution. The described techniques support selectively tracking execution of a process, with some additional tracking beyond the code that a developer wants to track, but with a significant reduction in computational cost by reducing the number of track enable and disable operations. A tracking controller uses a track disable distance variable, whose value indicates a computational distance from a track disable. As the process executes, a distance variable modifier automatically moves the distance variable closer to a stop tracking value. A create task function is modified to include a setting of an indicator that indicates that a newly created task is to be tracked if the current task or thread is being tracked. An execute task function is modified to request tracking of a newly created task when the newly created task is executed based on the indicator, thereby enabling selective tracking across process boundaries and tracking of asynchronous code execution.

Description

[0001] Related applications

[0002] This application is a divisional application of the invention patent application with the international filing date of April 13, 2019, which entered the Chinese national phase on October 27, 2020, with Chinese national application number 201980028662.0 and the invention title "Selective Tracking Part of Computer Process Execution". Background Technology

[0003] Computer software is typically complex. Part of this complexity may stem from the nature of the work a program is designed to perform—for example, 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 must be properly managed to instruct the computer hardware how to perform real-world work that would have been far less precise when initially described in English or another natural language. In other words, the conversion from a high-level description to a low-level implementation executable by a computer system inevitably introduces complexity. Even the source code of programming languages, which are more precise than natural languages, remains at a relatively high level and is therefore ambiguous, open to various interpretations and implementations. As the source code is translated into low-level instructions directly executable by computing hardware, many details are introduced and choices are made during the translation process.

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

[0005] Debugging is often easiest when developers can run a debug object at will, either slowly or at full speed, or pause its execution at will, and can inspect all its state information at any point during its execution. This is known as "real-time process debugging." However, such complete access to a debug object is often unavailable. For example, a debug object might be production software, which cannot be debugged in real-time without violating service agreements or harming the reputation, security, or financial condition of stakeholders. Pausing a real-time process debug object for even a few seconds at a time while developers examine variable values, check which functions are called with which parameter values, review source code, consider possible interpretations of defects, and design tests that might help identify, remedy, or eliminate defects could cause unacceptable harm.

[0006] Therefore, sometimes state information is recorded during the execution of the debug object so that it can be examined later without substantially halting the execution of the debug object. For example, some or all memory values ​​related to the execution of the debug object, as well as operations on those values, can be recorded in the execution trace over time. When the debug object is not a real-time process, some debuggers support using such a trace to replay the execution of the traced debug object. Using some debuggers, the execution of the debug object captured in the trace can be replayed forward or backward, thus allowing for "time travel," "reverse," or "historical" debugging.

[0007] Tracing often slows down the debugging process. Therefore, tracing the progress of software program execution while avoiding undue impact on software performance helps improve the information available for debugging and will thus tend to improve the functionality of the computer system being debugged by supporting the mediation and elimination of their defects. For software programs that rely on asynchronous execution to be useful, these progresses must be able to continue tracing execution across multiple threads of execution. Summary of the Invention

[0008] Some of the techniques described in this paper involve technical activities for creating execution traces that focus on the parts of a program most likely to contain defects of interest, thereby improving trace-based debugging while also enabling tracing to continue across multiple threads of execution. Some teachings involve specific computational mechanisms for balancing the computational cost of enabling or disabling tracing with the computational and storage costs of tracing code that does not contribute to specific debugging work. Other teachings involve specific computational mechanisms for tracing, annotating, and tracking tasks as they are executed in different threads of execution. Technical mechanisms for adapting to the environment to create traces of interest from native or managed processes are described. In response to the challenge of focusing tracing on user code of interest, specific technical tools and techniques are described here to reduce undesirable performance degradation and increased trace size due to tracing non-user code (such as kernel, compiler, garbage collector, or standard library code) while enabling tracing execution across multiple threads. Other technical activities related to the teachings in this paper will also become apparent to those skilled in the art.

[0009] Some selective execution tracing embodiments described herein include a processor, digital memory operably in communication with the processor, and executable code for a computer-implemented process. The executable code has portions implicitly or explicitly designated for tracing and other portions not designated for tracing. An execution tracer exists, utilizing a tracing disabler to disable tracing and a tracing enabler to enable tracing. A tracing controller includes a tracing disable distance variable, the changing 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 execution of the executable code will be traced before tracing is disabled. The tracing controller invokes the tracing disabler in conjunction with a distance variable having a stop tracing value (e.g., zero). The tracing controller can then invoke the tracing enabler in conjunction with a distance variable not having a stop tracing value. As the executable code executes, a distance variable modifier incrementally moves the distance variable closer to the stop tracing value. For example, the distance variable modifier can decrement a positive value in the distance variable, thereby moving the distance variable closer to zero, and when the distance variable reaches zero, tracing is disabled.

[0010] Instead of explicitly invoking the trace disabler every time an executable code specified for tracing is exited, the implementation can reduce the computational cost of tracing by using a distance variable to control tracing disabling. This can be beneficial in various situations because tracing is used for multiple purposes, such as during debugging to assist code understanding, for statistical analysis, and to support other goals. This reduction in computational cost comes at the cost of tracing some uninteresting code. The trace file may be larger than if only the code of interest were traced, but the performance impact of tracing is often smaller compared to tracing only the code of interest. For example, in a debugging context, when code is outside a suspicious part of the code, it is considered "uninteresting" relative to a particular defect, making it unlikely to help identify, mitigate, or remove the defect. For example, code in items (such as the kernel, compiler, system libraries, or garbage collector) is not interesting for identifying defects in user code outside of those items.

[0011] Some embodiments described herein relate to configuring an environment to perform selective execution tracing implemented by a computer. Some embodiments particularly relate to configuring executable code for tracing that is controlled using a tracing-disabled distance variable (i.e., a variable whose value indicates a relative distance to a computationally disabled tracing). One method embeds non-zero high-count assurance code in the executable code, which is configured to set the distance variable to a value not less than a high-count threshold during execution. This 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 attaches an execution tracer to the executable code. The method configures a tracing controller to disable tracing when the distance variable reaches a stop-tracing value, and further configures the tracing controller to enable tracing for at least a portion of the execution of the executable code when the distance variable differs from the stop-tracing value.

[0012] Some embodiments relate to selective execution tracing in a practically implemented computer. One embodiment sets a tracing-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 to the disabled tracing in terms of computational cost. In conjunction with setting the distance variable to a value not less than the high-count threshold, this embodiment makes a call that, if tracing is not already enabled, allows the execution tracer to trace up to the number of values ​​of the distance variable, and if tracing is already enabled, the call keeps tracing enabled. At the exit point of the code unit, this embodiment sets the distance variable to a non-zero low-count threshold less than the high-count threshold. As the computer processor executes instructions of the computer procedure containing the code unit, the distance variable automatically decrements. When the value of the distance variable is positive and the execution tracer is enabled, the execution tracer tracks the execution of the computer procedure, and if the value of the distance variable reaches zero, this embodiment disables tracing of the execution of the computer procedure.

[0013] The examples given are merely illustrative. This "Summary" is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Rather, 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 any conflict between the Summary and the claims, the claims shall prevail. Attached Figure Description

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

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

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

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

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

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

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

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

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

[0023] Figure 9 This is a block diagram illustrating aspects of a tracking controller that uses a tracking-disabled distance variable to control the execution of tracking;

[0024] Figure 10 It is a tracking state diagram;

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

[0026] Figure 12 This is a block diagram illustrating some aspects of the code that can be related to tracing, as well as some adjustment conditions that can be used when tracing code with the distance variable disabled;

[0027] Figure 13 It is a comparison of the computational costs of implementing side-by-side tracking control in tracking scenarios;

[0028] Figure 14 This is a flowchart illustrating an example method for configuring a system that selectively performs tracing when using a tracing-disabled distance variable;

[0029] Figure 15 This is a flowchart illustrating an example method for selectively performing tracing when a tracing-disabled distance variable is used;

[0030] Figure 16This is a flowchart further illustrating a method related to selectively performing tracing using a tracing-disabled distance variable; and

[0031] Figure 17 This is a flowchart illustrating methods related to execution tracing of asynchronously executed tasks. Detailed Implementation

[0032] Overview

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

[0034] In particular, debugging in a production cloud environment presents significant technical challenges. For example, suppose a specific request R for an online shopping cart is not working. How can developers debug the processing of request R without slowing down the processing of all other requests and minimizing any slowdown in the processing of request R? To find the defect, developers use information about what is happening internally in the code, such as a way of looking at the values ​​of variables at one or more points of interest during the processing of request R.

[0035] Tracing-based debugging innovations help overcome technical challenges that traditional methods cannot solve. For example, many traditional debuggers and debugging methods allow developers to set halt breakpoints to obtain information about variable values. A halt breakpoint is an instruction to pause execution, giving developers time to examine memory contents at a given point in processing and consider possible interpretations of what is observed. However, in production environments, halt breakpoints can pause the processing of a large number of requests, which is undesirable. Even pausing only a single thread can lead to unwanted dropped requests and produce unpredictable side effects that hinder debugging, degrade 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, such as to test the value of a variable to see if it is the value the developer expected at that point in the code. However, these methods may require recompiling and redeploying the code, which is undesirable in production environments, especially if recompiling and redeploying are to be done multiple times as part of an iterative debugging process to find and fix individual defects. Additionally, it may be necessary to require developers to identify defects in code that they do not have a source for and therefore cannot add print statements to and recompile.

[0037] Developers can inject operations into request handling code at execution time to create a copy of some or all of the memory relevant to the request. This 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 conventional debuggers can read dump files or snapshots and, given appropriate metadata, present the memory contents in a specific format that shows variable values ​​translated from binary into an informative structure including variable names and displaying variable values ​​based on their corresponding data types. However, dumping memory to a file is time-consuming, slowing down not only requests to R but all requests in the example scenario. While creating a snapshot is much faster than creating a dump file, it can require many attempts by the developer to find useful points in the processing to obtain a memory snapshot that reveals defects, and snapshots consume space in RAM. To view memory at another point in time other than execution time, captured in a dump file or snapshot, another copy of the memory can be created. Real-time processes are used to view memory from any point in time within a real-time process.

[0038] In many modern computing systems, such as Figure 2 The example of the managed process environment 200 shown includes a real-time process 206, which is a managed code 208 process that, in addition to depending on the operating system 120, also includes a runtime 210. The managed code 208, besides depending on the kernel 120, also includes or depends on the runtime 210 for garbage collection or code compilation (i.e., JIT compilation or compilation of intermediate language code) or both. Garbage collection may 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 and a real-time process 206 lacking runtime 210. The native code 308 interfaces directly with the kernel 120 without using runtime 210.

[0039] The teachings presented herein can be beneficially applied to one or both of the two environments 200 and 300. As shown, tool 122 (such as debugger 202 or execution tracer 204) can inject operations into real-time process 206 to make copies 214 of some or all of the memory entries 212 used during the execution of process 206. In an online shopping cart scenario, for example, tracer 204 can inject operations into request processing code to make copies of some or all of the memory 112, 212 associated with the problematic request R. Instructions 116 for implementing memory copying can be injected by tool 122 before or during the execution of code 208, 308. Code injection, also known as "code instrumentation," is a technique in which the binary representation of executable code is decoded and rewritten at execution time to add additional functionality to the program.

[0040] Processes lacking runtime can be directly controlled by the debugger by inserting pause breakpoints. However, processes that depend on runtime are not directly controlled by the debugger 202 because their runtime is effectively hidden from debugger details 212, such as memory location, memory contents, and instruction pointers. To show the developer what is in memory during debugging, the debugger sends a message to the runtime requesting the current memory values. The runtime sends these values ​​back to the debugger in a reply message, and the debugger displays the values ​​it received in the reply message in a user interface.

[0041] Runtime 210 also controls the execution of real-time debug objects. In one example, to set a breakpoint at offset 28 at an intermediate language (IL) instruction in method Foo, a message is sent to the runtime requesting it to set a breakpoint at offset 28 of Foo. The thread within the runtime then receives the message, translates Foo IL offset 28 into machine instructions residing at memory address 0x4567123512395, and then writes the breakpoint instruction at that location.

[0042] The debugger 202 user interface graphically displays a representation of the debugger's program states to the user. Some examples of program states include a list of threads, the next line of source code to be executed on each thread, the call stack for each thread, a set of variables in each frame of the call stack, and the values ​​of these variables.

[0043] In some implementations, the runtime translation section of debugger 202 is responsible for translating between low-level concepts (such as memory units 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 of the abstract runtime layer is not necessarily the same as the call stack at the abstract source code level; for example, the virtual machine's call stack does not match the virtual call stack of the IL code being executed within the virtual machine.

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

[0045] Like any other process, runtime can be traced. However, debugging software other than runtime is more common than debugging runtime, and unless otherwise stated, it is assumed here that the tracing process can exclude some or all of the code that is part of the runtime itself. Trace file 420 only traces the execution of processes that depend on the runtime and does not trace the runtime itself. Trace file 420 does not fully support reading the values ​​of runtime-managed objects from the trace file using conventional debugging methods. There is no runtime currently executing for the debugger to fully associate memory locations with objects and other variables, thus making the memory values ​​exposed by the trace meaningful. To control the execution of real-time processes that depend on the code currently executing at runtime, the debugger can send a message to the runtime requesting an operation, such as "step" or "run," which the runtime then executes on behalf of the debugger. This functionality does not apply to trace files that do not currently have a running runtime.

[0046] In terms of runtime unavailability, dump file 218 and snapshot 216 are similar to traces. The runtime can be presented in a dump, snapshot, or trace, but it is not being executed and therefore cannot be invoked.

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

[0048] In some cases, developers can use a "time-travel" debugger to control the execution replay, allowing the program to run forward or backward in execution time while replaying a recorded trace. This leverages the debugger's ability to present memory in useful high-level (e.g., named and data-data-based) variable representations, not only for snapshots as before, but now for continuous replays of segments of execution time recorded during code execution. Developers can then examine the memory values ​​captured in the trace at multiple points in a high-level representation based on the low-level data recorded in the trace file. Of course, memory inspection requires reading memory cell values ​​from the trace, or other values, and somehow extracting useful information 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 expected point in execution time.

[0049] When debugging using process dumps or snapshots, the data access layer is used as the data source to view information about high-level program states during runtime. With appropriate tuning, debugger 202 can apply a runtime (high-level) view of the process trace that has been recorded as machine-level operations. For the purposes of this application only, "machine-level" operations are operations specified at the assembly language, intermediate language, or lower levels.

[0050] In some cases, trace 220 records machine-level process activity, such as register activity and reads and writes at specific memory addresses specified in binary or hexadecimal rather than by identifiers in the source code compiled to create the process. Some traces 220 can be replayed using an 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 being debugged. The teachings in this paper discuss tools and techniques for selectively choosing segments of process 206 to be recorded. A “segment” is a part of a process and can include one or more routines, threads, libraries, or other suitable subsets of the process in the form of its underlying code or memory activity. Segment selection reduces the processing time and memory overhead of tracing, as well as the disk consumption of tracing 220. In production environments and many other environments, process execution tracing 220 tends to be large (hundreds or gigabytes), and tracing can result in significant processor overhead when tracing is enabled (execution is slowed down by ten times or more). The solutions presented in this paper help reduce file size, memory pressure, and processor load by selecting during process execution which parts of the software should be traced.

[0052] Some may view some of the embodiments described herein in a broader context. For example, concepts such as disable, distance, enable, size, and tracking may be considered relevant to a particular embodiment. However, not following the availability from a broad context, in which exclusive rights are sought for abstract concepts, they are not. Rather, this disclosure focuses on providing suitable specific embodiments that fully or partially solve specific technical problems, such as identifying tradeoffs, pursuing a balance between tracked program performance, slowed track execution, track relevance, and track size, and mechanisms for achieving such balances. Other media, systems, and methods involving disable, distance, enable, size, or tracking are not within the scope of this disclosure. Thus, ambiguity, mere abstraction, lack of technical features, and the associated problems of proof are also avoided, provided that this disclosure is properly understood.

[0053] Technical features

[0054] The technical features of the embodiments described herein will be readily apparent to those skilled in the art, and will also be apparent to various interested readers in a variety of ways. Some embodiments are dedicated to technical activities rooted in computing technology and aimed at improving the functionality of computing systems. For example, some embodiments assist in debugging systems by making debug tracing more efficient. When tracing the execution of these systems, some embodiments mitigate performance degradation in the system.

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

[0056] Furthermore, by making the traced program run at full speed while performing un-debugged operations, some implementations allow developers more time to perform debugging analysis within a given work cycle. Developers wait less time when tools trace operations of little interest (such as garbage collection, JIT compilation, or standard library routines, which are part of execution but are unlikely to contain the sought-after defect). The time saved by reducing irrelevant tracing can be used for code replay, variable inspection, and other debugging analysis.

[0057] Some embodiments include technical components, such as computing hardware, that interact with the 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 some form of I / O), some embodiments described herein also use tracking-disabled distance variables and one or more relevant thresholds to implement selective tracking algorithm steps, as disclosed herein.

[0058] Some of the technical effects provided by the embodiments include more efficient use of debugging time by developers, reduced trace file size, and reduced tracer execution speed.

[0059] Some implementations include technical adaptations such as tracking-disabled distance variables, routines, and other mechanisms for modifying or inspecting tracking-disabled distance variables. Some adaptations include tracking selection conditioning conditions. These conditions achieve a balance between the computational cost of enabling or disabling tracking and the computational and storage costs of tracking code that does not contribute to a particular debugging effort.

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

[0061] Acronyms and Abbreviations

[0062] The following defines some acronyms and abbreviations. Other abbreviations may be defined elsewhere in this document, or may not require any definition and will be understood by those skilled in the art.

[0063] ALU: Arithmetic and Logic Unit

[0064] API: Application Programming Interface

[0065] BIOS: Basic Input / Output System

[0066] CD: Compressed disc

[0067] CPU: Central Processing Unit

[0068] DV: Distance variable, as shown in "Disable distance variable in tracking".

[0069] DVD: Digital Multifunction 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 also called an "interactive development environment".

[0076] JIT: Timely, as in "JIT compiler" or "JIT compilation".

[0077] OS: Operating System

[0078] RAM: Random Access Memory

[0079] ROM: Read-Only Memory

[0080] "==" indicates "equals", "!=" indicates "not equals", and "=" indicates "assigned a value"; these abbreviations are used in... Figure 10 and 13 Use

[0081] The parentheses “()” indicate a routine; for example, “trace-on()” is a routine named “trace-on”. A routine can also be referenced by its name without parentheses, for example, Figure 13 In this context, "A", "B", "B1", "C", and "C2" 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 to describe them. However, changes and further modifications to the features illustrated herein, as well as additional technical applications of the abstract principles illustrated by specific embodiments herein, that may occur to those skilled in the art, should be considered within the scope of the claims.

[0084] The meanings of the terms are clarified in this disclosure, and these clarifications should be carefully considered when reading the claims. Specific examples are given, but those skilled in the art will understand that other examples may also fall within the meaning of the terms used and within the scope of one or more claims. The terms herein do not necessarily have the same meaning as they do in their general use (especially in non-technical use), in a particular industry, or in a particular dictionary or encyclopedia. Reference numerals may be used with a variety of wording to help indicate the breadth of the terminology. Omission of reference numerals from a given text does not necessarily indicate that the text does not discuss the figures. The inventors claim and exercise their rights to their own lexicographical compilations. Terms in quotation marks are explicitly defined, but may also be implicitly defined without quotation marks. Terms may be defined explicitly or implicitly in the “Detailed Description” and / or elsewhere in the application.

[0085] As used herein, "computer system" can include, for example, one or more servers, motherboards, processing nodes, laptop computers, tablets, personal computers (portable or non-portable), personal digital assistants, smartphones, smartwatches, smart bracelets, cellular or mobile phones, other mobile devices having 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 providing one or more processors that are at least partially controlled by instructions. Instructions may take the form of firmware or other software in memory and / or dedicated circuitry.

[0086] A "multithreaded" computer system is a computer system that supports multiple threads of execution. The term "thread" should be understood to include any code that can be performed or scheduled (and possibly synchronized), and may also be referred to as, for example, as a "procedure" or "coroutine." Threads can 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 unit for processing threads, the core of a multithreaded implementation. Processors comprise hardware. A given chip can house one or more processors. Processors can be general-purpose or customized for specific purposes, such as vector processing, graphics processing, signal processing, floating-point arithmetic, encryption, I / O processing, etc.

[0088] The "kernel" includes the operating system, virtual machine monitor, virtual machine, 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 in this document. Executable code, interpreted code, and firmware are some examples of code. Code that is interpreted or compiled for execution is called "source code."

[0090] The term "program" is used extensively in this article to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by programmers (also known as developers) and / or automatically generated.

[0091] "Service" refers to consumable programs provided in a cloud computing environment or other network environment.

[0092] An "execution time point" refers to a specific point in the execution of a processing unit or thread, especially relevant to tracing execution. References to "specific execution time" or "execution time t" in this document refer to execution time points. For example, an execution time point can be implemented as a timecode variable or timecode value, or as a relative position in other records of tracing or execution activity. An execution time point ta "earlier than" or "later than" an execution time point tb indicates 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] Information regarding the order of events in a tracing may be incomplete. Therefore, a tracing may have enough information to establish that event A precedes event B, or that event D follows event C. However, the relative order of events may also be partially or completely uncertain, even when considering a tracing. A tracing may show that event E does not follow event F, but this does not necessarily mean that E precedes F; similarly, a tracing may show that event K does not precede event J, but no tracing may also show that K follows J. A tracing may also lack enough information to establish any order of two specific events relative to each other.

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

[0095] A "memory cell" refers to an addressable unit of memory. Examples include bytes or words in RAM or ROM, processor registers, cache lines, and other addressable memory cells.

[0096] An "emulator" performs a "simulation" 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 with a different implementation; for example, the emulator can run on completely different physical hardware.

[0097] The terms “record” and “track” are used interchangeably in this article to refer to the action of creating or extending a track.

[0098] Unless otherwise stated, as used herein, “include” allows for additional elements (i.e., include means contain).

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

[0100] For example, the term "process" is sometimes used herein as a term in the field of computer science and, in a technical sense, encompasses resource users, namely 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 process claims in contrast to system claims or claims of articles of manufacture (configured storage media). Similarly, the term "method" is sometimes used herein as a technical term in the field of computer science (a "routine") and also as a term in the field of patent law ("process"). Those skilled in the art will understand the meaning intended for use in particular contexts and will also understand that (in the sense of patent law) a given claimed process or method can sometimes be implemented using one or more processes or methods (in the sense of computer science).

[0101] Contrary to the absence of automation, "automatically" refers to the use of automation (e.g., general-purpose computing hardware configured by software for the specific operations and technical effects discussed herein). In particular, steps performed "automatically," while potentially initiated or interactively guided by a human, are not manually executed on paper or in the human mind. Automated steps are performed by machines to achieve one or more technical effects that would be impossible without such technological interaction.

[0102] Those skilled in the art will understand that technical effects are the presumptive purpose of technical embodiments. For example, the fact that an embodiment involves computation, and that some computations can be performed without technical components (e.g., by paper and pencil, or even as mental steps), does not eliminate the presence of technical effects or alter the specificity and technical nature of the embodiment. Operations (such as enabling tracking, copying tracking data, and disabling tracking) should be understood herein to require and provide speed and accuracy unattainable by human mental steps, in addition to their inherently digital nature (human thought cannot directly interact with the execution process or tracking file). This is well understood by those skilled in the art, but others may sometimes benefit from being informed or reminded of the facts. Unless otherwise stated, contrary to mere thought experiments, embodiments are assumed to be capable of operating at scale in a production environment or in a test laboratory within a production environment.

[0103] "Computationally" also implies the use of computing devices (at least a processor and memory) and excludes results obtained solely by human thought or action. For example, arithmetic with paper and pencil, as understood herein, is not computationally arithmetic. Computational results are faster, broader, deeper, more accurate, more consistent, more comprehensive, and / or provide technical effects beyond the reach of human performance. A "computational step" is a step performed computationally. Neither "automatically" nor "computationally" necessarily means "immediately." "Computationally" and "automatically" are used interchangeably herein.

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

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

[0106] For purposes of U.S. law and practice, the use of the term “step” in the claims or elsewhere herein is not intended to invoke means plus function, steps plus function, or to require interpretation under 35 U.S.C. 112(6) / 112(f). Any presumption of such effect is hereby expressly rejected.

[0107] For the purposes of U.S. law and practice, claims are not intended to invoke a means-plus-function interpretation unless the phrase “means for…” is used. Claim language intended to be interpreted as means-plus-function language (if any) will explicitly state this intention by using the phrase “means for…”. When a means-plus-function interpretation is adopted, whether by using “means for…” and / or by the court’s legal interpretation of the claim language, the means listed in the specification for a given noun or given verb shall be understood to be linked to the claim language and hereby linked in any way that: appears in the same box in the drawing block diagram, is denoted by the same or similar name, or is denoted by the same reference numerals. For example, if a claim limitation refers to “zac widget” and that claim limitation is subject to a means-plus-function interpretation, then all structures identified anywhere “zac widget” is mentioned in any block, paragraph, or example in the specification, or bound together by any reference numerals assigned to the zac widget, shall be considered part of the structures identified in the zac widget application and contribute to defining the equivalent itemset of the zac widget structure.

[0108] Throughout this document, unless otherwise expressly stated, any reference to a step in the process is assumed to be that the step can be performed directly by the interested party, and / or indirectly by one party through an intervention mechanism and / or intervention entity, and still falls within the scope of that step. That is, unless explicitly stated as directly performed, the step does not need to be performed directly by the interested party. For example, actions by the interested party concerning a destination or other subject matter (such as association, configuration, confirmation, connection, control, copying, decrementing, specifying, disabling, embedding, enabling, entering, executing, exiting, installing, invoking, measuring, moving, recording, running, satisfying, selecting, setting, tracking, regulating, using (as well as associated, related, configured, etc.) may involve intervention actions by the other party, such as forwarding, copying, uploading, downloading, encoding, decoding, compressing, decompressing, encrypting, decrypting, authenticating, invoking, etc., but should still be understood as being performed directly by the interested party.

[0109] Whenever data or instructions are referenced, it should be understood that, for example, these items configure computer-readable storage memory and / or computer-readable storage media to convert them into a particular article, as opposed to simply existing on paper, in a person's mind, merely energy, or merely a signal propagating on a wire. For the purposes of U.S. patent protection, according to the interpretation of the U.S. Patent and Trademark Office (USPTO) in the re Nuijten case, memory or other computer-readable storage media is not a propagation of signals, carrier waves, or merely energy outside the scope of the patentable subject matter. In the United States, no claim covers the signal itself, and any claim interpretation that asserts the contrary is unreasonable. Unless expressly stated otherwise in a claim granted outside the United States, the claims do not cover the signal itself.

[0110] Furthermore, although there are obvious contrary provisions elsewhere herein, it should be understood that there is a clear distinction between (a) computer-readable storage media and computer-readable repositories and (b) transmission media (also referred to as signal media or energy-only). A transmission medium is a computer-readable medium or energy-only that propagates a signal or carrier wave. Conversely, computer-readable storage media and computer-readable repositories are not computer-readable media that propagate a signal or carrier wave. Unless expressly stated otherwise in the claims, “computer-readable medium” means computer-readable storage media, not the propagation of a signal itself, nor energy-only.

[0111] The term "exemplification" in this document is illustrative. The term "exemplification" should not be used interchangeably with "invention." Examples of embodiments may be freely shared or borrowed to create other embodiments (provided the result is operable), even if consequential combinations of aspects are not explicitly described herein. It would be unnecessary for a person skilled in the art to explicitly describe every permitted combination, contrary to the policy of acknowledging that patent specifications are written for those skilled in the art. Formal calculations of combinations and informal intuition regarding the number of possible combinations, even those arising from a small number of composable features, will indicate that there are numerous combinations of aspects described herein. Therefore, requiring an explicit description of each combination contradicts the policy of requiring a concise patent specification and leaving the reader with knowledge of the relevant technical field.

[0112] List of reference numerals

[0113] The following list is provided for convenience and support of the accompanying drawings and as part of the specification text, which describe innovations by referring to multiple items. However, items not listed herein may still be part of a given embodiment. For clarity and readability, given reference numerals are referenced near some (but not all) of the reference items in the text. Different examples or instances of the given items may use the same reference numerals. 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 architecture.

[0116] 104: User

[0117] 106: Peripheral equipment

[0118] 108: Generally refers to 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: Processor-executable instructions; may be on removable media or in other memory (volatile or non-volatile or both).

[0123] 118: Data

[0124] 120: (Multiple) kernels, such as (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., may be suitable for using the selective tracing control taught in this article.

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

[0127] 126: Display screen

[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 Tracker

[0132] 206: Real-time debugging of programs or processes

[0133] 208: Managed Code

[0134] 210: Runtime

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

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

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

[0138] 218: A dump file, also known as a storage dump, may include additional information such as indexes or metadata.

[0139] 220: Execution trace; although Figure 4 The dashed lines in the text indicate that a given trace may include individual items or omit individual items, but this document assumes that the trace is not empty, and therefore the boxes for trace data 454 in general are shown as solid lines.

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

[0141] 420: Trace file, containing execution trace data; it may include machine-level trace data, that is, data recording the execution activities of assembly language, intermediate language, or lower levels.

[0142] 422: Precise tracking data during tracking.

[0143] 424: A timecode, in a trace, identifies a specific point in time during the execution of the traced code; it can be linked to or embedded in other data within the trace, for example, trace data that explicitly declares the point in time associated with a declared operation at a declared memory address involving the declared data value; a timecode can be implemented as, for example, a clock tick or an instruction counter; some traces may contain a unique timecode for each recorded operation, but in some trace data, the timecode may be repeated or omitted.

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

[0145] 430: Indexes to data in the trace file, such as reverse lookup data structures used to quickly identify trace attributes, memory lifetime 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, they may exist at fixed intervals in the tracking data to allow for faster replay jumps to (or near) keyframes during tracking playback.

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

[0148] 436: Stack activity, which occurs while the debug object is running and being traced, such as stack growth, stack shrinking, and the execution time at which this activity occurs.

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

[0150] 440: Processor core activity that occurs while the debug object is running and being traced, such as the opcodes and parameters of instructions executed by the core.

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

[0152] 444: Thread activity that occurs while the debug object is running and being traced, such as instructions executed while the thread is running, memory accesses made while the thread is running, and associated metadata (such as thread IDs and timestamps).

[0153] 446: Register activity occurs while the debug object is running and being traced, such as what value is read from which register at what timecode, or what value is written to which register at what timecode.

[0154] 448: Memory address

[0155] 450: Instruction opcode

[0156] 452: Data value

[0157] 454: Generally tracking data

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

[0159] 458: Tracking Entry Point

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

[0161] 504: The stack, for example, is a portion of memory where 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; it is generally 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 upward (i.e., the address increases as an item is pushed onto the stack), but in another system it may also be downward (i.e., the address decreases as an item is pushed onto the stack); the term "growing" here refers to the direction of stack growth in the system under discussion, while "shrinking" refers to the opposite direction.

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

[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, and the heap identifies and marks it as available memory, which holds objects that are no longer accessible during the live execution of the process; in other cases, memory allocated from the heap requires a separate explicit call to 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; it can be a function, in which case the property is usually called a method; it also refers to a function that implements an object property; a function is a routine that returns a value.

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

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

[0171] 524: RAM (Random Access Memory); typically volatile.

[0172] 526: Local memory, for example, memory that is local to a declared or implicit context (local to the routine during its execution and then freed, or local to the thread).

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

[0174] 530: The characteristics of memory that allow external entities to alter the value stored in a memory cell, such as whether the memory cell is write-protected relative to other threads, or whether it is in shared memory (such as memory that is global relative to multiple threads).

[0175] 602: Thread

[0176] 604: Thread ID

[0177] 606: Thread states, such as created, runnable, running, suspended, blocked, terminated.

[0178] 608: Thread code, that is, 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 global to a thread and is accessed by that thread during its execution.

[0180] 700: Trace controller, also known as tracing controller.

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

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

[0183] 706: Parts of a traceable process that are not specified as to be traced, including parts explicitly specified as not to be traced and parts implicitly specified as not to be traced (because they are not explicitly specified as to be traced).

[0184] 708: A library containing code other than the user code being debugged; for example, the standard library or libraries related to any debugging process handled by different developers.

[0185] 710: Compiler, for example, JIT compiler

[0186] 712: Garbage collector, that is, code that reclaims memory, so that memory operation lines malloc() and free() are not needed in user code source code.

[0187] 714: Modifications to executable code to control tracing, such as calls to tracing enablers, tracing disablers, or calls to set or check tracing disable distance variables.

[0188] 716: Tracing disabler, i.e., the routine that calls to stop tracing.

[0189] 718: The tracing enabler, i.e., the routine that calls to begin tracing.

[0190] 720: Tracking Distance Variables Disabled

[0191] 722: Stop tracking value; the tracking disabler will be invoked when the tracking disable distance variable reaches this value; the expected stop tracking value is typically zero.

[0192] 724: Tracking disables distance variable modifiers, such as interrupts or hardware processor modes or circuits, which automatically decrement a specified register (serving as a distance variable) as each program instruction is executed; although the examples in this document discuss decrementing the distance variable until it reaches zero, those skilled in the art will recognize that a functionally equivalent implementation could increment a negative distance variable until it reaches zero, or could increment or decrement the distance variable until it reaches some other stopping tracking value at which the tracking controller triggers a call to the tracking disabler.

[0193] 726: A high count threshold for values ​​in the distance variable can be used to indicate that a newly entering code unit is being tracked.

[0194] 728: A low count threshold for the value in the distance variable can be used to maintain tracking for an extended period after exiting a code unit that has been tracked for a sufficiently long time, so that an indication is encountered in a newly entered code unit that is also being tracked. If such an indication exists, tracking is disabled unless control is passed (backward or downward) to the code unit designated to be tracked.

[0195] 730: Tracing status, i.e., tracing is enabled or tracing is disabled.

[0196] 731: Create a task modifier that can inject code, patch code, insert breakpoints, or control the selection of alternative versions of code. This allows the task creation function to include a value setting that indicates under specific circumstances the created task will be logged, such as if it is logging the currently executing task or thread itself, which calls the task creation function within its context.

[0197] 732: Execution Task Modifier, which can inject code, patch code, insert breakpoints, or control the selection of different code, causing the execution task function to include instructions, calls, or other triggers, thereby resulting in the recording of tasks executed by the execution task function if the recording indicator indicates that the task should be recorded.

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

[0199] 802: This is a variant of system 102 that lacks or does not utilize the distance variable aspect of the tracking controller 700, which restricts the invocation of the tracking disabler and tracking enabler taught herein; instead, this variant explicitly invokes the tracking enabler upon entering each section of the code to be tracked and explicitly invokes the tracking disabler upon exiting each section of the code to be tracked.

[0200] 804: Computational cost, measured in terms of processor cycles, instruction counts, or system clock elapsed time, or in terms of the number of times a 220-to-458 trace is executed.

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

[0202] 808: Computational cost, which is the computational cost of at least a specified portion of the tracing code without using the distance variable aspect of the tracing controller 700, which restricts the invocation of the tracing disabler and tracing 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 of the set-N() routine

[0205] 906: Tracing the get-N() routine in some implementations of the controller to retrieve the value of the local variable N.

[0206] 908: Local variable 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-disabled distance variable.

[0208] 912: tracing-max, a parameter used in the set-DV() routine.

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

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

[0211] 1000: Trace state diagram, illustrating some of the trace control behaviors in the implementation.

[0212] 1002: Tracking on status, i.e., the state where tracking is enabled.

[0213] 1004: Tracking the off state, i.e., tracking is disabled.

[0214] 1006: Instructions for executing the traced process; it can also refer to executing a large part of the process or the entire process.

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

[0216] 1010: Invokes the trace enabler; also specifies that the trace enabler should be executed.

[0217] 1012: Record execution information in the trace.

[0218] 1014: Decrease tracking disables the distance variable, or otherwise moves the value of the distance variable to approach the stop tracking value.

[0219] 1016: Invokes the tracing disabler; also specifies that the tracing disabler should be executed.

[0220] 1100: Code Unit

[0221] 1102: Function

[0222] 1104: Routine

[0223] 1106: Coroutines

[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 Method

[0228] 1116: Implementation of Virtual Methods

[0229] 1118: Pullback

[0230] 1120: Count assurance codes, including codes to ensure that a distance variable meets or exceeds a high count threshold, or codes to ensure that a distance variable does not exceed a low count threshold.

[0231] 1122: Ku

[0232] 1124: Modules, such as files, components, and packages.

[0233] 1200: Aspects of code related to using trace-disabled distance variables to control which parts of the process are logged in the trace.

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

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

[0236] 1206: Caller of the routine

[0237] 1208: The current execution point in a routine or other code unit.

[0238] 1210: Adjustment condition, used to adjust trade-offs when using a tracing disable distance variable to control which parts of the process are recorded in the tracing. For example, adjusting how much uninteresting code is traced and how many processor cycles are spent disabling and re-enabling tracing; also refers to using such conditions to adjust tracing thresholds 726 and 728.

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

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

[0241] 1220: Information about the computational cost of enabling or disabling tracing, such as the length (instructions / processor cycles) of the tracing enable or disable.

[0242] 1300: Example of computational cost comparison

[0243] 1400: Configure the system to control tracking by using a tracking-disabled distance variable.

[0244] 1402: Configure the system to control tracking by disabling the distance variable during tracking.

[0245] 1404: Controlling tracking by disabling the distance variable during tracking

[0246] 1406: Disabling distance variables when using tracking

[0247] 1408: Embedding counts in the process ensures code integrity.

[0248] 1410: High count ensures code

[0249] 1412: Location in the code

[0250] 1414: Low count ensures code

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

[0252] 1418: Instruction Counter

[0253] 1420: Link the execution tracer to the process or its code.

[0254] 1422: Install a callback to pass control to the execution tracker

[0255] 1424: Configure the tracking controller

[0256] 1426: For example, disabling tracking by involving a tracking disabler.

[0257] 1428: The distance variable reaches zero or other stopping tracking values ​​due to a change in its value (e.g., due to a decrease in the distance variable).

[0258] 1430: For example, enabling tracking by involving a tracking enabler.

[0259] 1500: A method of controlling tracking by disabling the distance variable during tracking.

[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: Specify a code unit as part of the process (e.g., a program) to be traced.

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

[0265] 1606: Confirmation that tracking is disabled and the distance variable is not at a stop tracking value, for example, the distance variable is non-zero.

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

[0267] 1616: Running (also known as executing) managed code

[0268] 1618: Running (also known as executing) native code

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

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

[0271] 1624: Use 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: Using information about the size of executable routines during control tracing 1218

[0274] 1630: Select a low counting threshold

[0275] 1632: Select a high counting threshold

[0276] 1634: The adjustment condition 1210 is met.

[0277] 1636: Sample the execution of the process into the trace.

[0278] 1638: Calling the routine

[0279] 1640: Entering the routine

[0280] 1642: Exiting the routine

[0281] 1646: Compiled code

[0282] 1648: Redirecting function calls

[0283] 1650: Identify a routine or other code unit as a routine or other code unit designated for tracing.

[0284] 1700: Configure the system to control tracking using a task log indicator. 1702: Configure the system to control tracking using a task log indicator.

[0285] 1704: Controlling tracking by using task log indicators

[0286] 1706: Using the Task Log Indicator

[0287] 1708: Detecting calls to the task creation function

[0288] 1710: Modify the task creation function

[0289] 1712: Set the task log indicator

[0290] 1714: Detecting calls to the function that executes the task.

[0291] 1716: Modify the task execution function

[0292] 1718: Task Tracing

[0293] Operating environment

[0294] refer to Figure 1 The operating environment 100 used in this embodiment includes at least one computer system 102. The computer system 102 may or may not be a multiprocessor computer system. The operating environment may include one or more machines within a given computer system, which may be clustered in a cloud, networked as client servers, and / or peer-to-peer. Individual machines are computer systems, as are groups of collaborating machines. The given computer system 102 may be configured for, for example, end users with applications, for administrators, as servers, as distributed processing nodes, and / or otherwise.

[0295] Human user 104 can interact with computer system 102 via typed text, touch, voice, mobile, computer vision, gestures, and / or other forms of I / O, using a display, keyboard, and other peripheral devices 106. Screen 126 may be a movable peripheral device 106 or may be an integral part of system 102. The user interface may support interaction between the embodiment and one or more human users. The user interface may 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 may be presented as different options or may 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., representing one or more individuals can also be users 104. Storage devices and / or network devices may be considered peripheral devices in some embodiments, and in other embodiments, they may be considered part of system 102, depending on their separability from processor 110. For example, Figure 1 Other computer systems, not shown, may technically interact with computer system 102 or another system embodiment via one or more connections to network 108 via network interface devices.

[0297] Each computer system 102 includes at least one processor 110. Like other suitable systems, computer system 102 also includes one or more computer-readable storage media 112. Media 112 can be of various physical types. Media 112 can be volatile memory, non-volatile memory, in-situ fixed media, removable media, magnetic media, optical media, solid-state media, and / or other types of physically persistent storage media (as opposed to media that merely transmits signals). Specifically, when inserted or otherwise installed, configured media 114 (such as portable (i.e., external) hard disk drives, CDs, DVDs, memory sticks, or other removable non-volatile storage media) can functionally become a technical part of the computer system, making its contents accessible for interaction with and use by the processor 110. Removable configured media 114 is an example of computer-readable storage media 112. Other examples of computer-readable storage media 112 include built-in RAM, ROM, hard disks, and other memory storage devices that are not readily removable by the user 104. To comply with current U.S. patent requirements, under any pending or granted claim in the United States, a computer-readable medium, a computer-readable storage medium, or a computer-readable memory is not a signal itself or merely energy.

[0298] For example, medium 114 is configured with binary instructions 116 executable by processor 110; "executable" is used broadly herein to include, for example, machine code, interpreted code, bytecode, and / or code running on a virtual machine. Medium 114 is also configured with data 118, which is created, modified, referenced, and / or otherwise used for technical effects through the execution of instructions 116. 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, instructions 116 and data 118 also configure the computer system. In some embodiments, a portion of data 118 represents real-world items such as product characteristics, inventory, physical measurements, settings, images, readings, targets, volumes, and so on. Such data may also be transformed through backup, restore, commit, abort, reformatting, and / or other technical operations.

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

[0300] In addition to 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. Display 126 may include one or more touchscreens, a screen responsive to input from a pen or tablet, or a screen for output only. In some embodiments, peripheral devices 106, such as human user I / O devices (screen, keyboard, mouse, tablet, microphone, speaker, motion sensor, etc.), will operatively communicate with one or more processors 110 and memory. The software process may be user 104.

[0301] In some embodiments, the system includes multiple computers connected by network 108. The networking interface device may use components such as packet-switched network interface cards, wireless transceivers, or telephone network interfaces to provide access to network 108; for example, the components may reside within a given computer system. However, embodiments may also convey 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 understand that the foregoing and other aspects presented herein in the context of an "operating environment" can form part of a given embodiment. The headings of this document are not intended to strictly categorize features into sets of features specific to embodiments and non-embodiments.

[0303] One or more items are shown in dashed lines in the accompanying drawings, or listed in parentheses, to emphasize that they are not necessarily part of the illustrated operating environment or all embodiments, but may interoperate with items in the operating environment or some embodiments discussed herein. Items not shown in dashed lines or parentheses are not necessarily required in any drawing or any embodiment. In particular, Figure 1 It is provided for convenience; in Figure 1 The inclusion of an item does not imply that the item or the use described therein was known prior to this invention.

[0304] Tracking Environment

[0305] Figure 2 and 3 The real-time process environment is shown respectively; Figure 2 The managed code 208 is shown, while Figure 3 Native code 308 is shown. Environments 200 and 300 are also discussed in detail above. Of particular interest here are tracker 204 and the trace 220 generated by tracker 204. Tracker 204 and trace 220 may include familiar aspects, but they will also reflect and benefit from the selective tracking innovations taught herein.

[0306] In each environment 200, 300, there exists a tracer 204. The tracer 204 was originally designed and implemented or has been adapted to perform selective tracing as taught herein. A debugger 202 may also exist in one or both of 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 trace 220 previously created by the tracer.

[0307] track

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

[0309] Some tracing processes record only two types of data. One type of data is the execution of code instructions 116 that may be executed in parallel on multiple threads. The other type of data is a snapshot 216 of a specific block of memory taken at discrete points during 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, a trace contains a valid representation of all recorded instructions and all their inputs and outputs. The recording of trace 220 can be made efficient by relying on the determinism of processor(s) 110 and primarily recording information that cannot be inferred from that determinism, as well as information already recorded in trace 220. Much of trace 220 in some implementations is data, not the executed code instructions; such data is typically non-deterministic. A trace can primarily consist of seed data plus non-deterministic information. In some cases, only information about the processor(s) being traced is recorded in trace 220; for example, a read of the value V from a processor register is entered into the trace, but a write of the value V from the register to memory location X need not be entered into the trace. If the write operation to X differs in the behavior of the traced program, it is because at some point the written value returns from X to the processor register, and at that point, if tracing is still enabled, the entry in trace 220 can be made.

[0310] Figure 5 Various memories 112 that can be traced and therefore examined in accordance with the teachings herein are shown. Examples of memory cells 502 shown include stack 504 (including data such as its base address 506 and allocated stack frames 508), heap contents 510 such as object 512, or metadata such as garbage collection data, cache 514, processor registers 516, object members such as attribute 518, addressable cells in ROM 520 or RAM 524, removable or third-level memory 522, local memory 526, and global memory 528. Memory cells may have one or more characteristics 530 that increase or decrease the accessibility of the memory cell; for example, the memory may be in kernel space, may be shared, may be subject to DMA, etc.

[0311] Figure 6 The activity information 444 of thread 602 that can be captured in a given trace 220 is shown. Thread identifier 604, thread state indicator 606, executable code of the thread 608, 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 in this document to help illustrate various aspects of the technology; however, the examples given in this document do not describe all possible embodiments. 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 deviate from the examples provided herein.

[0314] Figure 7 A system 102 configured for selective tracing, as taught herein, is illustrated. One or more portions 702 of code are designated for tracing using one or more specified criteria 704. For example, criteria 704 may include a list of function names or identifiers, file names, object names, method names, module names, routine names, or other identifiers of portions 702 that the developer wishes to include in the tracing. Criteria may also, or alternatively, include attributes or special instructions located within the code of a procedure that can be identified by the runtime or debugger during procedure execution and used to trigger tracing. The phrases “included in tracing” and similar expressions in this document indicate that tracing is enabled or will be enabled when the code in the specified portion is executed. In particular, criteria 704 may specify “user code,” such that tracing is substantially limited to software considered to be “user code,” where “substantially” means that 90% (or other value chosen by a particular administrator) of the traced code is user code. The eligible 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. Tracing is temporarily paused after the executing thread exits the "user code" and resumes when it re-enters the user code. Some implementations support tracing based on user-configured scopes. Users can configure tracing to be enabled for short periods, such as 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 can be implicitly or explicitly specified for exclusion from the trace. For example, a developer can set a specified standard 704 to exclude any or all of the following from the trace: non-user code base 708 (such as standard libraries or third-party libraries), kernel code 120, compiler code 710 (including, for example, preprocessors, the compiler itself, assemblers, linkers, interpreters), or garbage collection code 712.

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

[0317] The system 102 shown includes a tracker 204 configured with a tracking controller 700. Aspects of the tracker 204 may be familiar, while other aspects include or utilize selective tracking modifications 714. Familiar trackers may have a tracking enabler 718, a tracking disabler 716, and a tracking state 730, although these have not previously been used for selective tracking according to 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 stop tracking values ​​722, thresholds 726 and 728, a task record indicator 740 for one or more tasks, a create task modifier 731 that can change how the create task function operates, an execute task modifier 732 that can change how the execute task function operates, and routines whose routines are functionally equivalent to those of the combined task modifier. Figure 9 The code described, the changes and combinations Figure 10 The code describing the tracking state 730, the counting assurance code 1120, the code implementing one or more adjustment conditions 1210, and such combination Figure 13-16 The code that operates as described in one or more diagrams, and how it combines Figure 17 The code that operates as described.

[0318] According to one aspect, selective tracing modification 714 includes or uses distance variable 720. There may be a single distance variable during tracing, or there may be multiple distance variables, such as one per thread. For clarity, the discussion herein assumes that each process has a single distance variable, but those skilled in the art will readily apply these teachings when selective tracing is implemented using two or more distance variables that can independently disable tracing. Those skilled in the art will also understand that various names can be given to the distance variable in a given implementation. Here it is referred to as a "distance variable" simply to remind people of its usage: one way to describe its proper use is to interpret the distance variable as a measure of the computational distance from the operation to which tracing will be turned off. The larger the value in the distance variable, the more tracing will be performed; conversely, when the distance variable reaches zero (or some other stop tracing value 722), tracing will be disabled.

[0319] According to another aspect, selective tracking modification 714 includes or uses flags, Boolean values, or other identifiers to indicate that a task is being tracked, such as task logging indicator 740. More specifically, functions identified as to be tracked (such as functions explicitly enumerated or identified by the parts(s) specified for tracking 702, or functions that meet specified criterion 704) can create and execute one or more tasks, including asynchronously executing tasks across different processes and / or threads at indeterminate times. As utilized herein, the terms "asynchronously executed task" or "asynchronous task" refer to code that is enumerated and executed at different and indeterminate times and within different processes and / or threads. Task creation can be performed by a task creation function, which can be modified by task creation modifier 731 to include a check on whether the task or thread itself is being tracked in the execution context of the task or thread in which the task creation function is being called. If so, even if such a newly created task will be executed asynchronously, task logging indicator 740 can be updated to include an indication that the newly created task will also be tracked. Subsequently, when a newly created task (such as asynchronously in a different execution process or execution thread) is executed, the execution task function that triggered its execution may have been or is currently modified by the execution task modifier 732 to include checks on whether the task to be executed is marked for tracking, such as by checking one or more values, which are set by the task logging indicator 740. Figure 7 The text indicates that if the execution task function modified by the execution task modifier 732 detects that a task has been marked for tracing, the modified execution task function can trigger tracing, such as through the tracing enabler 718, as described herein.

[0320] As used herein, the term “record” is synonymous with “track” at least in the sense of naming variable identifiers. Therefore, 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 referring to “recorded” code and “tracked” code, although for the sake of 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 highlight the computational advantages of the innovations described herein. The system on the left is 102 configured with distance variable 720, and the system on the right is a variant 802 lacking distance variable and other selective tracking modifications 714. In each system, tracking is performed on at least a designated portion 702 of process 206. In each case, tracking has associated computational costs 804, such as the number of processor cycles executed. Figure 13As illustrated in the example, 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 fewer calls are made to enable tracing and fewer calls are made to disable tracing. One trade-off is that when selective tracing modifications 714 are used, tracing 220 will tend to be larger compared to when they are not used. However, by setting thresholds 726 and 728, control can be exercised over the size of the tracing to balance the increase in tracing size with the reduction in computational cost of tracing.

[0322] Figure 9 A specific design of the tracking controller 700 is shown; it should be understood that other designs may also utilize the teachings presented herein and, based on... Figure 10 , 13 Operate using the various methods shown in -16. Figure 9 The routines and parameters shown are a generalization of a specific implementation example. This specific implementation example includes a selective tracing interface 714 with functions described below, which runs on top of the underlying execution tracing technique 204. The underlying tracing technique 204 can provide, for example, during execution... Windows Event Tracing (ETW) (also known as "Time Travel Tracing" or part of "Time Travel Debugging") is used to trace events on a Microsoft (a trademark of Microsoft Corporation) system during runtime. Tracked on systems of 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 referenced in this article include the following.

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

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

[0326] SetMaxInstructionsToRecord(maxInstructions): Instructs the underlying tracing technique to stop recording after the maxInstructions instruction has been executed in the current thread.

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

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

[0329] IsRecordingCurrentThread(): Return value (such as a boolean) that indicates whether the current thread is being tracked, such as by using the TryStartRecordingCurrentThread() function, which was called in its execution context.

[0330] StopRecordingCurrentThread(): If the current thread is being traced, instructs the underlying tracing technique to stop recording the execution of the current thread.

[0331] IsTaskRecording(task): Returns a value (such as a boolean) that indicates 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 the process are considered "user code". Specifically, in this example, user code is specified for tracing, and all code in the process that is not explicitly specified for tracing is implicitly specified as not for tracing.

[0334] In the operation according to this example, each routine, considered "user code," is decoded at execution time. At a convenient early point in the thread's execution, a sufficiently large number of threadInstructions are used to call SetThreadInstructionsToRecord(threadInstructions). Administrator 104 can determine what constitutes early, convenient, sufficiently large, sufficiently small, and similar characteristics referenced herein, considering the trade-offs between trace size and computational cost mentioned above, and the capabilities of decoding, injection, and logging techniques 204.

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

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

[0337] Call CallTryStartRecordingCurrentThread().

[0338] Insert code 1408 before each exit point 1204 of the function (return, function call, exception throwing, etc.):

[0339] Call SetThreadInstructionsToRecord(GetThreadInstructionsToRecord()-GetR emainingInstructionsToRecord()), 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 can cache the specified infinite value.

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

[0342] When the resulting code is executed, the distance from the stop logging event or call 716 changes as the distance variable `maxInstructions` changes value. The distance increases upon entering designated section 702 and then decreases upon exiting. If the exit passes control to another designated section, the distance increases again. If the exit does not pass control to another designated section, one of these two events tends to occur (in this example, the possibility of another call within this call is ignored for simplicity).

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

[0344] Another possibility is that the entered portion 706 is not specified for tracing sufficiently so that maxInstructions will continue running until it reaches zero. If this occurs while control is still in the entered portion 706, then the tracing controller 700 shuts down tracing when maxInstructions reaches zero. In this case, the additional tracing will include records of the initial portion, but not the entirety, of the entered portion 706.

[0345] Control can eventually return to another designated section 702, in which case tracking will be re-enabled, and `maxInstructions` will be assigned a relatively large value, although not necessarily the same large value as before. Alternatively, the process can end or terminate without control being passed back to another designated section 702, in which case tracking will remain off, or at least not re-enabled by the selective tracking mechanism 700. Several other mechanisms can re-enable tracking; however, in this case, it is best to use other mechanisms in conjunction with the tracking controller 700 to avoid unexpected or undesirable effects on tracking 220.

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

[0347] Figure 10 A tracing state diagram 1000 is shown, illustrating the operation of some embodiments. The tracing state diagram 1000 illustrates tracing within the context of a given thread, and it should be understood that the teachings herein can be applied to both single-threaded and multi-threaded environments. Figure 10 An instance of a state machine can be used independently between threads that have a corresponding thread-local distance variable DV. For example, in Figure 10 As shown near the center on the right, the execution of process 206 to be traced begins with tracing in a closed state 1004, which may also be referred to as a tracing disabled state, a non-tracing state, or a non-recording state. One or more instructions 116 of the process are executed 1006 without changing the tracing state. At some point, in this example, after executing one or more instructions 1006, the execution of the process reaches the try-to-trace() routine 916. The execution 1008 of the try-to-trace() routine 916 determines that the distance variable 720 (also referred to as "DV" in the diagram) 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, which in this example implements or calls the trace-on routine() of the tracing enabler 718. Figure 10 As shown, tracking state 730 then transitions to tracking enabled state 1002. For example, tracking enabled state 1002 can also be called tracking enabled state or recording state.

[0348] Control is transferred to Figure 10 The execution record decrement test loop is shown in the upper left corner. One or more instructions 116 of the process are executed 1006, and the corresponding record 1012 is executed using the underlying tracing technology 204. The correspondence between individual instructions 116 and entries in tracing 220 can be one-to-one or not. For example, tracing technology 204 can perform sampling 1636 by recording every M instructions, where the integer M>1 is a previously specified sampling period. For example, the sampling period M is set by the administrator 104, or by the default or configuration parameters of the underlying tracing technology 204. When record 1012 is executed, the distance to the record being disabled is correspondingly reduced by decrementing the distance variable 1014. If the distance variable reaches zero, the tracing state transitions back to the tracing off state 1004, and the tracing disabler 716 is invoked 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 try-to-trace() calls. For example... Figure 10 As shown in the lower left portion, in state 1002, the execution of try-to-trace() 1008 will determine that the distance variable is non-zero and therefore will not change the distance variable. Control will then return to... Figure 10 The execute-record-decrement-test loop shown in the upper left corner executes part of process 1006, records the tracking data corresponding to 1012, decrements the distance variable by 1014, and tests the distance variable to see if it has reached the stop tracking value (zero in this example).

[0350] like Figure 7 As shown, some parts 702 of the code of the process to be traced can be specified, and other parts 706 can be implicitly or explicitly designated as not currently of interest and therefore not traced, unless they may be accidentally marked as a byproduct of the use of distance variable 720. Parts 702 and 706 can be code units, such as threads, libraries, etc. That is, the tracing specification 704 can be implicitly or explicitly applied to parts 702 and 706, the boundaries of parts 702 and 706 being the boundaries of certain code units 1100, some of which are in Figure 11 As shown in the image.

[0351] like Figure 11As shown, code unit 1100 can be one or more of the following, or a collection of one or more of the following: thread 602, function 1102, or other routine 1104 performing one or more tasks (including asynchronously, such as by marking related code with an "asynchronous" modifier or other similar identifier in one or more other execution threads), coroutine 1106, exception handler 1108, interrupt handler 1110, implementation 1116 of virtual method 1114, callback 1118, library 1122, module 1124, or another code unit 1112. For tracing purposes, the entire kernel 120 can be a code unit.

[0352] exist Figure 11 The count assurance code 1120 is also shown, but this is for convenience and completeness when listing ways in which the code can be categorized. Count assurance code 1120 includes code such as the set-DV routine 910, which exists to implement trace control, the opposite of the part that traces the process prior to the injection of modification 714.

[0353] Figure 12 Some aspects 1200 of the process code that may be of interest in the 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, having one or more entry points 1202 where control can enter code unit 1640, and one or more exit points 1204 where control can exit code unit 1642. Control may enter code unit 1640, for example, at the top of routine 1104 after caller 1206 calls routine 1638, and may exit routine 1642 after reaching the end of the routine or when another routine is called from 1638. "Control" refers to the current execution point 1208, i.e., a point in the execution of process 206, which 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 can be recorded using its context as a timecode 424 (such as the current thread ID 604).

[0354] Figure 12Several items that influence or determine one or more conditioning conditions 1210 are also shown. Conditioning conditions represent and implement a balance between the computational cost 804 of tracing, the size of tracing 220, and the specification 704 regarding what the developer wants to or does not want to trace. For example, conditioning conditions 1210 can be set by an administrator or by default. They can be determined based on experimental data, such as providing profile information on computational costs, or providing static analysis data on the length of routines and length distribution statistics. Conditioning conditions 1210 can be constant or variable throughout a particular execution of the traced process. Items involved in selective tracing of the execution of a conditioning process may include one or more of the following: a low count threshold 728 for the value of a distance variable, a high count threshold 726 for the value of a distance variable, the current value 1216 of the distance variable 720, information 1218 regarding the computational cost of routines and other code units 1100 in the traced process, and information 1220 regarding the computational cost of turning tracing off or on.

[0355] As a further illustration of adjusting thresholds 1210, 726, and 728, consider the following. Assume the computational cost of stopping tracking to not log a particular function (and then restarting it later) is equivalent to logging 1000 instructions. The distribution of instruction counts for functions the developer doesn't want to log is also a consideration. For example, suppose the developer needs 100 or fewer instructions to log 90% of the functions that logging would exclude. Adjustment could ask whether setting the low threshold 728 (or another count of instructions before automatically stopping logging) to 101 instead of 1 makes computational cost sense. In some architectures, if the flag to continue logging must be after a function prolog, it might not be possible to set that number below the threshold; therefore, at least the low must be high enough to accommodate any function prolog and calls to continue logging to avoid stopping logging before the instrumentation has a chance to tell the framework to continue (set it back high). Aside from those architectures, logging 90% of the functions the developer actually wants to exclude is computationally cheaper than excluding all functions. Therefore, the relevant adjustment information 1218 includes the possibility that specifying a function for exclusion will be cheaper than excluding, and that this information can be used to reduce or minimize the overhead of the record.

[0356] In the context of this adjustment discussion, the estimated cost reduction of 101 is that the average cost per function (100 * 0.9 + 1101 * 0.1) equals 200.1 instructions per function. This number would actually be lower if any of the recorded functions designated for exclusion had fewer than 100 instructions (which seems quite likely). The actual number is the average number of recorded instructions per function designated for exclusion, and the cost of 1 is 1001 instructions per function. Therefore, using a probability of 1218 for functions designated for exclusion below a given number supports choosing low as the preferred number.

[0357] Suppose that after setting the number to 101, the embodiment finds that actually 89% of the functions fit into 80 instructions. The embodiment can then dynamically lower the value to 81 (which is actually a better choice for that data). The number of instructions can also be dynamically increased; for example, if an embodiment observes that for 3% of the functions (of which 30% are not recorded), the recording stops at the end of the function, the embodiment can increase the value to accomplish this.

[0358] The distribution of probability 1218 can be collected in several ways. One way is through previous executions within the same recording session. Other sources of conditioning information may be available in the form of general statistics on the distribution of instructions for functions across industries, functions in codebases, or functions from previous records in that region.

[0359] refer to Figure 1-12 Some embodiments use or provide a selective execution tracing system, the system including: at least one processor 110 and a digital memory 112 operatively communicatively with the processor. Executable code 208, 308 is configured to execute a computer-implemented process 206 at execution time. 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 by the execution tracer at execution time, and a trace enabler 718 configured to enable tracing by the execution tracer at execution time. The system also includes a trace controller 700. The trace controller 700 includes a distance variable 720 having a value indicating the current computed distance from the execution of the trace disabler. The trace controller 700 is configured to invoke the trace disabler at execution time in conjunction with a distance variable having a stop tracing value 722, and subsequently invoke the trace enabler in conjunction with a distance variable not having a stop tracing value. The system's distance variable modifier 724 is configured to incrementally move the distance variable 720 closer to the stop tracking value as the executable code of process 206 is executed.

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

[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 runtime 210, which 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 requiring runtime 210, which 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 local-n parameter at execution; a get-N routine 906 configured to return the current value of the thread-local variable N at execution; a set-DV routine 910 having a tracing-max parameter 912 and configured to set a distance variable 720 to the value of the tracing-max parameter at execution; a get-DV routine 914 configured to return the current value of the distance variable 720 at execution; and a try-to-trace routine 916 configured to enable the tracing of the current thread 602 by the tracer 204 at execution if tracing is not already enabled.

[0363] In some embodiments, distance variable 720 represents the maximum number of instructions 116 to be traced, and distance variable modifier 724 is configured to decrement the distance variable as executable code executes. Additionally, trace controller 700 is configured to invoke trace disabler 716 upon execution in conjunction with the distance variable reaching zero as a stop tracing value 722, and subsequently invoke trace enabler 718 in conjunction with the distance variable being positive. The executable code of the traced process is configured (e.g., through injection of trace modification 714) upon execution to perform at least one of the following to ensure that the distance variable is not equal to the stop tracing value upon entering any executable code section designated for tracing: confirming that the distance variable is non-zero, or setting 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 logic 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 90% 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 specific percentage of routines and the average number of instructions in routines are examples of information 1218 regarding the computational cost of the code.

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

[0366] In some embodiments, the tracing controller 700 includes high-count assurance code 1120 in the exception handler 1108. The high-count assurance code is configured to set a distance variable to a value not less than a high-count threshold 726 upon execution. Therefore, tracing can be ensured to continue while handling exceptions without incurring the computational cost of calling and executing the tracing enabler 718 within the exception handler. Instead, tracing continues by setting the distance variable high enough to trace the desired portion (typically all) of the exception handler 1108.

[0367] Those skilled in the art will understand that other systems are also within the scope of the teachings presented herein. In particular, in some cases, other systems may use trace controller code that performs selective tracing, while in others they may not use specific APIs, variables, thresholds, trace file content, or the criteria specified in the examples illustrated herein. Any system or apparatus using any aspect or implementation of the selective tracing teachings provided is within the scope of this disclosure, whether or not they are in the examples herein. Any claim consistent with the following should be understood as, within the claims taught herein, a selective tracing system comprising trace modification or other trace controller code configured to perform selective tracing operations when executed with a processor, which replace or reduce calls to a trace disabler by using distance variables as taught herein.

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

[0369] method

[0370] The approaches to the selective tracing tools and techniques taught in this paper can be divided into two distinct but closely related categories: methods for configuring a system for selective tracing, and methods for performing selective tracing within a properly configured system. This will be discussed further below and elsewhere in this paper, for example in conjunction with... Figure 9 , 10 Sections 1 and 13 discuss each method.

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

[0372] The method 1400 shown embeds (also known as "insertion" or "injection") a high-count assurance code 1410 at a first position 1412 in the codes 208 and 308 of the procedure. This high-count assurance code 1410... Figure 13 In the text, it is shown as "DV=HIGH" after the TRACE-ON() call, while... Figure 9 The discussion shows a call to `SetThreadInstructionsToRecord(threadInstructions)` for threads with relatively large values. In some, but not all, cases, method 1400 also embeds low-count assurance code 1414 at a second position 1412 in the code of procedures 208 and 308. This low-count assurance code 1414... Figure 13 In the text, it is shown as "DV=LOW" before the call to enter B1, while... Figure 9 The discussion shows that it is a call to SetMaxInstructionsToRecord(e), where e is a relatively small number.

[0373] Incidentally, some embodiments make tracing decisions at runtime via code injection. One technical consequence of this is that the same code and binaries can be used for logging during development and production without any changes to the source code to allow tracing. Other mechanisms for implementing the tracing described above should also be considered. As an example, code patching can be used to modify the code to be traced before runtime, according to the mechanisms described herein. As another example, breakpoints can be inserted into the appropriate parts of the code being traced. When detected, the code can be modified as described herein, and execution of the modified code can then be resumed. As yet another example, two or more different codebases can be used, one instrumented and modified as described herein, while another lacks such instrumentation and modification. Then, selecting which codebase to execute, according to the mechanisms described herein, can trigger whether tracing is executed. As yet another example, code tracing can be triggered based on conditional or other similar branches that may remain untriggered during normal operation and have little or no effect on code execution unless triggered to initiate tracing according to the mechanisms described herein.

[0374] The method 1400 shown associates process codes 208, 308 with an instruction counter 1418, or other hardware 128, or a combination of a hardware clock, register, or circuit with decrementing software 1416. Thus, as in, for example, combined with Figure 10 The execution log decrement test loop discussed here automatically modifies the distance variable as the procedure code executes by bringing the distance variable closer to the stop tracking value. Figure 13 The DV decrease is not explicitly stated to avoid Figure 13 Readability decreases. Conversely, it can be understood that DV decreases as the code is executed.

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

[0376] The method 1400 shown configures the tracking controller 700 1424 to disable tracking 1426 when the distance variable reaches the stop tracking value 1428, and to enable tracking 1430 at another execution time. For example, this step can be accomplished, for instance, by inserting code that configures the process to perform a state 730 transition and otherwise operates as follows: Figure 10 As shown. Figure 13 and Figure 9 The discussion provides additional examples of configuring system 1424 to combine the state of distance variable 720 (whether it is a stop tracking value) to enable and disable tracking.

[0377] Figure 15 This is a flowchart illustrating an example of a selective tracking method 1500, which controls 1404 to track 1012 in a system configured by method 1400 or another suitable method. Any method for configuring a system for selective tracking, as taught herein, is a suitable alternative to method 1400.

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

[0379] Enter C2: Designated

[0380] DV = High

[0381] TRY-TO-TRACE() is already enabled.

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

[0383] Figure 15 The method shown includes: executing instruction 1006, and decrementing the distance variable by 1014 as the process proceeds. Figure 13 The left-hand side, this can be illustrated by any one of these items, since they are all executed and the distance variable DV decreases implicitly as these items are executed.

[0384] Figure 15The method shown includes: when the distance variable is not zero and tracking is enabled, recording execution information 1012 into tracking 220. Figure 13 The left side, this is shown, for example, by either TRACE-ON() or TRACE-OFF(), because they are both executed when DV is non-zero and tracking is enabled. To help emphasize the behavior with DV ( Figure 13 (left side) and behavior without DV ( Figure 13 The difference on the right side is that... Figure 13 The explicit RECORD operation is also shown. Therefore, when DV is present, B1 is logged (indicated by RECORD B1), while when DV is absent, B1 is not logged (tracing is turned off by the TRACE-OFF() call before ENTER B1: NOT DESIGNATED).

[0385] Figure 15 The method shown includes disabling tracking at 1426 when the distance variable reaches 1428 (zero) or another stopping tracking value. For example, this is achieved through... Figure 13 The following items shown on the left are explained:

[0386] EXECUTE UNTIL D==0

[0387] TRACE-OFF()

[0388] Figure 17 This is a flowchart illustrating an example of a selective tracing configuration method 1700 that can accommodate 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 asynchronously executing tasks being traced. For example, the function being traced may create and execute multiple tasks. Some of these tasks may execute 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, library 1122 code can be invoked, and functions provided by the library (such as task creation functions) can be utilized by the function being traced to create tasks that can be executed asynchronously. Continuing with such an example, library 1122 code can be invoked again, and functions provided by the library (such as task execution functions) can be utilized to execute the newly created task in a separate execution thread. Because such execution of library-provided functions can be skipped as previously described, the task being executed in a separate execution thread will not have been traced, even if it is a portion of the user code specified to be traced.

[0389] Thus, method 1700 can configure system 102 to control tracing 1012 by using task logging indicator 740 1704. The illustrated method 1700 detects calls to the task creation function 1708 or other triggers by the currently executing code (such as the currently executing task or thread). The task creation function 1710 can then be modified to include checks on whether the current task or thread is being traced. Such modifications 1710 can be performed via code injection by task creation modifier 731. Alternatively, task creation modifier 731 can present different versions of the executed task creation and include checks on whether the current task or thread is being traced. As yet another example, task creation modifier 731 can utilize breakpoints to detect 1708 and interrupt the execution of the task creation function. Therefore, as used herein, the term "modify task creation function" refers to altering the execution of the task creation function by inserting additional code, executing replacement code, or interrupting the execution of the task creation function, such as via hardware or software breakpoints.

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

[0391] Subsequently, calls to the 1714 execution task function can be detected, and the 1716 execution task function can be modified using the execution task modifier 732 to check whether a new task being executed should be traced. Similarly, such modifications can be performed via code injection, execution of different versions of the execution task, use of breakpoints, and other similar "modifications." Therefore, as used herein, the term "modify execution task function" refers to altering the execution of the execution task function by inserting additional code, executing replacement code, or interrupting the execution of the execution task function, such as via hardware or software breakpoints. The check for whether a new task being executed should be traced can be performed with reference to 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 record indicator 740 being checked can be a set of record indicators 1712 that checks record indicators of a previous task in the context of which the new task was previously created and is now being executed. If logging indicator 740 indicates that a new task being executed is to be traced, then tracing enabler 718 1718 can be invoked to trace the new task being executed. In this way, logging indicator 740 can be used to mark tasks for tracing across process or execution boundaries, so that asynchronously executed tasks can still be traced, even if the library code that supports the execution of such tasks asynchronously may not itself be traced, in order to obtain the technical advantages detailed above.

[0392] Unless otherwise stated, the technical methods shown in the figures or otherwise disclosed will be performed automatically by, for example, a tracking controller 700 or a system 102 configured with tracking modification 714. Within the scope of actions involving human administrators or other humans, the methods may also be performed partially automatically and partially manually. For example, a person may enter specified criteria 704 into the tool user interface and then initiate the execution of the process 206 being tracked, which allows tool 122 to configure process 1402 for tracking and then execute the configured process. However, a completely manual method is not considered here as an innovation. In a given embodiment, zero or more example steps of the method may be repeated, possibly with different parameters or data to be manipulated. The steps in the embodiments may also be performed in a different order than those shown in the figures. Steps may be performed sequentially, partially overlapping, or completely in parallel. The order in which steps are performed during a given method can vary from execution of one method to execution of another. Steps may also be omitted, combined, renamed, regrouped, or otherwise deviated from the illustrated flow if the method being performed is operable and conforms to at least one claim.

[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 to disabled tracing in terms of computational cost. The memory checking process includes embedding a non-zero high count assurance code 1410 at a first location in the executable code, the non-zero high count assurance code 1410 being configured to set a distance variable 1502 to a value not less than a high count threshold 726 during execution; associating an instruction count decrementing mechanism 724 or other decrementing mechanism 724 with the executable code 1416, the instruction count decrementing mechanism 724 or other decrementing mechanism 724 being configured to decrement the distance variable 1014 as the executable code executes; connecting an execution tracker 204 1420 to the executable code; configuring a tracking controller 700 1424 to disable tracking using the execution tracker 1426 when the distance variable reaches a stop tracking value (such as zero); and configuring the tracking controller 1424 to enable tracking using the execution tracker 1430 during at least a portion of the execution of the executable code when the distance variable is different from the stop tracking value.

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

[0395] Various criteria can be used to determine thresholds and other constraints regarding the distance variable value. In some embodiments, at least one of the following criteria is satisfied: the number of instructions in the trace disabler configured to disable the execution tracer is greater than a low count threshold; the number of instructions in the trace disabler configured to disable 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 the execution tracer's tracing is greater than the computational cost of executing a sequence of M instructions starting from the second location, where M is equal to the value of the distance variable at the second location; the value of the distance variable at the second location is not greater than the average number of instructions per routine in the executable code; the low count threshold is not greater than the average number of instructions per routine in the executable code; and the statistical execution cost of tracing routines not specified for tracing is less than the computational cost of calling the trace disabler at the second location to disable the tracing of those routines.

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

[0397] Those skilled in the art will understand that other methods are also within the scope of the teachings presented herein. In particular, in some cases, other methods 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 selective tracing teachings provided are within the scope of this disclosure, regardless of whether they are in the examples herein. Any claim consistent with the following should be understood as being within the scope of the claims taught herein: a selective tracing method comprising configuring a system with tracing modifications or performing such configuration, i.e., configuring or performing selective tracing operations by replacing or reducing calls to a tracing disabler using distance variables as taught herein.

[0398] Configured media

[0399] Some embodiments include a configured computer-readable storage medium 112. Medium 112 may include a disk (magnetic, optical, or otherwise), RAM, EEPROMs or other ROMs, and / or other configurable memories, particularly computer-readable media (which are not merely for transmitting signals or energy). The configured storage medium may in particular 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 to use embodiments employing, for example, a distance variable 720 having 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 adjustment conditions 1210 having constituting thresholds 726, 728 and information 1218, 1220, read in the form of data 118 and instructions 116 from the removable medium 114 and / or other sources (such as a network connection) to form the configured medium. As disclosed herein, the configured medium 112 is capable of inducing a computer system to perform technical processing steps for selectively tracking portions of the computer process execution. Therefore, the accompanying drawings help illustrate embodiments of the configured storage medium and processes, as well as system and process embodiments. In particular, Figure 10 , 1415, 16 or any other process steps taught herein may be used to help configure the storage medium to form the configured medium embodiment.

[0400] Some embodiments use or provide computer-readable storage media 112, 114 configured with code that, when executed by computer processor 110, performs a selective execution tracing method. This method includes the following: At the 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 the relative distance that disables tracing computationally. 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, enables tracker 204 to execute instructions for tracking up to the number of values ​​of the distance variable, and if tracing is already enabled, keeps tracing enabled. At the exit point of the code unit, the distance variable 1504 is set to a non-zero low-count threshold 728, less than the high-count threshold. The distance variable is automatically decremented by 1014 as the computer processor executes instructions of a computer process containing the code unit. When the distance variable is positive and the execution tracer is enabled, the execution tracer tracks the execution of the 1012 computer process, and disables the tracking of the execution of the 1426 computer process in response to the distance variable reaching zero at 1428.

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

[0402] In some embodiments, at an early execution point of a code unit, the selective execution tracing method sets the variable N, denoted here, 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 where at least one of the following criteria is met: no more than ten instructions of the code unit have been executed since the code unit received control; no more than one-tenth of the instructions of the code unit have been executed since the code unit received control. This example selective execution tracing method also modifies the code at the exit point of the code unit so that the value of N is subtracted by 1504 from the value of the distance variable at that exit point, thereby setting the distance variable to a non-zero low count threshold less than the high count threshold.

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

[0404] In some embodiments, the selective execution of the tracing method disables tracing K times (where K is positive) during the execution of computer process 206. Specifically, in this example, tracing is disabled for at least half of the aforementioned K times because the value of the distance variable reaches 1428 zero.

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

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

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

[0408] Some additional combinations and variations

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

[0410] in conclusion

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

[0412] Those skilled in the art will understand that implementation details may relate to specific code, such as a particular API, a particular type of trace data, and specific values, and therefore may not necessarily appear in every embodiment. Those skilled in the art will also understand that program identifiers and some other terms used in the discussion of details are implementation-specific and therefore not necessarily relevant to every embodiment. Nevertheless, while their presence is not necessarily required herein, such details can assist some readers by providing context and / or illustrate some of the many possible implementations of the techniques discussed herein.

[0413] References herein to embodiments having certain features X, and references elsewhere herein to embodiments having certain features Y, do not exclude embodiments having both features X and Y, unless such exclusion is expressly indicated herein. All possible limitations of the claims are within the scope of this disclosure, as any feature prescribed as part of an embodiment may be expressly removed from other embodiments, even if no specific exclusion is given in any example herein. The term “embodiment” is used herein only as a more convenient form of “process, system, article of manufacture, computer-readable medium of configuration and / or other example of the teachings herein applied in a manner consistent with applicable law.” Therefore, a given “embodiment” may include any combination of features disclosed herein, provided that the embodiment is consistent with at least one claim.

[0414] In each embodiment, not every item shown in the figures is required to be present. Instead, embodiments may include items not explicitly shown in the figures. While some possibilities are illustrated herein by way of specific examples in the text and figures, embodiments may deviate from these examples. For example, specific technical effects or features of the examples may be omitted, renamed, grouped differently, repeated, instantiated differently in hardware and / or software, or a mixture of effects or features appearing in two or more examples. In some embodiments, functionality shown in one location may also be provided in different locations; for example, those skilled in the art will recognize that functional modules can be defined in various ways in a given implementation without having to omit the desired technical effects from a collection of interactive modules considered as a whole.

[0415] The accompanying drawings are referenced throughout the text using reference numerals. Any apparent inconsistencies in the wording related to a given reference numeral in the drawings or text should be understood as simply broadening the scope to which that numeral refers. Even when using the same reference numeral, different instances of a given reference numeral may refer to different embodiments. Similarly, given reference numerals...

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

[0417] Instruction 110 can be processed by executing instructions.

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

[0419] The headings are for convenience only; information about a given topic can be found outside the section indicated by the heading.

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

[0421] Although exemplary embodiments have been shown in the accompanying drawings and described above, it will be apparent 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 has been described in language specific to structural features and / or procedural 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 need not be present or utilized in every embodiment. Rather, the specific features, actions, and effects described are disclosed as examples for consideration in implementing the claims.

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

Claims

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

2. The selective execution tracing 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, an elapsed system clock time, a number of trace entries.

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

4. The selective execution tracing system of claim 1, wherein at least one first portion of the executable code designated for tracing comprises native code, the native code being code configured to run without 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 set a thread-local variable to a value of the parameter local-n upon execution, the thread-local variable denoted herein as N; a get-N routine configured to return a current value of the thread-local variable N upon execution; a set-DV routine having a tracing-max parameter and configured to set the distance variable to a value of the parameter tracing-max upon execution; ​ ​ a get-DV routine configured to return, upon execution, the current value of the distance variable; and a try-to-trace routine configured to, if tracing has not been enabled, upon execution, enable tracing of the current thread by the execution tracer.

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

7. The selective execution tracing 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 cell 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 routines of the executable code.

8. The selective execution tracing system of claim 6, wherein the tracing controller comprises: external high count assurance code in the executable code at an entry point of a code cell, the high count assurance code configured to, upon execution, set the distance variable to a value that is not less than the high count threshold, wherein the code cell comprises at least one of the following: a thread, a function, a routine, a coroutine, an exception handler, an interrupt handler; low count assurance code in the executable code prior to a call to a virtual method within the code cell, the low count assurance 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 that is less than the high count threshold; and internal high count assurance code in the executable code in a first implementation of the virtual method, configured to, upon execution, set the distance variable to a value that is not less than the high count threshold; and wherein a second implementation of the virtual method does not have any code that sets the distance variable.

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

10. The selective execution tracing system of claim 1, wherein invoking the trace enabler conditioned 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.

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 configured to store a distance variable, the distance variable representing a maximum amount of computational cost incurred prior to invoking a trace disable, the method comprising: executing, at the at least one processor, executable code having: one or more first portions designated for tracing, and one or more second portions not designated for tracing; managing the distance variable based at least on the execution of the executable code, including: incrementally moving the distance variable closer to a stop trace value while the one or more second portions of the executable code are executing; and moving the distance variable away from the stop trace value while the one or more first portions of the executable code are executing; and managing tracing of the distance executable code based at least on a value of the distance variable, including: invoking the trace disable in conjunction with the distance variable reaching the stop trace value; and invoking a trace enable, after invoking the trace disable, conditioned on the distance variable not having the stop trace value, wherein the value of the distance variable causes tracing of at least a subset of the one or more second portions of the executable code during execution of the at least subset.

12. The selective execution tracing method of claim 11, 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.

13. The selective execution tracing method of claim 11, wherein the one or more first portions of the executable code designated for tracing comprise managed code, the managed code being code configured to run under control of a runtime, the runtime implementing at least one of memory garbage collection, code compilation.

14. The selective execution tracing method of claim 11, wherein at least one first portion of the executable code designated for tracing consists 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 conditioned 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.

16. A computer-readable storage medium configured with code, which, when executed by a computer processor comprising a register configured to store a distance variable representing a maximum amount of computational cost incurred prior to invoking a trace disable, causes a computer system to at least: execute executable code at the at least one processor, the executable code having: one or more first portions designated for tracing, and one or more second portions not designated for tracing; manage the distance variable based at least on the execution of the executable code, including: incrementally moving the distance variable closer to a stop trace value while the one or more second portions of the executable code are executing; and moving the distance variable away from the stop trace value while the one or more first portions of the executable code are executing; and manage tracing of the distance executable code based at least on a value of the distance variable, including: invoking the trace disable in conjunction with the distance variable reaching the stop trace value; and invoking a trace enable conditioned on the distance variable not having the stop trace value after invoking the trace disable, wherein the value of the distance variable causes tracing of at least a subset of the one or more second portions of the executable code during execution of the at least the subset.

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, an elapsed system clock time, a number of trace entries.

18. The computer-readable storage medium of claim 16, wherein the one or more first portions of the executable code designated for tracing comprise managed code, the managed code being code configured to run under control of a runtime, the runtime implementing at least one of memory garbage collection, code compilation.

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

20. The computer-readable storage medium of claim 16, wherein invoking the trace enabler conditioned 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.

21. A computer program product comprising computer executable instructions, wherein said computer executable instructions implement the method of any one of claims 11 to 15 when executed by a processor.

Images