Patent application number | Description | Published |
20120222019 | Control Flow Graph Operating System Configuration - 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. | 08-30-2012 |
20120222043 | Process Scheduling Using Scheduling Graph to Minimize Managed Elements - A process scheduler may use a scheduling graph to determine which processes, threads, or other execution elements of a program may be scheduled. Those execution elements that have not been invoked or may be waiting for input may not be considered for scheduling. A scheduler may operate by scheduling a current set of execution elements and attempting to schedule a number of generations linked to the currently executing elements. As new elements are added to the scheduled list of execution elements, the list may grow. When the scheduling graph indicates that an execution element will no longer be executed, the execution element may be removed from consideration by a scheduler. In some embodiments, a secondary scan of all available execution elements may be performed on a periodic basis. | 08-30-2012 |
20120233601 | Recompiling with Generic to Specific Replacement - Executable code may be recompiled so that generic portions of code may be replaced with specific portions of code. The recompilation may customize executable code for a specific use or configuration, making the code lightweight and executing faster. The replacement mechanism may replace variable names with fixed values, replace conditional branches with only those branches which are known to be executed, and may eliminate executable code portions that are not executed. The replacement mechanism may comprise identifying known values defined in the executable code for variables, and replacing those variables with the constant value. Once the constants are substituted, the code may be analyzed to identify branches that may be evaluated using the constant values. Those branches may be reformed using the constant value and the rest of the conditional code that may not be accessed may be removed. | 09-13-2012 |
20120317557 | Pattern Extraction from Executable Code in Message Passing Environments - 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. | 12-13-2012 |
20120317577 | Pattern Matching Process Scheduler with Upstream Optimization - 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. | 12-13-2012 |
20120317587 | Pattern Matching Process Scheduler in Message Passing Environment - Processes in a message passing system may be unblocked when messages having data patterns match data patterns of a function on a receiving 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. | 12-13-2012 |
20120324454 | Control Flow Graph Driven Operating System - An operating system may be reconfigured during execution by adding new components to a control flow graph defining a system's executable flow. The operating system may use a control flow graph that defines executable elements and relationships between those elements. The operating system may traverse the control flow graph during execution to monitor execution flow and prepare executable elements for processing. By placing new components in memory then modifying the control flow graph, the operating system functionality may be updated or changed. In some embodiments, a lightweight version of an operating system may be deployed, then additional features or capabilities may be added. | 12-20-2012 |
20130067445 | Determination of Function Purity for Memoization - The purity of a function may be determined after examining the performance history of a function and analyzing the conditions under which the function behaves as pure. In some cases, a function may be classified as pure when any side effects are de minimis or are otherwise considered trivial. A control flow graph may also be traversed to identify conditions in which a side effect may occur as well as to classify the side effects as trivial or non-trivial. The function purity may be used to identify functions for memoization. In some embodiments, the purity analysis may be performed by a remote server and communicated to a client device, where the client device may memoize the function. | 03-14-2013 |
20130073523 | Purity Analysis Using White List/Black List Analysis - 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. | 03-21-2013 |
20130073604 | Optimized Settings in a Configuration Database with Boundaries - A set of optimizations may be defined in a configuration database. The configuration database may be defined with a set of boundaries that may define conditions under which the optimizations may be valid. When the conditions are not met, a new configuration database may be requested from an optimization server. The system may be used to distribute and manage optimizations for an application, which may be deployed in interpreted or runtime scenarios or in pre-execution or compiled scenarios. | 03-21-2013 |
20130073829 | Memory Usage Configuration Based on Observations - A computer software execution system may have a configurable memory allocation and management system. A configuration file or other definition may be created by analyzing a running application and determining an optimized set of settings for the application on the fly. The settings may include memory allocated to individual processes, memory allocation and deallocation schemes, garbage collection policies, and other settings. The optimization analysis may be performed offline from the execution system. The execution environment may capture processes during creation, then allocate memory and configure memory management settings for each individual process. | 03-21-2013 |
20130073837 | Input Vector Analysis for Memoization Estimation - A function's purity may be estimated by comparing a new input vector to previously analyzed input vectors. When a new input vector is within a confidence boundary, the new input vector may be treated as a known vector, even when that vector has not been evaluated. The input vector may reflect the input parameters passed to a function, and the function may be analyzed to determine whether to memoize with the input vector. The function may be a function that behaves as a pure function in some circumstances and with some input vectors, but not with others. By memoizing the function when possible, the function may be executed much faster, thereby improving performance. | 03-21-2013 |
20130074049 | Memoization Configuration File Consumed at Runtime - Memoization may be deployed using a configuration file or database that identifies functions to memorize, and in some cases, includes input and result values for those functions. As an application is executed, functions defined in the configuration file may be captured and memoized. During the first execution of the function, the return value may be captured and stored in the configuration file. For subsequent executions of the function, the return value may be stored in the configuration file. In some cases, the configuration file may be distributed with the return values to client computers. The configuration file may be created by one device and deployed to other devices in some deployments. | 03-21-2013 |
20130074055 | Memoization Configuration File Consumed at Compile Time - Memoization may be deployed using a configuration file or database that identifies functions to memorize, and in some cases, includes input and result values for those functions. At compile time, functions defined in the configuration file may be captured and memoized. During compilation or other pre-execution analysis, the executable code may be modified or otherwise decorated to include memoization code. The memoization code may store results from a function during the first execution, then merely look up the results when the function may be called again. The memoized value may be stored in the configuration file or in another data store. In some embodiments, the modified executable code may operate in conjunction with an execution environment, where the execution environment may optionally perform the memoization. | 03-21-2013 |
20130074056 | Memoizing with Read Only Side Effects - A function may be memoized when a side effect is a read only side effect. Provided that the read only side effect does not mutate a memory object, the side effect may be considered as an input to a function for purity and memoization analysis. When a read only side effect may be encountered during memoization analysis, the read only side effect may be treated as an input to a function for memoization analysis. In some cases, such side effects may enable an impure function to behave as a pure function for the purposes of memoization. | 03-21-2013 |
20130074057 | Selecting Functions for Memoization Analysis - A function may be selected for memoization when the function indicates that memoization may result in a performance improvement. Impure functions may be identified and ranked based on operational data, which may include length of execution. A function may be selected from a ranked list and analyzed for memoization. The memoization analysis may include side effect analysis and consistency analysis. In some cases, the optimization process may perform optimization on one function at a time so as to not overburden a running system. | 03-21-2013 |
20130074058 | Memoization from Offline Analysis - Memoization may be deployed using a configuration file or database that identifies functions to memorize, and in some cases, includes input and result values for those functions. The configuration file or database may be created by profiling target code and offline or otherwise separate analysis of the profiling results. The configuration file may be used by an execution environment to identify which functions to memorize during execution. The offline or separate analysis of the profiling results may enable more sophisticated analysis than could otherwise be performed in parallel with executing the target code, including historical analysis of multiple instances of the target code and sophisticated cost/benefit analysis. | 03-21-2013 |
20130074092 | Optimized Memory Configuration Deployed on Executing Code - A configurable memory allocation and management system may generate a configuration file with memory settings that may be deployed at runtime. An execution environment may capture a memory allocation boundary, look up the boundary in a configuration file, and apply the settings when the settings are available. When the settings are not available, a default set of settings may be used. The execution environment may deploy the optimized settings without modifying the executing code. | 03-21-2013 |
20130074093 | Optimized Memory Configuration Deployed Prior to Execution - A configurable memory allocation and management system may generate a configuration file with memory settings that may be deployed prior to runtime. A compiler or other pre-execution system may detect a memory allocation boundary and decorate the code. During execution, the decorated code may be used to look up memory allocation and management settings from a database or to deploy optimized settings that may be embedded in the decorations. | 03-21-2013 |
20130080760 | Execution Environment with Feedback Loop - An execution environment may have a monitoring, analysis, and feedback loop that may configure and tune the execution environment for currently executing workloads. A monitoring or instrumentation system may collect operational and performance data from hardware and software components within the system. A modeling system may create an operational model of the execution environment, then may determine different sets of parameters for the execution environment. A feedback loop may change various operational characteristics of the execution environment. The monitoring, analysis, and feedback loop may optimize the performance of a computer system for various metrics, including throughput, performance, energy conservation, or other metrics based on the applications that are currently executing. The performance model of the execution environment may be persisted and applied to new applications to optimize the performance of applications that have not been executed on the system. | 03-28-2013 |
20130080761 | Experiment Manager for Manycore Systems - An execution environment may have a monitoring, analysis, and feedback loop that may configure and tune the execution environment for currently executing workloads. A monitoring or instrumentation system may collect operational and performance data from hardware and software components within the system. A modeling system may create an operational model of the execution environment, then may determine different sets of parameters for the execution environment. A feedback loop may change various operational characteristics of the execution environment. The monitoring, analysis, and feedback loop may optimize the performance of a computer system for various metrics, including throughput, performance, energy conservation, or other metrics based on the applications that are currently executing. The performance model of the execution environment may be persisted and applied to new applications to optimize the performance of applications that have not been executed on the system. | 03-28-2013 |
20130081005 | Memory Management Parameters Derived from System Modeling - Optimized memory management settings may be derived from a mathematical model of an execution environment. The settings may be optimized for each application or workload, and the settings may be implemented per application, per process, or with other granularity. The settings may be determined after an initial run of a workload, which may observe and characterize the execution. The workload may be executed a second time using the optimized settings. The settings may be stored as tags for the executable code, which may be in the form of a metadata file or as tags embedded in the source code, intermediate code, or executable code. The settings may change the performance of memory management operations in both interpreted and compiled environments. The memory management operations may include memory allocation, garbage collection, and other related functions. | 03-28-2013 |
20130085882 | Offline Optimization of Computer Software - An offline optimization for computer software may involve creating optimized parameters or components for a software product, and charging customers for the optimization service. The software product may be distributed under one licensing regime and the optimization components may be distributed under a second licensing regime. In some embodiments, a low cost or no-cost monitoring system may be provided, which may interface with a remote service that optimizes the software product for its current workload. A user may pay for the remote optimization service through a subscription, pay-per-use, pay-for-performance, or other payment models. | 04-04-2013 |
20130117753 | Many-core Process Scheduling to Maximize Cache Usage - 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. | 05-09-2013 |
20130117759 | Network Aware Process Scheduling - A schedule graph may be used to identify executable elements that consume data from a network interface or other input/output interface. The schedule graph may be traversed to identify a sequence or pipeline of executable elements that may be triggered from data received on the interface, then a process scheduler may cause those executable elements to be executed on available processors. A queue manager and a load manager may optimize the resources allocated to the executable elements to maximize the throughput for the input/output interface. Such as system may optimize processing for input or output of network connections, storage devices, or other input/output devices. | 05-09-2013 |
20130219057 | Relationships Derived from Trace Data - 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. | 08-22-2013 |
20130219372 | Runtime Settings Derived from Relationships Identified in Tracer Data - 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. | 08-22-2013 |
20130227529 | Runtime Memory Settings Derived from Trace Data - 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. | 08-29-2013 |
20130227536 | Increasing Performance at Runtime from Trace Data - 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. | 08-29-2013 |
20130298112 | Control Flow Graph Application Configuration - 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. | 11-07-2013 |
20140013311 | Iterative 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. | 01-09-2014 |
20140026142 | Process Scheduling to Maximize Input Throughput - A schedule graph may be used to identify executable elements that consume data from a network interface or other input/output interface. The schedule graph may be traversed to identify a sequence or pipeline of executable elements that may be triggered from data received on the interface, then a process scheduler may cause those executable elements to be executed on available processors. A queue manager and a load manager may optimize the resources allocated to the executable elements to maximize the throughput for the input/output interface. Such as system may optimize processing for input or output of network connections, storage devices, or other input/output devices. | 01-23-2014 |
20140281726 | Bottleneck Detector Application Programming Interface - 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. | 09-18-2014 |
20140282597 | Bottleneck Detector for Executing Applications - 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. | 09-18-2014 |
20140298304 | Transmission Point Pattern Extraction from Executable Code in Message Passing Environments - 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. | 10-02-2014 |
20150052400 | Breakpoint Setting Through a Debugger User Interface - 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. | 02-19-2015 |
20150052403 | Snapshotting Executing Code with a Modifiable Snapshot Definition - 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. | 02-19-2015 |
20150052406 | Combined Performance Tracer and Snapshot Debugging System - A tracing and debugging system may collect both performance related tracer data and snapshot data. The tracer data may contain aggregated performance and operational data, while the snapshot data may contain call stack, source code, and other information that may be useful for debugging and detailed understanding of an application. The snapshot data may be stored in a separate database from the tracer data, as the snapshot data may contain data that may be private or sensitive, while the tracer data may be aggregated information that may be less sensitive. A debugging user interface may be used to access, display, and browse the stored snapshot data. | 02-19-2015 |
20150082285 | RUNTIME SETTINGS DERIVED FROM RELATIONSHIPS IDENTIFIED IN TRACER DATA - 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. | 03-19-2015 |