Execution sequence information may be analyzed and quantified using n-gram analysis of functions executed by an application. The sequences of functions may be represented by n- grams, and the frequency of the various n-grams may indicate the behavior of the application in production, which may be compared to a test suite whose coverage may be quantified using a similar n-gram analysis. A coverage factor may compare the observed behavior of the application in production to the test suite for the application. The n-grams may be further quantified or prioritized by resource utilization, and several visualizations may be generated from the data.
G06F 9/455 - ÉmulationInterprétationSimulation de logiciel, p. ex. virtualisation ou émulation des moteurs d’exécution d’applications ou de systèmes d’exploitation
2.
COMPUTER PERFORMANCE PREDICTION USING SEARCH TECHNOLOGIES
A computer monitoring system may predict near term and long term performance by comparing a segment of current time series data with previously observed time series to find matching segments. From a matching segment, a prediction of performance may be made by examining later observations in the time series. Each time series element may include a large number of parameters, and one mechanism for comparing segments may be treating the elements as multi-dimensional vectors and using cosine similarity for finding significant matches. A deployment mechanism may store time series segments in a searchable database, and search the database with a newly observed time series segment for matches.
Production or development uses of an application may be identified from tracing data when the data fits a heuristic. The heuristic may include length of execution run, number of executions, repeating patterns within the execution run, or other factors. Similarly, prototyping or development uses of an application may be identified by frequent code changes, sporadic uses, low loads, and other factors. The production and development uses of an application may be displayed by a uses versus user graph, where production users may be displayed as those users with the largest number of uses. The tracing data may be gathered by monitoring an entire application or from monitoring functions, modules, subroutines, libraries, interfaces, services, or other portions of an application.
Recommendations may be generated while calculating performance metrics from multiple uses of a software component. A tracing service may collect trace data from multiple uses of a software component, where each use may be done on different conditions. The performance metric analysis may identify various factors that may affect the performance of a software component, then present those factors to a user in different delivery mechanisms. In one such mechanism, a recommended set of hardware and software configurations may be generated as part of an operational analysis of a software component.
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.
G06F 9/44 - Dispositions pour exécuter des programmes spécifiques
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
G06F 17/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des fonctions spécifiques
6.
MODULE SPECIFIC TRACING IN A SHARED MODULE ENVIRONMENT
A module-specific tracing mechanism may trace the usage of a module on behalf of the module developer. The module may be used by multiple application developers, and the tracing system may collect and summarize data for the module in each of the different applications. The data may include usage data as well as performance data. Usage data may include anonymized data for each time the module may be invoked and called, and performance data may include the processing time, memory consumption, and other metrics. The module-specific tracing may be enabled or disabled by an application developer.
G06F 17/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des fonctions spécifiques
G06F 17/30 - Recherche documentaire; Structures de bases de données à cet effet
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
7.
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.
An event chain visualization of performance data may show the execution of monitored elements as bars on a timeline, with connections or other relationships connecting the various bars into a sequential view of an application. The visualization may include color, shading, or other highlighting to show resource utilization or performance metrics. The visualization may be generated by monitoring many events processed by an application, where each bar on a timeline may reflect multiple instances of a monitored element and, in some case, the aggregated performance.
Code elements may be selected from a graph depicting an application. The graph may show code elements as nodes, with edges representing connections between the nodes. The connections may be messages passed between code elements, code flow relationships, or other relationships. When a code element or group of code elements are selected from the graph, the corresponding source code may be displayed. The code may be displayed in a code editor or other mechanism by which the code may be viewed, edited, and manipulated.
A marketplace for monitoring services providers may configure and deploy monitoring and other services that meet a solution definition for a given application. The services may include monitoring and tracing, analysis, rendering, debugging, optimizing, load generating, and other solution providers. The solution definition may include a schema or other data definitions for parameters gathered during application execution, as well as definitions for parameters or solutions that may be desired. The marketplace may identify those services that may be configured to meet the solution definition, then configure and deploy the selected services. A financial clearinghouse may handle financial payments to the various service providers.
A tracing system may use an evaluation mechanism to determine which functions to include or exclude during tracing. The architecture may evaluate functions when functions or groups of functions may be loaded for execution, as well as each time a function may be encountered. The evaluation mechanism may use whitelists, blacklists, and various expressions to identify which functions to trace and which functions to exclude. The evaluation mechanism may evaluate an expression that may identify specific conditions under which a function may be traced or not traced. The tracing mechanism may create wrapping functions for each function, including callback functions.
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.
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 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.
A tracing system may perform cost analysis to identify burdensome or costly trace objectives. For a burdensome objective, two or more objectives may be created that can be executed independently. The cost analysis may include processing, storage, and network performance factors, which may be budgeted to collect data without undue performance or financial drains on the application under test. A larger objective may be recursively analyzed to break the larger objective into smaller objectives which may be independently deployed.
G06F 19/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des applications spécifiques (spécialement adaptés à des fonctions spécifiques G06F 17/00;systèmes ou méthodes de traitement de données spécialement adaptés à des fins administratives, commerciales, financières, de gestion, de surveillance ou de prévision G06Q;informatique médicale G16H)
G06F 17/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des fonctions spécifiques
A tracing management system may use cost analyses and performance budgets to dispatch tracing objectives to instrumented systems that may collect trace data while running an application. The tracing management system may analyze individual tracing workloads for processing, storage, and network performance costs, and select workloads to deploy based on a resource budget that may be set for a particular device. In some cases, complementary tracing objectives may be selected that maximize consumption of resources within an allocated budget. The budgets may allocate certain resources for tracing, which may be a mechanism to limit any adverse effects from tracing when running an application.
G06F 17/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des fonctions spécifiques
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
A tracing system may divide trace objectives across multiple instances of an application, then deploy the objectives to be traced. The results of the various objectives may be aggregated into a detailed tracing representation of the application. The trace objectives may define specific functions, processes, memory objects, events, input parameters, or other subsets of tracing data that may be collected. The objectives may be deployed on separate instances of an application that may be running on different devices. In some cases, the objectives may be deployed at different time intervals. The trace objectives may be lightweight, relatively non-intrusive tracing workloads that, when results are aggregated, may provide a holistic view of an application's performance.
Periodicity similarity between two different tracer objectives may be used to identify additional input parameters to sample. The tracer objectives may be individual portions of a large tracer operation, and each of the tracer objectives may have separate set of input objects for which data may be collected. After collecting data for a tracer objective, other tracer objectives with similar periodicities may be identified. The input objects from the other tracer objectives may be added to a tracer objective and the tracer objective may be executed to determine a statistical significance of the newly added objective. An iterative process may traverse multiple input objects until exhausting possible input objects and a statistically significant set of input objects are identified.
G06F 11/00 - Détection d'erreursCorrection d'erreursContrôle de fonctionnement
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
Tracer objectives in a distributed tracing system may be compared to identify input parameters that may have a high statistical relevancy. An iterative process may traverse multiple input objects by comparing results of multiple tracer objectives and scoring possible input objects as being possibly statistically relevant. With each iteration, statistically irrelevant input objects may be discarded from a tracer objective and other potentially relevant objects may be added. The iterative process may converge on a set of statistically relevant input objects for a given measured value without a prior knowledge of an application being traced.
A distributed tracing system may use independent trace objectives for which a profile model may be created. The profile model may be deployed as a monitoring agent on non-instrumented devices to evaluate the profile models. As the profile models operate with statistically significant results, the sampling frequencies may be adjusted. The profile models may be deployed as a verification mechanism for testing models created in a more highly instrumented environment, and may gather performance related results that may not have been as accurate using the instrumented environment. In some cases, the profile models may be distributed over large numbers of devices to verify models based on data collected from a single or small number of instrumented devices.
A message passing compute environment may be visualized by illustrating messages passed within the environment. The messages may contain data consumed by a function or other computational element, and may be used to launch or spawn various computational elements. One visualization may be a force directed graph that has each function as a node, with messages passed as edges of the graph. In some embodiments, the edges may display the number of messages, quantity of data, or other metric by showing the edges as wider or thinner, or by changing the color of the displayed edge. The nodes may be illustrated with different colors, size, or shape to show different aspects. Some embodiments may have a mechanism for storing and playing back changes to the graph over time.
A force directed graph may display recent activities of a message passing system as highlighted features over a larger graph. The force directed graph may display a superset of nodes and edges representing processes and message routes, then display recent activities as highlighted elements within the larger superset. The highlighted elements may display messages passed or computation performed during a recent time element of a time series. In some embodiments, the effects of activities may be displayed by decaying the highlighted visual elements over time.
A force directed graph may display time series data using a set of playback controls to pause, play, reverse, fast forward, slow down, or otherwise control the display of the time series data. The playback controls may be used in a real time or near real time application to which data sets are displayed and the speed with which the data sets may be displayed. In one architecture, the force directed graph may be deployed using a rendering engine that receives data and renders the data into a graph. A playback controller may send updates to the rendering engine according to user inputs from the playback controls.
A visualization system for a tracer may include a processing pipeline that may generate tracing data, preprocess the data, and visualize the data. The preprocessing step may include a mechanism to process user-defined expressions or other executable code. The executable code may perform various functions including mathematical, statistical, aggregation with other data, and others. The preprocessor may perform malware analysis, test the functionality, then implement the executable code. A user may be presented with an editor or other text based user interface component to enter and edit the executable code. The executable code may be saved and later recalled as a selectable transformation for use with other data streams.
G06F 21/50 - Contrôle des utilisateurs, des programmes ou des dispositifs de préservation de l’intégrité des plates-formes, p. ex. des processeurs, des micrologiciels ou des systèmes d’exploitation
G06F 3/14 - Sortie numérique vers un dispositif de visualisation
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
24.
CONTROLLING APPLICATION TRACING USING DYNAMIC VISUALIZATION
A force directed graph may serve as a part of a user control for a tracer. The tracer may collect data while monitoring an executing application, then the data may be processed and displayed on a force directed graph. A user may be able to select individual nodes, edges, or other elements, then cause the tracer to change what data may be collected. The user may be able to select individual nodes, edges, or groups of elements on the graph, then perform updates to the tracer using the selected elements. The selection mechanisms may include clicking and dragging a window to select nodes that may be related, as well as selecting from a legend or other grouping.
G06F 17/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des fonctions spécifiques
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
A tracer may obfuscate tracer data such that the tracer data may be used in an unsecure environment even though raw tracer data may contain private, confidential, or other sensitive information. The tracer may obfuscate using irreversible or lossy hash functions, look up tables, or other mechanisms for certain raw tracer data, rendering the obfuscated tracer data acceptable for transmission, storage, and analysis. In the case of parameters passed to and from a function, tracer data may be obfuscated as a group or as individual parameters. The obfuscated tracer data may be transmitted to a remote server in some scenarios.
G06F 21/00 - Dispositions de sécurité pour protéger les calculateurs, leurs composants, les programmes ou les données contre une activité non autorisée
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
A parallel tracer may perform detailed or heavily instrumented analysis of an application in parallel with a performance or lightly instrumented version of the application. Both versions of the application may operate on the same input stream, but with the heavily instrumented version having different performance results than the lightly instrumented version. The tracing results may be used for various analyses, including optimization and debugging.
A load balanced system may incorporate instrumented systems within a group of managed devices and distribute workload among the devices to meet both load balancing and data collection. A workload distributor may communicate with and configure several managed devices, some of which may have instrumentation that may collect trace data for workload run on those devices. Authentication may be performed between the managed devices and the workload distributor to verify that the managed devices are able to receive the workloads and to verify the workloads prior to execution. The workload distributor may increase or decrease the amount of instrumentation in relation to the workload experienced at any given time.
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
An instrumented execution environment may connect to an execution environment to provide detailed tracing and logging of an application as it runs. The instrumented execution environment may be configured as a standalone service that can be configured and purchased. The instrumented execution environment may be deployed with various authentication systems, administrative user interfaces, and other components. The instrumented execution environment may engage a customer's system through a distributor that may manage a workload and distribute work to the instrumented execution environment as well as other worker systems. A marketplace may provide multiple preconfigured execution environments that may be selected, further configured, and deployed to address specific data collection objectives.
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
29.
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.
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.
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.
G06F 3/00 - Dispositions d'entrée pour le transfert de données destinées à être traitées sous une forme maniable par le calculateurDispositions de sortie pour le transfert de données de l'unité de traitement à l'unité de sortie, p. ex. dispositions d'interface
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.
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/30 - Dispositions pour exécuter des instructions machines, p. ex. décodage d'instructions
G06F 12/00 - Accès à, adressage ou affectation dans des systèmes ou des architectures de mémoires
34.
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.
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.
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.
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.
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.
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.
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.
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
G06F 17/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des fonctions spécifiques
G06Q 20/14 - Architectures de paiement spécialement adaptées aux systèmes de facturation
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/30 - Dispositions pour exécuter des instructions machines, p. ex. décodage d'instructions
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/44 - Dispositions pour exécuter des programmes spécifiques
G06F 17/00 - Équipement ou méthodes de traitement de données ou de calcul numérique, spécialement adaptés à des fonctions spécifiques
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/46 - Dispositions pour la multiprogrammation
44.
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.
Processes in a message passing system may be launched 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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/44 - Dispositions pour exécuter des programmes spécifiques
G06F 9/46 - Dispositions pour la multiprogrammation
46.
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/30 - Dispositions pour exécuter des instructions machines, p. ex. décodage d'instructions
G06F 9/45 - Compilation ou interprétation de langages de programmation évolués
47.
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/44 - Dispositions pour exécuter des programmes spécifiques
Executable code may be fingerprinted by inserting NOP codes into the executable code in a pattern that may reflect a fingerprint. The NOP codes may be single instructions or groups of instructions that perform no operation. A dictionary of NOP codes and their corresponding portion of a fingerprint may be used to create a series of NOP codes which may be embedded into executable code. The fingerprinted executable code may be fully executable and the presence of the NOP codes may not be readily identifiable. The fingerprinting mechanism may be used to authenticate executable code in various scenarios.
Processes may be assigned to specific processors when memory objects consumed by the processes are located in memory banks closely associated with the processors. When assigning processes to threads operating in a multiple processor NUMA architecture system, an analysis of the memory objects accessed by a process may identify processor or group of processors that may minimize the memory access time of the process. The selection may take into account the connections between memory banks and processors to identify the shortest communication path between the memory objects and the process. The processes may be pre-identified as functional processes that make little or no changes to memory objects other than information passed to or from the processes.
G06F 9/46 - Dispositions pour la multiprogrammation
G06F 9/30 - Dispositions pour exécuter des instructions machines, p. ex. décodage d'instructions
G06F 15/80 - Architectures de calculateurs universels à programmes enregistrés comprenant un ensemble d'unités de traitement à commande commune, p. ex. plusieurs processeurs de données à instruction unique
Processes may be assigned heap memory within locally accessible memory banks in a multiple processor NUMA architecture system. A process scheduler may deploy a process on a specific processor and may assign the process heap memory from a memory bank associated with the selected processor. The process may be a functional process that may not change state of other memory objects, other than the input or output memory objects defined in the functional process.
G06F 15/80 - Architectures de calculateurs universels à programmes enregistrés comprenant un ensemble d'unités de traitement à commande commune, p. ex. plusieurs processeurs de données à instruction unique
G06F 12/00 - Accès à, adressage ou affectation dans des systèmes ou des architectures de mémoires
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
A hybrid operating system may allocate two sets of resources, one to a first operating system and one to a second operating system. Each operating system may have a memory manager, process scheduler, and other components that are aware of each other and cooperate. The hybrid operating system may allow one operating system to provide one set of services and a second operating system to provide a second set of services. For example, the first operating system may have monitoring applications, user interfaces, and other services, while the second operating system may be a lightweight, high performance operating system that may not provide the same services as the first operating system.
An execution environment for functional code may treat application segments as individual programs for memory management. A larger program of application may be segmented into functional blocks that receive an input and return a value, but operate without changing state of other memory objects. The program segments may have memory pages allocated to the segments by the operating system as other full programs, and may deallocate memory pages when the segments finish operating. Functional programming languages and imperative programming languages may define program segments explicitly or implicitly, and the program segments may be identified at compile time or runtime.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/30 - Dispositions pour exécuter des instructions machines, p. ex. décodage d'instructions
G06F 9/45 - Compilation ou interprétation de langages de programmation évolués
G06F 12/00 - Accès à, adressage ou affectation dans des systèmes ou des architectures de mémoires
53.
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/22 - Aménagements de microcommande ou de microprogramme
G06F 9/46 - Dispositions pour la multiprogrammation
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 a system may optimize processing for input or output of network connections, storage devices, or other input/output devices.
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/30 - Dispositions pour exécuter des instructions machines, p. ex. décodage d'instructions
G06F 9/45 - Compilation ou interprétation de langages de programmation évolués
G06F 15/16 - Associations de plusieurs calculateurs numériques comportant chacun au moins une unité arithmétique, une unité programme et un registre, p. ex. pour le traitement simultané de plusieurs programmes
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.
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.
G06F 15/80 - Architectures de calculateurs universels à programmes enregistrés comprenant un ensemble d'unités de traitement à commande commune, p. ex. plusieurs processeurs de données à instruction unique
G06F 9/46 - Dispositions pour la multiprogrammation
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.
G06F 9/06 - Dispositions pour la commande par programme, p. ex. unités de commande utilisant des programmes stockés, c.-à-d. utilisant un moyen de stockage interne à l'équipement de traitement de données pour recevoir ou conserver les programmes
G06F 9/46 - Dispositions pour la multiprogrammation
brevets