Deriving profile data for compiler optimizations

Abstract

The method includes requesting, by a compiler responsive to execution of the first code segment, a first profile data set associated with the first code segment. The method also includes, in response to receiving an indication that the first profile data set is unavailable, performing a query operation to search for other code segments based on specified criteria related to attributes of the first code segment. The method also includes receiving search results from the query operation, the search results including the second code segment. The embodiment also includes generating an extrapolated profile data set based at least in part on the second code segment. The method stores the extrapolated profile data set in a memory associated with the first code segment, and the compiler performs an optimization operation on the first code segment using the extrapolated profile data set.

Description

[Technical Field]

[0001] The present invention relates generally to methods, systems, and computer program products for compiler optimization, and more particularly to methods, systems, and computer program products for deriving profile data for compiler optimization. [Background technology]

[0002] Computer programs are usually written in a programming language that is easily understood by an experienced programmer, and then translated into machine code that a computer processor can understand. For many programming languages, a compiler or interpreter translates a computer program into machine code. Generally, a compiler attempts to translate the entire program file at once and reports any errors at the end of this process, while an interpreter attempts to translate the program file one line at a time and stops if an error occurs.

[0003] For programs written using the Java programming language, source code is typically first translated into an intermediate language called bytecode, which is then translated into machine code. The primary compiler for Java is Javac, which translates Java source code into bytecode organized into class files. A utility called a class loader then loads the bytecode into a Java Virtual Machine (JVM). The JVM contains an interpreter and a just-in-time (JIT) compiler, which translates the bytecode and provides the resulting machine code to the computer processor for executing the program. Summary of the Invention

[0004] An exemplary embodiment provides for deriving profile data for compiler optimization. The embodiment includes, by a compiler responsive to execution of a first code segment, requesting a first profile dataset associated with the first code segment. The embodiment also includes, in response to receiving an indication that the first profile dataset is unavailable, performing a query process to search for other code segments based on specified criteria related to attributes of the first code segment. The embodiment also includes receiving search results from the query process, the search results including the second code segment. The embodiment also includes generating an extrapolated profile dataset based at least in part on the second code segment. The embodiment also includes storing the extrapolated profile dataset in memory such that the extrapolated profile dataset is associated with the first code segment in memory. The embodiment also includes performing an optimization process on the first code segment by the compiler based at least in part on the extrapolated profile dataset. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the embodiments.

[0005] Embodiments include a computer-usable program product that includes a computer-readable storage medium and program instructions stored on the storage medium.

[0006] An embodiment includes a computer system including a processor, a computer-readable memory, a computer-readable storage medium, and program instructions stored on the storage medium for execution by the processor via the memory.

[0007] The novel features believed to be characteristic of the invention are set forth in the appended claims. However, the invention itself, together with its preferred method of use, further objects and advantages, will best be understood by reference to the following detailed description of illustrative embodiments when read in connection with the accompanying drawings. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a block diagram of a network of data processing systems in which illustrative embodiments may be implemented; [Figure 2] 1 is a block diagram of a data processing system in which illustrative embodiments may be implemented; [Figure 3] FIG. 1 is a block diagram of an exemplary computing system in accordance with an exemplary embodiment. [Figure 4] FIG. 2 is a block diagram of an example virtual machine memory layout in accordance with an illustrative embodiment. [Figure 5] FIG. 2 is a block diagram of an exemplary virtual machine in accordance with an exemplary embodiment. [Figure 6] 1 is a flowchart of an example of a JIT compiler in accordance with an illustrative embodiment. [Figure 7] 10 is a flow chart of an exemplary profile derivation unit according to an exemplary embodiment. [Figure 8] FIG. 10 is a block diagram of an example virtual machine of an alternative example profile derivation unit in accordance with an example embodiment. [Figure 9] 1 is a flowchart of an exemplary process for generating profile data in accordance with an exemplary embodiment. [Figure 10] 10 is a flowchart of an alternative exemplary process for generating profile data in accordance with an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Software applications are typically written in source code, which is a high-level representation of the application that is convenient for programmers to write and understand. Specialized programs are then used to convert the application into another form that can be directly executed by a machine. These specialized programs may include compilers, interpreters, and hybrid systems that combine elements of compilers and interpreters. However, for convenience, these specialized programs will be referred to herein simply as compilers, and similarly, the translation process will be referred to simply as compilation, unless otherwise noted.

[0010] In general, compilers typically perform compilation either before runtime or during runtime. Each of these two options has certain advantages. For example, runtime compilers enable portability, automatic memory management, and dynamic code loading. On the other hand, the processing costs of runtime compilation can cause performance degradation compared to applications compiled before runtime. For this reason, runtime compilers also commonly use optimization algorithms to mitigate the impact of runtime compilation on program performance.

[0011] Optimization algorithms used at runtime typically include profile-guided optimization, which performs optimizations based on profile data. Profile data typically contains information summarizing the behavior of instructions at several profile points in a running application. Compilers use profile data to determine when and where to compile and optimize code segments, such as methods. For example, profile data might include a count of the number of times a particular instruction was executed by the virtual machine. This count allows the compiler to estimate how frequently that code segment will be executed in the future. If the count exceeds a threshold, the compiler applies optimizations to that code segment. Other types of profile data include information about the types of objects that reach type tests, targets of virtual method dispatches, and the lengths of arrays and strings.

[0012] There are two common methods for collecting profile data: sampling and program instrumentation. Sampling uses a timer to collect profile data periodically, while program instrumentation uses a trigger added to the application, such as the incrementing of a counter. When a compiler queries for profile data, it requests profile data for a particular method and bytecode offset. If profile data has been recorded for the particular method and bytecode offset, that data is returned in response to the request. On the other hand, if no profile data is available for the particular method and bytecode offset, a sentinel value indicating that no profile data is available is returned to the compiler in response to the request, preventing the compiler from performing the intended profile-guided optimizations.

[0013] Thus, the illustrative embodiments recognize that a lack of profile data hinders a compiler's ability to implement profile-guided optimizations. For example, without profile information, a compiler cannot identify which segments of program code are executed most frequently (e.g., the cyclic sequence of executions within a program), hindering runtime performance. Degraded runtime performance is generally undesirable because it can lead to reduced program throughput, increased memory overhead, or other suboptimal behavior. For example, in one test implementation, the absence of profile information reduced peak throughput on an X86 machine by 40%. Thus, the lack of profile information available to a compiler typically results in significant performance degradation.

[0014] Exemplary embodiments include embodiments that address this challenge by adapting compiler optimization processes to reduce instances where optimizations are not performed due to a lack of profile data. Exemplary embodiments recognize that alternative information can be used for compiler optimizations when profile data is unavailable. For example, in exemplary embodiments, such alternative information includes program state information, such as information from the state of a class hierarchy table, or extrapolated profile information, such as profile information extrapolated from other portions of the program. Exemplary embodiments recognize that compiler optimizations that use such alternative information provide significant performance improvements compared to forgoing optimizations due to a complete lack of profile information.

[0015] The exemplary embodiments described herein refer to the Java programming language, a Java Virtual Machine ("JVM"), a JIT compiler, an interpreter, and a Java Runtime Environment. However, alternative embodiments are used in combination with other programming languages, virtual machine architectures, or runtime environments. Thus, for example, terms described in Java terminology, such as "method," are interchangeable with other terms, such as "function." Furthermore, the term "method" is synonymous with the terms "class method" and "object method." A method is a set of code that is referenced by name and can be invoked at various points in a program, causing the method's code to be executed.

[0016] In some embodiments, a compiler uses program state information to optimize code segments in the absence of profile information for a code segment. For example, in some such embodiments, a compiler uses the state of a class hierarchy table to optimize code segments. One example of such optimization involves calls to potentially polymorphic methods, such as calls to virtual methods. For example, consider an abstract class "Shape" with a subclass "Circle" and another subclass "Square," where Circle implements a virtual method "draw" that creates a representation of a circle, and Square implements a virtual method "draw" that creates a representation of a square. If an array is declared to hold Shape objects and the "draw" method is invoked and iterated for each object, the implementation of each invocation of the virtual method "draw" will have different results depending on whether the object is a Circle or a Square. In some embodiments, a compiler determines whether a particular derived class is typically loaded and optimizes the code segment accordingly. For example, if Square is always loaded or most frequently loaded, the compiler can inline the implementation of Square and inject "guard code" that includes a type test to ensure that the object is a Square. If so, the inlined method code is executed, otherwise the non-optimized virtual method call for the other object type is reinstated.

[0017] In some such embodiments, a compiler processing an invocation of such a virtual method accesses data representative of the current state of the class hierarchy table to evaluate whether any of the derived classes have been loaded or instantiated. If the compiler determines that one or more of the derived classes have been loaded but none have been instantiated, it inlines only the parent class implementation of the virtual method, since none of the derived classes are viable dispatch targets.

[0018] In some such embodiments, instantiations of derived classes are tracked by profiling instrumentation at the time of object instantiation. In an alternative embodiment, instantiations of derived classes are tracked by processing the application heap at the time the snapshot is taken. In another alternative embodiment, instantiations of derived classes are tracked by combining data about which classes were instantiated by which methods (e.g., as tracked in the interpreter) with data from a call graph constructed to capture the flow of control from the snapshot point. In such an embodiment, the compiler combines dynamic execution state (e.g., data about which classes were instantiated by which methods) with static analysis (e.g., data from the snapshot point, such as data from the call graph) to generate a replacement for the lack of profiling information at a code location. Having the call graph and essentially performing reachability analysis on the instantiated classes starting at the code location where the classes were instantiated can determine the methods that an instance of a given class can reach. This context-sensitive approach using program state at the snapshot point can advantageously eliminate instantiated classes that are unreachable at a particular program point based on reachability analysis.

[0019] In some embodiments, if the compiler checks profile information for a particular code segment and determines that profile information is not available, the compiler initiates a query process that searches for other code segments in the program code that meet specified criteria. If the query process returns code segments that meet the specified criteria, the compiler generates extrapolated profile information using the code segments found by the query process.

[0020] In some embodiments, sometimes referred to herein as syntactic matching embodiments, the search criteria include criteria for syntactic matching of a particular code segment. In alternative embodiments, sometimes referred to herein as semantic matching embodiments, the search criteria include criteria for semantic matching of a particular code segment. In other alternative embodiments, sometimes referred to herein as context matching embodiments, the search criteria include criteria for context-dependent matching of a particular code segment. In further alternative embodiments, the search criteria include various combinations of syntactic, semantic, or context-dependent matching of a particular code segment, or combinations thereof.

[0021] In some syntax matching embodiments, a compiler processing a particular code segment for optimization initiates a query process for path execution frequency information and / or value profile information. In such embodiments, the compiler statically constructs a set of syntax patterns of interest based on the syntax of sequences within the particular code segment.

[0022] For example, in the case of path execution frequency information, a particular code segment may include the following bytecode sequence: aload_0 instanceof #1 “CustomerName” ifeq The compiler will determine whether there is profile information for the ifeq bytecode by querying the bytecode offset and method. If there is no profile information, the compiler will search for other locations in the program code that test the object to be an instance of CustomerName (e.g., other code segments in the program code that are associated with profile information, such as branch bias information for ifeq provided by the instanceof bytecode). In some embodiments, the compiler performs this search by generating syntactic search criteria that includes a statically constructed set of target syntactic patterns such as instanceof CustomerName followed by ifeq.

[0023] In some embodiments, the compiler assigns each such sequence a unique identifier. Each time a class is loaded, the compiler scans its bytecode for matches against a set of patterns and stores the method and bytecode offset of any pattern matches in a map data structure keyed by the pattern's unique identifier, with the map data structure holding tuples of method and bytecode offset that match each keyed pattern. In some embodiments, the compiler then looks up the pattern ID in case profile information is unavailable, and then checks recorded profile information for other locations that match the same pattern. If the pattern is parameterized by value or type, the compiler uses a multi-level map: pattern ID → parameters → parameters → set of method and bytecode offset tuples representing the matching locations.

[0024] As another example, for value profile information, a particular code segment may include the following sequence: Object obj = table.get(customerName); String s = obj.toString(); Based on the syntax of the above code segment, the compiler will search for toString calls on objects of declared type java / lang / Object for other code locations where this same code pattern appears, and use the bound value profile information to determine if CustomerRecord.toString should be inlined. If so, the compiler will inline the code with the guards profiled at code locations without profile information.

[0025] In some semantic matching embodiments, a compiler processing a particular code segment for optimization will statically construct a set of semantic patterns of interest (e.g., other locations in the program that may provide similar information from different patterns) based on sequences within the particular code segment. For example, the particular code segment may include the following bytecode sequence: aload_0 instanceof #1 “CustomerName” ifeq In some cases, the compiler may attempt a syntax match but may not find other locations in the program code where a syntactically matching code segment with profile information exists. Therefore, in an alternative embodiment, the compiler searches for other code segments that can provide similar profile information associated with code segments having different syntax patterns. For example, the program code may include a code segment where the code segment is associated with profile information such as: Object obj = table.get(customerName); String s = obj.toString(); In some embodiments, the compiler stores methods and byte-code offsets that match such patterns in a map data structure keyed by the pattern's unique identifier, where the map data structure holds tuples of methods and byte-code offsets that match each keyed pattern. Following this example, in some embodiments, the compiler determines the probability that the recipient is of type CustomerName versus some other type, and uses the probability to estimate whether a particular implementation should be inlined as the most likely invocation target for the toString call.

[0026] In some embodiments, the compiler uses rules for recognizing logically related conditions in the code to search for other code segments that can provide similar profile information related to code segments with different syntax patterns. For example, a particular code segment might include the following sequence: boolean condition = getSomeCondition(); If (condition) { … In some such embodiments, the compiler checks profile information for the code segment. If the compiler determines that there is no profile information for this code segment, the compiler then constructs a set of semantic patterns of interest based on sequences within this particular code segment (e.g., other locations in the program that may provide similar information from different patterns). The compiler stores the methods and bytecode offsets for such pattern matches in a map data structure keyed by the pattern's unique identifier. For example, a pattern match could have the following sequence: boolean condition = getSomeCondition(); if (!condition) { … } In some such embodiments, the compiler checks profile information for the code segment. If the compiler determines that the code segment has profile information, the compiler performs optimizations for the particular code segment being executed. For example, if the profile information indicates a branch bias, the compiler can use this information to derive a branch bias for the particular code segment and can optimize the particular code segment accordingly.

[0027] In some embodiments, the compiler searches for other code segments that can provide similar profile information associated with a code segment that has a different syntactic pattern, using rules to spot assignments that obscure the fact that the two code patterns are actually semantically similar. For example, a particular code segment might contain a sequence such as: Object obj = table.get(customerName); String s = obj.toString();

[0028] In some such embodiments, the compiler checks profile information for the code segment. If the compiler determines that there is no profile information for this code segment, the compiler then builds a set of semantic patterns of interest based on the rules and sequences within this particular code segment. For example, the pattern match may include the following sequence: Object obj1 = table.get(customerName); …other unrelated code… Object obj = obj1; String s = obj.toString();

[0029] In some such embodiments, the compiler checks profile information for the code segment. If the compiler determines that the code segment has profile information, the compiler performs optimizations on the particular code segment being executed. For example, if the profile information indicates an object type, the compiler can use this information to derive the object type of the particular code segment and can optimize the particular code segment by performing profile-guarded inlining on the derived type of the object.

[0030] In some such embodiments, the compiler uses any of a variety of pattern recognition techniques to find semantically similar code, such as reaching definitions, abstract interpretation, or value propagation. Such semantic matching embodiments enable more complete matching of code segments than syntactic matching by searching based on the semantics of the code segments with less concern for the actual structure of the code.

[0031] In some context matching embodiments, a compiler processing a particular code segment for optimization will identify candidate code segments, for example, according to a syntactic or semantic matching embodiment. When a compiler performs a syntactic or semantic search, it is searching for other operations that appear to be doing the same thing as the particular code segment being optimized. For example, the compiler may be searching the "draw" method of the abstract Shape class to determine the probability that Shape is a Square. There are many different, contextually relevant and unrelated locations that test whether a Shape is a Square or indicate the probability that a Shape is a Square. For example, an application may place a "draw" call on a Square in its application code as part of a larger code segment that draws different composite shapes. These locations that test whether a Shape is a Square contain the type of information the compiler is looking for. However, some of these locations are contextually similar because they are the same composite shape as the particular code being optimized, while others are contextually different because they are other composite shapes. In such cases, the type test probabilities may vary significantly depending on which composite shape is being drawn, leading to uncertain results. Therefore, if a compiler simply aggregates syntactically or semantically similar code, the results may be too uncertain to be a useful substitute for profile data.

[0032] Thus, a context matching embodiment identifies candidate code segments, for example, according to a syntactic or semantic matching embodiment, and then performs a context-sensitive analysis of each of the candidate code segments by evaluating their surrounding code segments. In such an embodiment, the compiler further searches for specific significant operations before the candidate code segment, or specific significant operations after the candidate code segment, or both. In some embodiments, the length of the operations is set or limited according to adjustable parameters. The longer the length of the operations searched for, the more costly it is from a processing standpoint to search for a match, and the lower the likelihood that the compiler will find a match, but the higher the likelihood that the search results will provide reliable information.

[0033] In some context matching embodiments, the compiler generates a matching pattern that includes syntactic or semantic search criteria for a particular code segment under optimization processing and criteria related to trace information that includes a length of operations that are prefix and / or suffix operations for the particular code segment. The compiler performs a syntactic or semantic search to identify candidate code segments that match the search criteria and have profiling information. For each candidate code segment, the compiler generates a trace for each candidate code segment that includes instruction sequences before and / or after the candidate code segment. As the compiler generates traces for each candidate code segment, it examines each trace to identify other patterns that match the trace criteria, resulting in a trace of recognized and profiled patterns for each candidate code segment.

[0034] In some context matching embodiments, once the compiler recognizes candidate code segments and generates traces of profiled patterns, the compiler inserts these traces into a data structure of candidate code segments. In some embodiments, the placement of the data structure is based at least in part on the degree of similarity between the particular code segment and each of the candidate code segments. For example, in some embodiments, the compiler inserts these traces into a suffix tree data structure to enable fast searching and fuzzy matching. Next, the compiler starts at a point where there is no profiling information, matches patterns to the particular code segment, generates traces from prefix and suffix operations on the particular code segment, and maps the traces to pattern traces. The compiler then takes this pattern trace and matches it to one or more existing traces with profile data using a known suffix tree matching algorithm. The compiler then uses the profile data from the matched traces to derive alternative profile information for the particular code segment during the optimization process. For example, a particular code segment may include the following sequence, which includes methods with profile data and methods without profile data: void wellProfiled(Object arg1, Object arg2) { if (arg1 instanceof CustomerRecord) { if (arg2 instanceof CustomerRecord) { … arg1.toString(); … arg2.toString(); ... } ... } if (arg1.equals(arg2)) { ... } else { ... } }

[0035] In this example, the call to arg2.toString() does not have any profile information that tells the compiler which implementation of toString will most likely be called. In some embodiments of context matching, the compiler selects a trace (e.g., a trace that includes all of the statements shown in the sample code above). In this example, the compiler has patterns that match the instanceof operation and the virtual call. The compiler takes the statements in the trace and reduces the statement trace to the following pattern trace: Instanceof(Object, CustomerRecord) -> instanceof(Object, CustomerRecord) -> virtual_call(CustomerRecord, toString) -> virtual_call(CustomerRecord, toString) -> equals(Object, Object) The compiler uses this pattern trace to match traces with profile data, attempting to find the closest match with the profile data of the second virtual_call in the matching sequence. The compiler can use the matched trace to provide receiver profile information that is aggregated and used to predict the dispatch target of the toString call.

[0036] For clarity of explanation, and without implying any limitations thereto, the exemplary embodiments are described using several exemplary configurations. From this disclosure, one skilled in the art may conceive of many changes, adaptations, and modifications of the described configurations to achieve the described objectives, and the same are contemplated within the scope of the exemplary embodiments.

[0037] Additionally, the figures and exemplary embodiments use simplified illustrations of data processing environments. An actual computing environment may contain additional structures or components not shown or described herein, or structures or components that differ from those shown but have similar functionality to those described herein, without departing from the scope of the exemplary embodiments.

[0038] Furthermore, the exemplary embodiments are described with reference to specific real or hypothetical components for illustrative purposes only, and the steps described by various exemplary embodiments may be adapted to provide explanations for decisions made by, for example, a machine learning classifier model.

[0039] Any particular representation of these and other similar artifacts is not intended to limit the present invention, and any suitable representation of these and other similar artifacts may be selected within the scope of exemplary embodiments.

[0040] The examples in this disclosure are used for clarity of explanation only and are not intended to limit the exemplary embodiments. Any advantages described herein are merely examples and are not intended to limit the exemplary embodiments. Additional or different advantages may be realized by certain exemplary embodiments. Furthermore, certain exemplary embodiments may have some, all, or none of the advantages listed above.

[0041] Furthermore, exemplary embodiments may be implemented with respect to any type of data, data source, or access to a data source via a data network. Any type of data storage device may provide data to an embodiment of the present invention, either locally at a data processing system or via a data network, within the scope of the present invention. Where an embodiment is described using a mobile device, any type of data storage device suitable for use with a mobile device may provide data to such an embodiment, either locally at the mobile device or via a data network, within the scope of exemplary embodiments.

[0042] The exemplary embodiments are described using specific code, comparative descriptions, computer-readable storage media, high-level features, historical data, designs, architectures, protocols, layouts, circuits, and tools as examples only and not as limitations of the exemplary embodiments. Furthermore, the exemplary embodiments may be described using specific software, tools, and data processing environments as examples only for clarity of explanation. The exemplary embodiments may be used in combination with other equivalent or similar purpose structures, systems, applications, or architectures. For example, other equivalent mobile devices, structures, systems, applications, or architectures therefor may be used in combination with such embodiments of the present invention within the scope of the present invention. The exemplary embodiments may be implemented in hardware, software, or a combination thereof.

[0043] The examples in this disclosure are used for clarity of explanation only and are not intended to limit the exemplary embodiments. Additional data, operations, actions, tasks, activities, and manipulations are contemplated by this disclosure, and the same are contemplated within the scope of the exemplary embodiments.

[0044] Any advantages described herein are exemplary only and are not intended to limit the exemplary embodiments. Additional or different advantages may be realized by certain exemplary embodiments. Moreover, certain exemplary embodiments may have some, all, or none of the advantages listed above.

[0045]

[0023] Referring now to the drawings, and in particular to Figures 1 and 2, these figures are exemplary diagrams of data processing environments in which illustrative embodiments may be implemented. Figures 1 and 2 are merely exemplary and are not intended to assert or imply any limitation with regard to the environments in which different embodiments may be implemented. Particular embodiments may make many modifications to the depicted environments based on the following description.

[0046] 1 is a block diagram illustrating a network of data processing systems in which exemplary embodiments may be implemented. Data processing environment 100 is a network of computers in which exemplary embodiments may be implemented. Data processing environment 100 includes network 102. Network 102 is the medium used to provide communications links between various devices and computers connected together within data processing environment 100. Network 102 may include connections such as wire, wireless communication links, or fiber optic cables.

[0047] Client or server are merely exemplary roles for particular data processing systems connected to network 102 and are not intended to exclude other configurations or roles of these data processing systems. Data processing system 104 couples to network 102. Software applications may execute on any data processing system in data processing environment 100. Any software application described in FIG. 1 as executing on processing system 104 may be configured to execute in a similar manner on other data processing systems. Any data or information stored or generated in data processing system 104 in FIG. 1 may be configured to be stored or generated in a similar manner on another data processing system. A data processing system, such as data processing system 104, may contain data and may have software applications or software tools that perform computing operations thereon. In one embodiment, data processing system 104 includes memory 124 that includes application 105A, which may be configured to implement one or more of the functions of the data processor described herein in accordance with one or more embodiments.

[0048] Server 106 couples to network 102 along with storage unit 108. Storage unit 108 includes database 109 configured to store data (e.g., image data and attribute data) as described herein with respect to various embodiments. Server 106 is a conventional data processing system. In one embodiment, server 106 includes application 105B that can be configured to implement one or more of the processor functions described herein in accordance with one or more embodiments.

[0049] Clients 110, 112, and 114 are also coupled to network 102. A conventional data processing system, such as server 106 or client 110, 112, or 114, may contain data and may have software applications or tools that perform conventional computing operations thereon.

[0050] By way of example only, and without implying limitation to such architecture, Figure 1 depicts certain components that may be used in an exemplary implementation of embodiments. For example, server 106 and clients 110, 112, and 114 are depicted as servers and clients by way of example only, and without implying limitation to a client-server architecture. As another example, an embodiment may be distributed across multiple data processing systems and data networks, as shown, while another embodiment may be implemented on a single data processing system within the scope of the exemplary embodiment. Conventional data processing systems 106, 110, 112, and 114 also represent exemplary nodes in clusters, partitions, and other configurations suitable for implementing embodiments.

[0051] Device 132 is an example of a conventional computing device as described herein. For example, device 132 may take the form of a smartphone, a tablet computer, a laptop computer, a stationary or portable client 110, a wearable computing device, or any other suitable device. In one embodiment, device 132 sends a request to server 106 to perform one or more data processing tasks according to neural network application 105B, such as initiating a neural network process as described herein. Any software application described as executing in another conventional data processing system in FIG. 1 may be configured to execute in device 132 in a similar manner. Any data or information stored or generated in another conventional data processing system in FIG. 1 may be configured to be stored or generated in device 132 in a similar manner.

[0052] Server 106, storage unit 108, data processing system 104, and clients 110, 112, and 114, as well as device 132, may be coupled to network 102 using wired connections, wireless communication protocols, or other suitable data connections. Clients 110, 112, and 114 may be, for example, personal computers or network computers.

[0053] In the depicted example, server 106 may provide data such as boot files, operating system images, and applications to clients 110, 112, and 114. Clients 110, 112, and 114 may be clients to server 106 in this example. Clients 110, 112, 114, or some combination thereof, may include their own data, boot files, operating system images, and applications. Data processing environment 100 may include additional servers, clients, and other devices not shown.

[0054] In the depicted example, memory 124 may provide data such as boot files, operating system images, and applications to processor 122. Processor 122 may also include its own data, boot files, operating system images, and applications. Data processing environment 100 may include additional memory, processors, and other devices not shown.

[0055] In the depicted example, data processing environment 100 may be the Internet. Network 102 may represent a collection of networks and gateways that communicate with each other using Transmission Control Protocol / Internet Protocol (TCP / IP) and other protocols. At the heart of the Internet is a backbone of data communication links between major nodes or host computers, including thousands of commercial, government, educational, and other computer systems that route data and messages. Of course, data processing environment 100 also may be implemented as a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). Figure 1 is intended as an example, and not as architectural limitations for different illustrative embodiments.

[0056] Among other uses, data processing environment 100 may be used to implement a client-server environment in which exemplary embodiments may be implemented. A client-server environment allows software applications and data to be distributed across a network, such that applications function using interactions between traditional client and server data processing systems. Data processing environment 100 may also employ a service-oriented architecture, in which interoperable software components distributed across a network may be packaged as coherent business applications. Data processing environment 100 may also take the form of a cloud, employing a cloud computing model of service delivery to enable convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider.

[0057] 2, a block diagram of a data processing system in which exemplary embodiments may be implemented is shown. Data processing system 200 is an example of a conventional computer, such as data processing system 104, server 106, or clients 110, 112, and 114 of FIG. 1, or another type of device in which computer-usable program code or instructions implementing processes may be located for exemplary embodiments.

[0058] Additionally, data processing system 200 is representative of a conventional data processing system or configuration in which computer-usable program code or instructions that implement the processes of the illustrative embodiments may be located, such as conventional data processing system 132 in FIG. 1. Data processing system 200 is described as a computer only, by way of example and not limitation. Implementations in the form of other devices, such as device 132 in FIG. 1, may modify data processing system 200, such as adding a touch interface, or even eliminate certain depicted components from data processing system 200, without departing from the general description of the operation and functionality of data processing system 200 described herein.

[0059] In the depicted example, data processing system 200 employs a hub architecture including a northbridge and memory controller hub (NB / MCH) 202 and a southbridge and input / output (I / O) controller hub (SB / ICH) 204. A processing unit 206, a main memory 208, and a graphics processor 210 are coupled to northbridge and memory controller hub (NB / MCH) 202. Processing unit 206 may include one or more processors and may be implemented using one or more heterogeneous processor systems. Processing unit 206 may be a multi-core processor. Graphics processor 210 may be coupled to NB / MCH 202 via an accelerated graphics port (AGP) in certain implementations.

[0060] In the depicted example, a local area network (LAN) adapter 212 is coupled to a southbridge and I / O controller hub (SB / ICH) 204. An audio adapter 216, a keyboard and mouse adapter 220, a modem 222, a read-only memory (ROM) 224, a universal serial bus (USB) and other ports 232, and PCI / PCIe devices 234 are coupled to the southbridge and I / O controller hub 204 via a bus 238. A hard disk drive (HDD) or solid-state drive (SSD) 226 and a CD-ROM 230 are coupled to the southbridge and I / O controller hub 204 through a bus 240. The PCI / PCIe devices 234 may include, for example, an Ethernet adapter, an add-in card, and a PC card for a notebook computer. PCI uses a card bus controller, while PCIe does not. The ROM 224 may be, for example, a flash binary input / output system (BIOS). Hard disk drive 226 and CD-ROM 230 may use, for example, integrated drive electronics (IDE), serial ATA (SATA) interfaces, or variants such as external SATA (eSATA) and micro SATA (mSATA). Super I / O (SIO) device 236 may be coupled to southbridge and I / O controller hub (SB / ICH) 204 via bus 238.

[0061] Memories such as main memory 208, ROM 224, or flash memory (not shown) are some examples of computer-usable storage devices. Hard disk drives or solid state drives 226, CD-ROM 230, and other similarly usable devices are some examples of computer-usable storage devices that include computer-usable storage media.

[0062] An operating system runs on processing unit 206. The operating system coordinates and provides control of various components within data processing system 200 in FIG. 2. The operating system may be a commercially available operating system for any type of computing platform, including, but not limited to, server systems, personal computers, and mobile devices. An object-oriented or other type of programming system may operate in conjunction with the operating system and may provide calls to the operating system from programs or applications running on data processing system 200.

[0063] 1, instructions for the operating system, the object-oriented programming system, and applications or programs, such as application 105 in FIG. 1, may be located on a storage device, such as in the form of code 226A on hard disk drive 226, and loaded into at least one of one or more memories, such as main memory 208, for execution by processing unit 206. The processes of the exemplary embodiments may be performed by processing unit 206 using computer-implemented instructions, which may be located in a memory, such as main memory 208, read-only memory 224, or in one or more peripheral devices.

[0064] Additionally, in some cases, code 226A may be downloaded over network 201A from remote system 201B, where similar code 201C is stored in storage device 201D. In other cases, code 226A may be downloaded over network 201A to remote system 201B, with the downloaded code 201C being stored in storage device 201D.

[0065] The hardware in Figures 1-2 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives, may be used in addition to or in place of the hardware depicted in Figures 1-2. Furthermore, the processing of the illustrated embodiments may be applied to multi-processor data processing systems.

[0066] In some illustrative examples, data processing system 200 may be a personal digital assistant (PDA) that is typically configured with flash memory to provide non-volatile memory for storing operating system files and / or user-generated data. The bus system may be comprised of one or more buses, such as a system bus, an I / O bus, a PCI bus, etc. Of course, the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture.

[0067] The communications unit may include one or more devices used to send and receive data, such as a modem or a network adapter. The memory may be, for example, main memory 208 or a cache such as that found in northbridge and memory controller hub 202. The processing unit may include one or more processors or CPUs.

[0068] 1-2 and above-described examples are not meant to imply architectural limitations. For example, data processing system 200 may also be a tablet computer, a laptop computer, or a telephone device, in addition to taking the form of a mobile or wearable device.

[0069] When a computer or data processing system is described as a virtual machine, virtual device, or virtual component, the virtual machine, virtual device, or virtual component operates in the manner of data processing system 200 using virtualization manifests of some or all of the components depicted in data processing system 200. For example, in a virtual machine, virtual device, or virtual component, processing unit 206 is manifested as a virtualized instance of all or some number of hardware processing units 206 available in the host data processing system, main memory 208 is manifested as a virtualized instance of all or a portion of main memory 208 available in the host data processing system, and disk 226 is manifested as a virtualized instance of all or a portion of disk 226 available in the host data processing system. The host data processing system in such a case is represented by data processing system 200.

[0070] Referring to Figure 3, this figure shows a block diagram of an exemplary computing system 300 in accordance with an example embodiment. This figure illustrates one embodiment of computing system 300 including a virtual machine 314, such as a JVM. In some embodiments, virtual machine 314 performs processing according to the flowcharts shown in Figure 9 or Figure 10. In some embodiments, virtual machine 314 is an example of application 105A / 105B of Figure 1.

[0071] In some embodiments, computing system 300 also includes compiler 304 and operating system 312. Operating system 312 runs on computer hardware and provides an operating environment for applications executed by virtual machine 314. Virtual machine 314 includes class loader subsystem 316, interpreter 318, JIT compiler 320, and memory 322. Embodiments of memory 322 may include any form of electronic or computer-usable storage. In some embodiments, the functionality described herein is distributed among multiple systems, which may include a combination of software-based or hardware-based systems, or both, such as application-specific integrated circuits (ASICs), computer programs, or smartphone applications.

[0072] In some embodiments, computing system 300 includes source code 302, which includes code written in a particular programming language, such as Java, C, C++, C#, Ruby, or Perl. As such, source code 302 adheres to a particular set of syntactic and / or semantic rules for the associated language. For example, code written in Java conforms to the Java Language Specification. However, because specifications are updated and revised over time, source code 302 may be associated with a version number that indicates the revision of the specification to which source code 302 conforms.

[0073] In some embodiments, compiler 304 converts source code 302, for example in the form of bytecode, into class files 306 that represent the program to be executed. For example, in some embodiments, source code 302 includes one or more files that are input to compiler 304. Compiler 304 processes the one or more files and outputs the resulting bytecode as one or more class files 306.

[0074] In some embodiments, the class files 306 are then loaded and executed by an execution engine 308, which includes a runtime environment 310 and an operating system 312. The runtime environment 310 includes a virtual machine 314 that receives the class files 306 and inputs the bytecode of the class files 306 to an interpreter 318 or a JIT compiler 320. The interpreter 318 and the JIT compiler 320 generate machine code, which the virtual machine 314 outputs to the operating system 312 for program execution. In some embodiments, the virtual machine 314 processes the bytecode of the program as the program is executed. As a result, the processing time of the virtual machine 314 affects the runtime performance of the program. In some embodiments, the JIT compiler 320 uses the optimization techniques described herein to reduce the processing time of the virtual machine 314, thereby improving the runtime performance of the program.

[0075] In some embodiments, the virtual machine 314 executes a program using a combination of interpretation and compilation techniques, using an interpreter 318 and a JIT compiler 320. In some such embodiments, the virtual machine 314 initially begins by interpreting the bytecode representing the program using the interpreter 318 while collecting profile data related to the program's operation. For example, some embodiments collect profile data representative of the frequency with which different sections or blocks of code are executed by the virtual machine 314. In some embodiments, as an interpreted method call is executed, the virtual machine 314 increments a "call counter," which is metadata stored in a profile structure associated with the called method. When the call counter exceeds a compilation threshold, the virtual machine 314 spawns a compilation thread (or uses an existing compilation thread) to compile / optimize the method. In an alternative embodiment, the virtual machine 314 tracks the number of times a loop iterates within a method using a "back edge counter" and triggers compilation when the back edge counter reaches the compilation threshold.

[0076] In some embodiments, when a block of code exceeds a specified threshold (is "hot"), the virtual machine 314 invokes the JIT compiler 320 to use optimization techniques to reduce the amount of processing time the virtual machine 314 uses to process the block of code into machine-level instructions. However, some such embodiments include non-optimized periods of program execution during which the virtual machine 314 processes the block of code up to JIT compilation (e.g., by running the code in interpreter mode) before identifying the block as a hot block of code.

[0077] In some embodiments, virtual machine 314 implements the techniques described herein to perform compiler optimizations during program execution, including during periods of program execution when little or no profile data is available for one or more code segments or blocks of code. Such periods of program execution are not limited to the early or initial periods of program execution, but can occur throughout the program's execution. For example, programs based on Java technology can be modified on the fly at any point during program execution due to their powerful ability to perform dynamic loading of classes. This dynamic loading of classes invalidates compiler optimizations and profile data collected by virtual machine 314 prior to the class modification. When compiler optimizations and profile data are invalidated by dynamic loading, this creates periods of program execution that can occur at any point during program execution, during which little or no profile data is available for code segments associated with dynamically loaded classes. In some embodiments, virtual machine 314 uses the techniques described herein to enable compiler optimizations of code segments during any such periods of program execution. Such embodiments have the potential to improve program performance throughout the program's execution compared to embodiments that lack optimizations during such periods.

[0078] While the illustrated embodiment shows memory 322 as part of virtual machine 314, alternative embodiments locate memory 322 elsewhere outside of virtual machine 314, but in communication with virtual machine 314. Embodiments of memory 322 include memory on a single electronic or computer-usable storage device, or memory distributed among any number of electronic or computer-usable storage devices.

[0079] 4, which is a block diagram of an exemplary layout of virtual machine memory 400 according to an exemplary embodiment. Components of virtual machine memory 400 may be illustrated or referenced as memory regions, blocks, etc., although there is no requirement that the memory regions be contiguous. In some embodiments, virtual machine memory 400 is an example of memory 322 of FIG. 3.

[0080] In the illustrated embodiment, virtual machine memory 400 includes a heap 402, a class data area 404, a thread data area 412, and a method area 418. In one embodiment, heap 402 represents a runtime data area where memory for class instances and arrays is allocated. In one embodiment, class data area 404 represents a memory area where data pertaining to each individual class is stored. In one embodiment, class data area 404 includes, for each loaded class, a runtime constant pool 406 representing data from each class's constant table, method code 408 representing virtual machine instructions for the class's methods, and field and method data 410 representing data such as static field data for each class. Method area 418 includes class data, including a runtime constant pool 420 shared by all threads executing in the virtual machine.

[0081] In the illustrated embodiment, thread data area 412 represents a memory area where structures specific to each individual thread are stored. Thread area 412 includes a thread stack 414 and a program counter 416 for each thread executing on a virtual machine (e.g., virtual machine 314 of FIG. 3). In one embodiment, program counter 416 stores the current address of the virtual machine instruction being executed for the respective thread. Thus, as a thread steps through instructions, the program counter is updated to maintain an index to the current instruction. In one embodiment, thread stack 414 stores a frame for each thread that holds local variables and partial results, and is also used for method invocations.

[0082] 5, a block diagram of an exemplary virtual machine 500 is shown, in accordance with an exemplary embodiment. In some embodiments, the virtual machine 500 is an example of the virtual machine 314 of FIG.

[0083] In the illustrated embodiment, virtual machine 500 includes a JIT compiler 502 and an interpreter 504. While the illustrated embodiment depicts JIT compiler 502 and interpreter 504 as separate components, in alternative embodiments, JIT compiler 502 and interpreter 504 may be integrated into a single component. In some embodiments, virtual machine 500 includes a decision mechanism 506 that controls whether bytecode is compiled by JIT compiler 502 or interpreted by interpreter 504. In some embodiments, decision mechanism 506 selects JIT compiler 502 based on the availability of profile data 524 for the called segment. However, embodiments disclosed herein enable deriving profile information for code segments that lack profile data. Such embodiments enable the decision mechanism to select JIT compiler 502 even in situations where profile data 524 is not available or is insufficient for a given called code segment. For example, in some embodiments, the decision mechanism 506 selects the JIT compiler 502 based on the type of code in the called code segment, regardless of the availability of the profile data memory 524 .

[0084] In the illustrated embodiment, virtual machine 500 includes a class loader subsystem 514 that provides a mechanism for loading types, which are classes and interfaces, and making them accessible to JIT compiler 502 and interpreter 504. In the illustrated embodiment, virtual machine 500 also includes a frequency data component 520 and a type data component 522, which are examples of profiling instrumentation that obtain information for constructing profile data in profile data memory 524. Type data component 522 collects type information for each variable in the program and records the type information in profile data memory 524. Frequency data component 520 collects frequency information indicating how many times each function was executed and records it in profile data memory 524.

[0085] In some embodiments, the JIT compiler 502 performs a second level compilation to create code (e.g., JIT code) that is output as optimized code, updates the data heap 518, and is executed by the execution component 516 that runs the application on the operating system 526. In some embodiments, the JIT compiler 502 optimizes code segments using profile data from the profile data memory 524. In some embodiments, if there is no profile data for a given code segment, the JIT compiler 502 will instead attempt to optimize the code segment using alternative data, such as class hierarchy data 512 or data from the application heap 510 at the time the application snapshot 508 was taken (e.g., the snapshot saved the state of the application).

[0086] In some embodiments, there are fail-safe paths coupling the execution component 516 to each of the JIT compiler 502 and the interpreter 504. These fail-safe paths transfer control from the execution component 516 to the interpreter 504 when certain assumptions in the optimized code (e.g., the optimized JIT code) become invalid during runtime and execution must fall back to an interpreter that does not make those assumptions.

[0087] Referring to Figure 6, this figure shows a block diagram of an example JIT compiler 600 in accordance with an example embodiment. Although the example embodiment shows JIT compiler 600, alternative embodiments include other types of optimizing compilers. In some embodiments, JIT compiler 600 is an example of JIT compiler 502 of Figure 5.

[0088] In some embodiments, the JIT compiler 600 includes a detector 602 that receives a code segment 612, e.g., in bytecode, and detects or derives information about the code segment, such as the type of instruction the bytecode represents. For example, the bytecode may include a call to a method that is potentially polymorphic, such as a call to a virtual method, or other types of code that may be optimized by the JIT compiler 600. In the illustrated embodiment, the detector 602 sends information about the code segment 612 detected by the detector 602 to a profile request module 604. The profile request module 604 receives the information about the code segment 612, which triggers the profile request module 604 to request profile data for the code segment 612. For example, in some embodiments, the profile request module 604 requests profile information by sending a request for profile information associated with a particular method and bytecode offset associated with the code segment 612. In some embodiments, the functionality described herein is distributed among multiple systems, which may include a combination of software-based or hardware-based systems, such as, for example, an application-specific integrated circuit (ASIC), a computer program, or a smartphone application.

[0089] In some embodiments, the JIT compiler 600 includes a determination module 606 that determines whether the profile request module 604 received any profile information in response to the request. If so, the profile data is provided to the optimizing compiler 608. If not, the profile derivation unit 610 is triggered by the absence of profile data to generate data that can be used for optimization as a substitute for the absence of profile data. For example, in some embodiments, the profile derivation unit 610 receives information detected by the detector 602 about the code segment 612 and associated state information 614 as a basis for generating substitute profile data. In some embodiments, the profile derivation unit 610 receives the information detected by the detector 602 directly from the detector 602, while in alternative embodiments, the profile derivation unit 610 receives the information detected by the detector 602 forwarded from the profile request module 604. The profile substitute data is then provided to the optimizing compiler 608. The optimizing compiler 608 receives either the profile data or the profile alternative data and uses either to create optimized executable code, which the optimizing compiler 608 outputs to an execution component (e.g., execution component 516 of FIG. 5 ) for execution on an operating system (e.g., operating system 526 of FIG. 5 ).

[0090] 7, a block diagram of an exemplary profile derivation unit 700 is depicted, in accordance with an example embodiment. In some embodiments, the profile derivation unit 700 is an example of the profile derivation unit 610 of FIG.

[0091] In the illustrated embodiment, profile derivation unit 700 receives code segment information 706 associated with the code segment being compiled. For example, in one embodiment, code segment information 706 is an example of information detected by detector 602 that profile derivation unit 610 receives from detector 602 for code segment 612 in FIG. 6 .

[0092] In the illustrated embodiment, the profile derivation unit 700 uses state information 708 to optimize code segments in the absence of profile information for the code segments. For example, in some such embodiments, the compiler uses class hierarchy data (e.g., class hierarchy data 512 of FIG. 5) to optimize code segments.

[0093] In the illustrated embodiment, the profile derivation unit 700 includes a query builder 702, a query engine 704, and a results processor 710. In some embodiments, the functionality described herein is distributed among multiple systems, which may include software-based or hardware-based systems or a combination of both, such as, for example, application specific integrated circuits (ASICs), computer programs, or smartphone applications.

[0094] In some embodiments, the query builder 702 evaluates the code segment information 706 to generate criteria for searching state information 708. For example, in some embodiments, the query builder 702 generates one or more criteria for searching data representative of the current state of the class hierarchy table. The query engine 704 receives the one or more criteria from the query builder 702 and initiates a search of one or more data sources. The results processor 710 receives the results of the one or more queries initiated by the query engine 704 and filters the results for data that can be used for optimization processing. The results processor 710 provides the filtered results as optimization data 714 to an optimization compiler, such as optimization compiler 608 of FIG. 6. In some embodiments, the results processor 710 generates optimization data 714 that is in the same format as the profile data output by the profile request module 604 in FIG. 6.

[0095] As an example, in one embodiment, query builder 702 identifies that code segment information 706 includes a call to a potentially polymorphic method, such as a call to a virtual method, and therefore generates a query of state information 708 to determine whether a particular derived class is normally loaded so that the code segment can be optimized accordingly. In some such embodiments, query builder 702 generates any derived classes that have already been loaded as criteria for the query. In alternative embodiments, query builder 702 also generates any derived classes that have already been instantiated as another criterion for the query. In some embodiments, query engine 704 receives one or more criteria from query builder 702 (search for loaded derived classes) and initiates a search of state information 708, such as class hierarchy data. Result processor 710 receives results of one or more queries initiated by query engine 704, which in this example may include a list of loaded classes, or alternatively, may include a list of instantiated classes. The results processor 710 filters these results for data that can be used in optimization processing, for example, by determining that there are certain derived classes that are always or most frequently called from among the loaded and / or instantiated classes. The results processor 710 provides the filtered results as optimization data 714 to an optimizing compiler, such as optimizing compiler 608 of Figure 6, which in this example can inline commonly called derived classes and inject "guard code" that includes type tests to ensure that objects are of the derived class. In some embodiments, the results processor 710 generates optimization data 714 that is in the same format as the profile data output by profile request module 604 of Figure 6.

[0096] In some such embodiments, instantiations of derived classes are tracked by profiling instrumentation 722, such as frequency data component 520 of FIG. 5, at the time of object instantiation. In an alternative embodiment, instantiations of derived classes are tracked by processing application heap 718 at the time snapshot 716 is being taken. In another alternative embodiment, instantiations of derived classes are tracked by combining data about which classes were instantiated by which methods (e.g., as tracked in interpreter 724) with data constructed from call graph 726 or other class hierarchy data 720 to capture control flow from snapshot 716. In such an embodiment, the compiler combines dynamic execution state (e.g., data about which classes were instantiated by which methods) with static analysis (e.g., data from snapshot points, such as data from call graph 726) to generate a substitute for the lack of profiling information at some code locations. Having call graph 726 reveals the methods that an instance of a given class can reach by essentially performing reachability analysis on the instantiated classes starting at the code location where the classes were instantiated. This context-sensitive approach to using the program state at a snapshot point advantageously eliminates instantiated classes that cannot reach a particular program point based on reachability analysis.

[0097] 8, which is a block diagram of an alternative profile derivation unit 800 according to an example embodiment. In some embodiments, the profile derivation unit 800 is an example of the profile derivation unit 610 of FIG.

[0098] In the illustrated embodiment, profile derivation unit 800 receives code segment information 820 associated with the code segment being compiled. For example, in one embodiment, code segment information 820 is an example of information detected by detector 602 that profile derivation unit 610 receives from detector 602 for code segment 612 in FIG. 6 .

[0099] In the illustrated embodiment, the profile derivation unit 800 uses the state information 822 to optimize code segments in the absence of profile information for the code segments. For example, in some such embodiments, the compiler uses class hierarchy data (e.g., class hierarchy data 512 of FIG. 5) to optimize code segments.

[0100] In the illustrated embodiment, the profile derivation unit 800 includes a query builder 802, a query engine 804, a query result processor 806, a trace generator 808, a trace analyzer 810, a context matching module 812, a context result processor 814, and a memory 818. In some embodiments, the functionality described herein is distributed among multiple systems, which may include a combination of software-based or hardware-based systems, such as, for example, an application specific integrated circuit (ASIC), a computer program, or a smartphone application.

[0101] In some embodiments, the query builder 802 evaluates the code segment information 820 to generate criteria for searching the state information 822. For example, in some embodiments, the query builder 802 generates one or more criteria for searching data representative of the current state of the class hierarchy table. The query engine 804 receives the one or more criteria from the query builder 802 and initiates a search of the state information 822, one or more other data sources, or both. The query result processor 806 receives results of one or more queries initiated by the query engine 804 and stores the resulting code segments in the memory 818 as candidate code segments 836. The query result processor 806 also provides the state information 822 to the trace generator 808.

[0102] The trace generator 808 obtains statement traces including contextual code segments from application code preceding and following the invoked code segment. The trace generator 808 then stores the statement traces as trace data 838 in memory 818. In some embodiments, the trace generator 808 then obtains respective resultant contextual traces for each of the candidate code segments 836 from the query results, where the resultant contextual traces include resultant contextual code segments from application code preceding and following the resultant code segment. In some embodiments, the trace analyzer 810 reduces the contextual code segments to invoked pattern traces. In some embodiments, the trace analyzer 810 then generates a suffix tree data structure from the candidate code segments 836 and their respective pattern traces. The trace analyzer 810 then stores the suffix tree data structure in memory 818 as suffix tree data 840. The context matching module 812 maps the invoked pattern traces to the suffix tree to identify the closest matching results and resultant contextual code segments with correlation profile data. The context matching module 812 provides the closest matching result and the result context code segment to a context result processor 814. The context result processor 814 generates an extrapolated profile data set based on data from the closest matching result found by the context matching module 812. The context result processor 814 provides the extrapolated profile data set to an optimizing compiler, such as optimizing compiler 608 of FIG. 6, which in this example can inline commonly invoked derived classes and inject “guard code” that includes type tests to ensure that objects are of the derived class. In some embodiments, the context result processor 814 generates optimized data 842, which is in the same format as the profile data output by profile request module 604 in FIG. 6.

[0103] In some such embodiments, instantiations of derived classes are tracked by profiling instrumentation 830, such as frequency data component 520 of FIG. 5, at the time of object instantiation. In an alternative embodiment, instantiations of derived classes are tracked by processing application heap 826 at the time snapshot 824 is taken. In another alternative embodiment, instantiations of derived classes are tracked by combining data about which classes were instantiated by which methods (e.g., as tracked in interpreter 832) with data constructed from call graph 834 or other class hierarchy data 828 to capture control flow from snapshot 824. In such an embodiment, the compiler combines dynamic execution state (e.g., data about which classes were instantiated by which methods) with static analysis (e.g., data from the snapshot point, such as data from call graph 834) to generate a substitute for the lack of profiling information at some code locations. Having call graph 834 and essentially performing reachability analysis on the instantiated classes starting at the code location where the classes were instantiated can reveal the methods that an instance of a given class can reach. This context-sensitive approach to using the program state at the snapshot point advantageously eliminates instantiated classes that are not reachable to a particular program point based on reachability analysis.

[0104] 9, a flowchart of an exemplary process 900 for generating profile data in accordance with an exemplary embodiment is shown. In a particular embodiment, a compiler, such as JIT compiler 502, performs process 900.

[0105] In one embodiment, at block 902, a compiler receives a called code segment that triggers compilation. Then, at block 904, the compiler requests profile data for the called code segment. Then, at block 906, the compiler receives a response indicating that profile data is not available for the called code segment. Then, at block 908, the compiler performs a query process to retrieve profiled code segments based on specified criteria related to attributes of the called code segment. Then, at block 910, the compiler receives search results from the query process including the result code segment. Then, at block 912, the compiler generates an extrapolated profile data set based on the correlated profile data. Then, at block 914, the compiler stores the extrapolated profile data set in memory such that the extrapolated profile data set is associated with the called code segment in memory. Then, at block 916, the compiler performs an optimization process on the called code segment based on the extrapolated profile data set.

[0106] 10, which illustrates a flowchart of an exemplary process 1000 for generating profile data in accordance with an exemplary embodiment. In a particular embodiment, a compiler, such as JIT compiler 502, performs process 1000.

[0107] In one embodiment, at block 1002, the compiler receives a called code segment that triggers compilation. Next, at block 1004, the compiler requests profile data for the called code segment. Next, at block 1006, the compiler receives a response indicating that profile data is not available for the called code segment. Next, at block 1008, the compiler obtains a statement trace including context code segments from application code preceding and following the called code segment. Next, at block 1010, the compiler reduces the context code segments to called pattern traces. Next, at block 1012, the compiler performs a query operation to search for profiled code segments based on specified criteria related to attributes of the called code segment. Next, at block 1014, the compiler receives search results from the query operation including result code segments. Next, at block 1016, the compiler obtains result context code segments from application code preceding and following the result code segment. Next, at block 1018, the compiler generates a suffix tree data structure from the candidate code segment 836 and the result context code segments preceding and following the result code segment. Next, at block 1020, the compiler maps the called pattern trace to the suffix tree to identify the closest matching result code segment and result context code segment with correlated profile data. Next, at block 1022, the compiler generates an extrapolated profile data set based on the correlated profile data. Next, at block 1024, the compiler stores the extrapolated profile data set in memory such that the extrapolated profile data set is associated with the called code segment in memory. Next, at block 1026, the compiler performs optimization operations on the called code segment based on the extrapolated profile data set.

[0108] The following definitions and abbreviations shall be used for interpreting the claims and the specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," or "containing," or any variation thereof, are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or device consisting of a list of elements is not necessarily limited to only those elements, but can include other elements not expressly listed or inherent in such composition, mixture, process, method, article, or device.

[0109] Also, the term "illustrative" is used herein to mean content "serving as an example, instance, or illustration." Furthermore, any aspect or design described herein as "illustrative" is not necessarily to be construed as preferred or advantageous over other aspects or designs. The terms "at least one" and "one or more" are understood to include any integer number of one or more (i.e., 1, 2, 3, 4, etc.). The term "plurality" is understood to include any integer number of two or more (i.e., 2, 3, 4, 5, etc.). The term "connection" can include indirect and direct connection.

[0110] References herein to "one embodiment," "an embodiment," "an example embodiment," etc., are intended to indicate that the described embodiment may include a particular feature, structure, or characteristic, but that all embodiments may or may not include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one of ordinary skill in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly stated.

[0111] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with measurement of a particular quantity based on equipment available at the time of filing. For example, "about" can include a range of ±8%, or 5%, or 2% of a given value.

[0112] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments described herein.

[0113] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments described herein.

[0114] Thus, computer-implemented methods, systems or apparatus, and computer program products for managing participation in online communities and other related features, functions, or operations are provided in exemplary embodiments. Where an embodiment, or portions thereof, are described in terms of a type of apparatus, the computer-implemented method, system or apparatus, computer program product, or portions thereof, is adapted or configured for use with appropriate and equivalent representations of that type of apparatus.

[0115] While an embodiment is described as being implemented in an application, delivery of the application in a software-as-a-service (SaaS) model is contemplated within the scope of exemplary embodiments. In the SaaS model, the functionality of an application implementing an embodiment is provided to users by running the application in a cloud infrastructure. Users can access the application using a variety of client devices through a thin-client interface, such as a web browser (e.g., web-based email) or other lightweight client application. Users do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage of the cloud infrastructure. In some cases, users may not manage or control the functionality of the SaaS application. In some other cases, a SaaS implementation of an application may allow for possible exceptions to limited user-specific application configuration settings.

[0116] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0117] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, by way of example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, mechanically encoded devices having instructions recorded on punch cards or ridge-in-groove structures, or the like, and suitable combinations thereof. Computer-readable storage devices, as used herein, should not be construed as ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0118] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). The network may be comprised of copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0119] Computer-readable program instructions for carrying out operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages such as Smalltalk, C++, etc., and procedural programming languages such as the "C" programming language and similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, as a standalone software package, or partially on the user's computer. Alternatively, the computer may be executed partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the computer-readable program instructions in order to carry out aspects of the present invention.

[0120] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0121] These computer-readable program instructions can be provided to a general-purpose computer, a processor of a special-purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable storage media can also be stored in computer-readable storage media connectable to a computer, programmable data processing apparatus, or other device, or combination thereof, that functions in a particular way, such that the computer-readable program instructions stored therein configure one of the products containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0122] Computer-readable program instructions, such as instructions to perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams on a computer, other programmable apparatus, or other device, can also be loaded into a computer, other programmable apparatus, or other device to perform a series of operational steps on the computer, other programmable apparatus, or other device to generate a computer-implemented process.

[0123] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of executable aspects of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which constitute one or more executable instructions for implementing the specified logical function(s). In some alternative embodiments, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0124] Embodiments of the present invention may also be provided as part of a service agreement with a client company, a non-profit organization, a government agency, an internal organizational structure, or the like. Aspects of these embodiments may include configuring a computer system to perform some or all of the methods described herein, and deploying software, hardware, and web services that implement some or all of the methods described herein. Aspects of these embodiments may also include analyzing a client's operations, making recommendations responsive to the analysis, building a system that implements some of the recommendations, integrating the system into existing processes and infrastructure, metering system usage, allocating costs to users of the system, and charging for system usage. Although embodiments of the present invention have been described above, each describing its individual advantages, the present invention is not limited to any particular combination thereof. Rather, such embodiments may be combined in any manner and number, depending on the intended deployment of the present invention, without losing their beneficial effects.

Claims

1. requesting, by a compiler responsive to execution of a first code segment, a first profile data set associated with the first code segment; In response to receiving an indication that the first profile data set is unavailable, performing a query process to search for other code segments based on specified criteria related to attributes of the first code segment; receiving search results from the query processing, the search results including a second code segment; generating an extrapolated profile data set based at least in part on the second code segment; storing the extrapolated profile data set in memory such that the extrapolated profile data set is associated with the first code segment in the memory; performing an optimization operation on the first code segment by the compiler based at least in part on the extrapolated profile data set; 11. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the query process retrieves aggregated program state information.

3. The computer-implemented method of claim 2 , wherein the program state information includes a class hierarchy table.

4. The computer-implemented method of claim 1 , wherein the specified criteria include syntactic criteria based at least in part on the syntax of the first code segment.

5. The computer-implemented method of claim 4 , wherein the specified criteria includes a syntactic match of the first code segment.

6. The computer-implemented method of claim 4 , wherein the specified criteria includes rules that describe semantic matching of the first code segment.

7. The query processing includes: identifying a candidate code segment based on a semantic match between the candidate code segment and the first code segment; obtaining context code segments from application code preceding and following the first code segment; obtaining result context code segments from application code preceding and following the candidate code segment; identifying the candidate code segment as the second code segment based on fuzzy matching between the result context code segment and the context code segment; The computer-implemented method of claim 1 , comprising:

8. 8. The computer-implemented method of claim 7, wherein the query processing includes generating a data structure of candidate code segments, the arrangement of the data structure being based at least in part on respective degrees of similarity between the first code segment and each of the candidate code segments.

9. The computer-implemented method of claim 1 , wherein the query processing includes limiting the search results to code segments having an associated profile data set.

10. 10. The computer-implemented method of claim 9, wherein the generating the extrapolated profile data set comprises generating the extrapolated profile data set for the first code segment based at least in part on a second profile data set for the second code segment.

11. 1. A computer program product for deriving profile data, the computer program product including one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions executable by a processor to cause the processor to perform operations, the operations including: requesting, by a compiler responsive to execution of a first code segment, a first profile data set associated with the first code segment; In response to receiving an indication that the first profile data set is unavailable, performing a query process to search for other code segments based on specified criteria related to attributes of the first code segment; receiving search results from the query processing, the search results including a second code segment; generating an extrapolated profile data set based at least in part on the second code segment; storing the extrapolated profile data set in memory such that the extrapolated profile data set is associated with the first code segment in the memory; performing an optimization operation on the first code segment by the compiler based at least in part on the extrapolated profile data set; a computer program product,

12. 12. The computer program product of claim 11, wherein the stored program instructions are stored in a computer-readable storage device in a data processing system, and wherein the stored program instructions are transferred over a network from a remote data processing system.

13. the stored program instructions are stored in a computer readable storage device at a server data processing system, and the stored program instructions are downloaded over a network to a remote data processing system for use in a computer readable storage device associated with the remote data processing system; program instructions for metering usage of said program instructions associated with said request; program instructions for generating a bill based on said metered usage; 12. The computer program product of claim 11, further comprising:

14. 12. The computer program product of claim 11, wherein the query process retrieves aggregated program state information, the program state information including a class hierarchy table.

15. 12. The computer program product of claim 11, wherein the specified criteria include syntactic criteria based at least in part on a syntax of the first code segment, the specified criteria including a syntactic match of the first code segment.

16. The query processing includes: identifying a candidate code segment based on a semantic match between the candidate code segment and the first code segment; obtaining context code segments from application code preceding and following the first code segment; obtaining result context code segments from application code preceding and following the candidate code segment; identifying the candidate code segment as the second code segment based on fuzzy matching between the result context code segment and the context code segment; 12. The computer program product of claim 11, comprising:

17. a processor; one or more computer-readable storage media; and program instructions collectively stored on the one or more computer-readable storage media, the program instructions executable by the processor to cause the processor to perform operations, the operations including: requesting, by a compiler responsive to execution of a first code segment, a first profile data set associated with the first code segment; In response to receiving an indication that the first profile data set is unavailable, performing a query process to search for other code segments based on specified criteria related to attributes of the first code segment; receiving search results from the query processing, the search results including a second code segment; generating an extrapolated profile data set based at least in part on the second code segment; storing the extrapolated profile data set in memory such that the extrapolated profile data set is associated with the first code segment in the memory; performing an optimization operation on the first code segment by the compiler based at least in part on the extrapolated profile data set; 2. A computer system comprising:

18. 20. The computer system of claim 17, wherein the query process retrieves aggregated program state information, the program state information including a class hierarchy table.

19. 20. The computer system of claim 17, wherein the specified criteria include syntactic criteria based at least in part on a syntax of the first code segment, the specified criteria including a syntactic match of the first code segment.

20. The query processing includes: identifying a candidate code segment based on a semantic match between the candidate code segment and the first code segment; obtaining context code segments from application code preceding and following the first code segment; obtaining result context code segments from application code preceding and following the candidate code segment; identifying the candidate code segment as the second code segment based on fuzzy matching between the result context code segment and the context code segment; 20. The computer system of claim 17, comprising:

Images