Concurix Corporation

Microsoft Technology Licensing, LLC

Google Inc.

Charles D Garrett

Alexander G Gounares

Ying Li

Michael D Noakes

Christopher W Fraser

Russell Steven Krajec

Thomas M Annau

Jonathan D Wilson

Rosemary Emery-Montemerlo

Aaron A D'Souza

Sharmila Subramaniam

Sanjay Joshi

Bryce B Baril

Alexadner G Gounares

A debugging system may display snapshot information that may be collected in response to an event identified while an application executes. The debugging system may allow a user to browse the various data elements in the snapshot, and may allow the user to modify a snapshot configuration by including or excluding various data elements within the snapshot data. The user interface may have a mechanism for including or excluding data elements that may be presented during browsing, as well as options to change the events that may trigger a snapshot. The updated snapshot configuration may be saved for future execution when the event conditions are satisfied.

Inserting snapshot code into an application

An application programming interface may receive workload identifiers and checkpoint identifiers from which bottleneck detection may be performed. Workloads may be tracked through various checkpoints in an application and timestamps collected at each checkpoint. From these data, bottlenecks may be identified in real time or by analyzing the data in a subsequent analysis. The workloads may be processed by multiple devices which may comprise a large application. In some cases, the workloads may be processed by different devices in sequence or in a serial fashion, while in other cases workloads may be processed in parallel by different devices. The application programming interface may be part of a bottleneck detection service which may be sold on a pay-per-use model, a subscription model, or some other payment scheme.

Bottleneck detector application programming interface

A tracing system may define an origin for consolidating and comparing trace paths within a traced application. A tracer may define an identifier that may be passed through a tracing route, and the identifier may be defined to capture specific instances or groups of instances of traces. The traces may be consolidated into a graphical representation of the program flow. The identifier may be passed across various boundaries, including function boundaries, library boundaries, application boundaries, device boundaries. An analysis system may consolidate or aggregate trace results having the same identifier, and may render such data graphically or provide statistics using the identified datasets.

User interface for selecting tracing origins for aggregating classes of trace data

Extractable annotations are created and stored for different transmission points. In some instances, this occurs during compiling. One type of transmission point is a message being passed to another process. Once the transmission point is identified, a pattern defining output for the transmission point is then identified. A first extractable annotation defining the first patter is then created and stored for subsequent use.

Transmission point pattern extraction from executable code in message passing environments

An analysis system may perform network analysis on data gathered from an executing application. The analysis system may identify relationships between code elements and use tracer data to quantify and classify various code elements. In some cases, the analysis system may operate with only data gathered while tracing an application, while other cases may combine static analysis data with tracing data. The network analysis may identify groups of related code elements through cluster analysis, as well as identify bottlenecks from one to many and many to one relationships. The analysis system may generate visualizations showing the interconnections or relationships within the executing code, along with highlighted elements that may be limiting performance.

Relationships derived from trace data

Memoizable functions may be identified by analyzing a function's side effects. The side effects may be evaluated using a white list, black list, or other definition. The side effects may also be classified into conditions which may or may not permit memoization. Side effects that may have de minimus or trivial effects may be ignored in some cases where the accuracy of a function may not be significantly affected when the function may be memoized.

Purity analysis using white list/black list analysis

Processes in a message passing system may be launched when messages having data patterns match a function on a receiving process. The function may be identified by an execution pointer within the process. When the match occurs, the process may be added to a runnable queue, and in some embodiments, may be raised to the top of a runnable queue. When a match does not occur, the process may remain in a blocked or non-executing state. In some embodiments, a blocked process may be placed in an idle queue and may not be executed until a process scheduler determines that a message has been received that fulfills a function waiting for input. When the message fulfills the function, the process may be moved to a runnable queue.

Pattern matching process scheduler with upstream optimization

A tracing and debugging system may take a snapshot of an application in response to an event, and may continue executing the program after the snapshot is captured. The snapshot may be stored and retrieved later in a debugging tool where a programmer may browse the snapshot or the snapshot may have some other analysis performed. The snapshot may contain a subset of the state of the application, such as call stacks, portions of source code, the values of local and global variables, and various metadata. The snapshot may be defined in a snapshot configuration that may include an event description and data to be collected.

Snapshotting executing code with a modifiable snapshot definition

Increasing performance at runtime from trace data

A process scheduler for multi-core and many-core processors may place related executable elements that share common data on the same cores. When executed on a common core, sequential elements may store data in memory caches that are very quickly accessed, as opposed to main memory which may take many clock cycles to access the data. The sequential elements may be identified from messages passed between elements or other relationships that may link the elements. In one embodiment, a scheduling graph may be constructed that contains the executable elements and relationships between those elements. The scheduling graph may be traversed to identify related executable elements and a process scheduler may attempt to place consecutive or related executable elements on the same core so that commonly shared data may be retrieved from a memory cache rather than main memory.

Many-core process scheduling to maximize cache usage

A bottleneck detector may analyze individual workloads processed by an application by logging times when the workload may be processed at different checkpoints in the application. For each checkpoint, a curve fitting algorithm may be applied, and the fitted curves may be compared between different checkpoints to identify bottlenecks or other poorly performing sections of the application. A real time implementation of a detection system may compare newly captured data points against historical curves to detect a shift in the curve, which may indicate a bottleneck. In some cases, the fitted curves from neighboring checkpoints may be compared to identify sections of the application that may be a bottleneck. An automated system may apply one set of checkpoints in an application, identify an area for further investigation, and apply a second set of checkpoints in the identified area. Such a system may recursively search for bottlenecks in an executing application.

Bottleneck detector for executing applications

A bottleneck detector may use an iterative method to identify a bottleneck with specificity. An automated checkpoint inserter may place checkpoints in an application. When a bottleneck is detected in an area of an application, the first set of checkpoints may be removed and a new set of checkpoints may be placed in the area of the bottleneck. The process may iterate until a bottleneck may be identified with enough specificity to aid a developer or administrator of an application. In some cases, the process may identify a specific function or line of code where a bottleneck occurs.

Iterative bottleneck detector for executing applications

An operating system may be configured using a control flow graph that defines relationships between each executable module. The operating system may be configured by analyzing an application and identifying the operating system modules called from the application, then building a control flow graph for the configuration. The operating system may be deployed to a server or other computer containing only those components identified in the control flow graph. Such a lightweight deployment may be used on a large scale for datacenter servers as well as for small scale deployments on sensors and other devices with little processing power.

Growing community of inventors

Woodinville, WA, United States of America

Charles D Garrett