Compilation Strategies for Shareable Application Snapshots

Abstract

A method list is constructed for the currently executing application in the process virtual machine at a snapshot point, the method list including a set of methods that can be executed by the currently executing application after the snapshot point, and the snapshot point including the execution state of the currently executing application when the snapshot process was triggered. Profiling data of the currently executing application collected before the snapshot point is reached is committed to a specified storage location. One method in the method list is compiled using the profiling data and a just-in-time compiler of the process virtual machine. The snapshot data includes data of the execution state of the currently executing application at the snapshot point, and the snapshot data includes the results of the compilation.

Description

[Technical field]

[0001] The present invention relates generally to methods, systems, and computer program products for application compilation, and more particularly, to methods, systems, and computer program products for compilation strategies for shareable application snapshots. [Background technology]

[0002] A process virtual machine (VM), also known as a language runtime, managed language runtime, application virtual machine or managed runtime environment, runs as an application on a host operating system. A process VM provides a platform-independent environment that hides the details of the underlying hardware and operating system from the applications running within it, allowing applications to run unmodified on different platform configurations.

[0003] For application execution in a process VM environment, several options are available. First, the application's source code (in a high-level language, e.g., Java) can be compiled into an executable file (also called a native executable, native image, or native machine code) of processor-specific instructions (Java is a registered trademark of Oracle America, Inc. in the United States and other countries). At run-time, the environment loads the executable file into memory and executes the instructions. Although executable files do not require additional processing at run-time, their static nature means that program code must be separated from data, and other dynamic language features require run-time support, resulting in a performance penalty. Static executable files also contain seldom-executed code that occupies additional memory space, since they contain code to handle unexpected events.

[0004] Another option for running an application is to compile the application's source code into an intermediate representation known as a bytecode, which resembles machine code for a particular processor or family of processors, but is not processor-specific. To then execute the application's bytecode, the process VM uses an interpreter that converts one or a few bytecode instructions at a time into corresponding processor-specific instructions, which are then executed by the particular processor. Because the interpreter process adds execution time, interpreted code does not perform as well as a static executable, but it is more adaptable to changing conditions and avoids unnecessary code processing.

[0005] A third option is the just-in-time (JIT) compiler, which converts parts of the bytecode into processor-specific instructions (also called machine code) while the application is running and saves the compilation results for reuse. Compilation can be done on a per-file, per-method, or other unit of code. A method, also called a procedure, subroutine, or function, is a block of code that is executed only when the method is called. Because the compilation process itself takes time, most process VMs improve overall application performance by only compiling the code that is about to be used (hence the term just-in-time compilation), by only compiling the most frequently used code (and interpreting the rest of the code), or by a combination of these techniques. Some process VMs collect profiling information while the application is running and use the profiling information to further decide both to compile parts of the code and to improve the resulting compiled code.

[0006] Two currently known examples of process VMs are the Common Language Runtime (CLR) and the Java Virtual Machine (JVM). The CLR, the virtual machine component of the Microsoft .NET framework, manages the execution of .NET programs, which can be written in several different source code languages. (.NET is a registered trademark of Microsoft Corporation in the United States and other countries.) The Java Virtual Machine (JVM) is a process VM that supports source code written in the Java language as well as other supported source code languages.

[0007] A snapshot point is a point in the execution flow of a running application at which the execution state can be saved for restoration in another instance of a process VM. A snapshot is data of the process VM state at the snapshot point, including data relevant to resuming execution from the snapshot point in another instance of the process VM. For example, a snapshot typically includes some or all of the JIT compiled code of the application, classes loaded up to the snapshot point, and the VM's heap that has been populated by executing some or all of the initializers for the classes up to the snapshot point. Once the snapshot is saved, it can be used in another process VM instance to resume execution from the snapshot point by recreating and repopulating the necessary data structures in the new instance. Summary of the Invention [Means for solving the problem]

[0008] Exemplary embodiments provide methods, systems, and computer program products. One embodiment includes a method for constructing a method list for a currently executing application in a process virtual machine at a snapshot point, where the method list includes a set of methods that can be executed by the currently executing application after the snapshot point, where the snapshot point includes an execution state of the currently executing application when a snapshot process is triggered. One embodiment commits profiling data of the currently executing application to a specified repository, where the profiling data is collected before the snapshot point is reached. One embodiment compiles a method in the method list using the profiling data and a just-in-time compiler of the process virtual machine. One embodiment stores snapshot data, where the snapshot data includes data of the execution state of the currently executing application at the snapshot point, where the snapshot data includes a result of the compiling.

[0009] One embodiment includes a computer-usable program product comprising one or more computer-readable storage devices and a plurality of program instructions stored on at least one of the one or more computer-readable storage devices.

[0010] One embodiment includes a computer system comprising one or more processors, one or more computer readable memories and one or more computer readable storage devices, and a plurality of program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more computer readable memories.

[0011] Certain novel features which are believed to be characteristic of the invention are set forth in the appended claims, however the invention itself, as well as preferred modes of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of illustrative embodiments when read in connection with the accompanying drawings. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 illustrates a block diagram of a network of data processing systems in which illustrative embodiments may be implemented. [Diagram 2] FIG. 2 illustrates a block diagram of a data processing system in which illustrative embodiments may be implemented. [Diagram 3] FIG. 3 illustrates a block diagram of an exemplary configuration for a compilation strategy for shareable application snapshots, in accordance with an exemplary embodiment. [Figure 4] FIG. 4 illustrates a block diagram of an exemplary configuration for a compilation strategy for shareable application snapshots, in accordance with an exemplary embodiment. [Diagram 5] FIG. 5 illustrates an example of a compilation strategy for a shareable application snapshot, in accordance with an exemplary embodiment. [Figure 6] FIG. 6 illustrates an example of a compilation strategy for a shareable application snapshot, according to an exemplary embodiment. [Figure 7] FIG. 7 illustrates an example of a subsequent compilation strategy for a shareable application snapshot, in accordance with an exemplary embodiment. [Figure 8] FIG. 8 illustrates an example of a subsequent compilation strategy for a shareable application snapshot, in accordance with an exemplary embodiment. [Figure 9] FIG. 9 illustrates an example of a subsequent compilation strategy for a shareable application snapshot, according to an exemplary embodiment. [Figure 10]FIG. 10 illustrates a flowchart of an exemplary process for a compilation strategy for a shareable application snapshot in accordance with an exemplary embodiment. [Figure 11] FIG. 11 illustrates a flowchart of an exemplary process for a compilation strategy for a shareable application snapshot in accordance with an exemplary embodiment. [Figure 12] FIG. 12 illustrates a cloud computing environment according to one embodiment of the invention. [Figure 13] FIG. 13 illustrates abstraction model layers according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Exemplary embodiments recognize that in modern cloud computing, servers are typically removed from service when not needed to serve user requests and returned to service when needed again. However, the startup times required to bring process VMs and applications from startup to full performance levels can be longer than the time available to serve demand spikes, resulting in slower than expected client service and violating service level agreements between service providers and their users.

[0014] The exemplary embodiments recognize that one currently available solution to the problem of quickly instantiating new server instances is to compile application code into a static native executable while including several startup time and memory footprint optimizations. One example of this technology is GraalVM Native Image, in which the native image runs in a VM that contains runtime components (e.g., deoptimizer, garbage collector, thread scheduling, etc.), the Substrate VM (GraalVM is a registered trademark of Oracle International Corporation in the United States and other countries). The resulting programs have faster startup times and lower runtime memory overhead compared to the Java VM. However, the Substrate VM can only support a subset of the Java programming language. As a result, implementing existing applications built in the Substrate VM using the traditional server-based model may require significant code changes.

[0015] The illustrative embodiments recognize that an improved solution to the problem of quickly instantiating new server instances can be implemented using snapshot functionality without requiring modifications to existing applications. In particular, the process VM and application are instantiated and run to a desired execution point, and then a snapshot is taken. Then, to create additional instances of the application, the saved snapshot is restored in the new instance, skipping the original initialization process. Also, multiple instances can be created in parallel from a single snapshot, saving further time.

[0016] Exemplary embodiments also recognize that performing the snapshot at the appropriate time within the application execution is critical to the effectiveness of the improved solution. If the snapshot is performed late within the application execution, open resources, such as files and network connections, may not be captured in the snapshot process, resulting in an inaccurate restore. However, if the snapshot has been running long enough to exercise common application code paths because it is under the full load of client requests, the snapshot has already compiled the code for those common code paths, as well as making other adjustments to optimize the application for full performance. Conversely, if the snapshot is performed early in the application execution, an inaccurate snapshot due to open resources is not a risk, but once the application is restored, too much additional code will need to be executed, lengthening the time it takes for the new instance to be able to respond to client requests. In addition, code that has not yet been executed will also not have had a chance to be profiled and optimized using profiling information, lengthening the time it takes for the application to reach an optimized performance level.

[0017] Exemplary embodiments recognize that other currently known solutions either do not use profiling information or use profiling information from a previous training-type run of the application to generate profiling information for a subsequent compilation. Static compilers (e.g., for generating native executables from C or C++ source code) often use this technique, but it requires separate training that takes very little time for the user to perform.

[0018] Exemplary embodiments also recognize that the snapshot should be able to share as much code as possible across multiple instances of a process VM running on common hardware. Sharing code across multiple instances reduces the total memory requirements of a set of instances. However, the instances must all be restored from a common snapshot that was built with shareability in mind.

[0019] Thus, the illustrative embodiments recognize that there is a need for improvements to snapshot-based application instantiation solutions that optimize application startup times and performance while maintaining code sharing. The illustrative embodiments recognize that currently available tools or solutions do not address or provide adequate solutions for these needs. The illustrative embodiments used to describe the present invention generally address and solve the above-mentioned problems and other problems associated with compilation strategies for shareable application snapshots.

[0020] One embodiment can be implemented as a software application. An application implementing one embodiment can be configured as a modification of an existing process VM snapshot system, as a separate application that operates in conjunction with an existing process VM snapshot system, as a standalone application, or some combination thereof.

[0021] In particular, some example embodiments provide a method for building, for an application currently executing in a process VM at the snapshot point, a list of methods that can be executed after the snapshot point, committing collected profiling data for the application to a specified repository, compiling the methods using the profiling data and a JIT compiler, and storing snapshot data including the compiled methods.

[0022] One embodiment begins executing an application in a process VM, which is configured to prevent compiling any application code. Instead, the application code is interpreted using existing process VM features, so forcing the code to be interpreted instead of compiled can cause a penalty in application throughput until a snapshot point is reached, since compiled code generally runs faster than interpreted code. However, delaying compilation until the snapshot point provides control over which portions of the application code are included in the snapshot in compiled form, and can maximize the profiling data that can be used during and after the snapshot. Controlling the contents of the snapshot provides tuning to optimize application startup time and performance while maintaining code sharing in an application instance restored from the snapshot. In one embodiment, preventing compilation is implemented by starting the process VM in a special snapshot mode that modifies the normal JIT compiler heuristics, allowing profiling data collection while preventing compilation decisions based on the profiling data.

[0023] One embodiment collects profiling data for the application as it executes within the process VM prior to the snapshot point. Some non-limiting examples of the profiling data include, for conditional branches, how often the condition is true and how often it is false, and, for virtual calls, the class type of the object being used as the receiver of the call. Both types of profiling data help the JIT compiler optimize the compiled code by predicting likely execution paths. In one embodiment, the profiling data is accumulated in one or more buffers. When the buffers approach capacity or at predetermined time intervals, one embodiment flushes or commits the buffered data to a predetermined memory location for use by the JIT compiler. In one embodiment, the predetermined memory location is a hash table of the JIT compiler. Other types of data structures and other memory locations within the process VM are also possible and contemplated within the scope of the exemplary embodiment.

[0024] A point in an application's execution is selected as the snapshot point, and one embodiment configures a snapshot handler to be triggered when the application's execution reaches the snapshot point. One embodiment receives the selected snapshot point during process VM initialization, e.g., as a parameter in a VM startup command or in a configuration file. In another embodiment, a user can select a snapshot point by invoking a snapshot command through an application program interface (API) from within a running application. In another embodiment, the process VM selects a snapshot point using its own internal heuristics. For example, a process VM may invoke a snapshot when a new class load rate of a running application falls below a threshold rate, indicating that the application has completed ramp-up and reached a stable performance state that should be snapshotted. As another example, a process VM may invoke a snapshot when an application begins to process representative work, e.g., a server application processes at least one client request. One embodiment uses any currently known technique to trigger a snapshot handler at a desired point.

[0025] When the snapshot handler is triggered at the snapshot point, one embodiment builds a method list. The method list includes a set of methods that can be executed by the currently executing application after the snapshot point. To build the method list, one embodiment references the call stacks of the application's active threads (i.e., those that were called when the snapshot point was reached but have not yet completed execution). A call stack is a data structure that stores information about the active methods of a computer program, including the point to which each active method should return when it finishes executing. In another embodiment, the method list includes a list of code units that can be executed by the currently executing application after the snapshot point, where the code units need not be methods.

[0026] In particular, to build the method list, if the code unit in the method list is a method, one embodiment selects the method that was currently executing when the snapshot point was reached. The embodiment adds the selected method to the method list and determines whether the selected method can call other methods. If so, the embodiment adds a new method to the method list and determines whether the new method can itself call other methods. The embodiment continues in this manner, accumulating all methods that can be called from the currently executing method. If another method is currently present in the call stack when the snapshot point is reached (i.e., the method calls the executing method), the embodiment repeats the process with that method. Additionally, if multiple threads of the application were executing, the embodiment repeats the process for another thread. Note that not all methods from all threads need to be analyzed for inclusion in the method list. Alternatively, if an embodiment has a means for determining that a particular method or group of methods is executed very frequently, compiling such methods may unnecessarily bloat the resulting snapshot in exchange for relatively little performance improvement when the application is restored. Thus, the resulting method list includes any methods currently executing, as well as any methods that the currently executing methods can call when execution continues after the snapshot point, either in the original VM or in a new instance restored from the snapshot. In one embodiment where the method list includes code units other than methods, to construct the method list, an embodiment analyzes the currently executing application and adds the currently executing code units to the method list, along with code units that can be executed from the snapshot point.

[0027] One embodiment maintains the method list in any currently known data structure. One non-limiting example of a data structure for the method list is a static call graph. A static call graph is a control flow graph that represents the calling relationships between methods in a computer program. Each node in the graph represents a method, each edge (f,g) indicates that method f calls method g, and a cycle in the graph indicates a recursive method call.

[0028] During construction of the method list, or after an embodiment has completed constructing the method list, an embodiment determines whether a method should be removed from the method list (or not added in the first place). An embodiment uses one or more criteria to determine whether a method should be filtered or removed from the method list. One non-limiting example of criteria for determining whether a method should be removed is based on an analysis of the probability of execution of the method. For example, if a method is executed only if a certain condition is true, and the condition is never true or has a probability of being true below a threshold, then the method is not needed in the method list and can be removed without impacting future application performance. Similarly, a method that is called only upon an exception may also not need to be compiled. As another example, all methods that are part of the calling method (e.g., methods embedded as inline code) may not need to be compiled individually because the calling method has already been compiled. As another example, when preparing a snapshot for an application framework to be used by other applications, some methods may need to be placed in the correct layer of the framework, so methods that are appropriate for a different layer may be removed from the method list.

[0029] When the snapshot handler is triggered at the snapshot point, one embodiment commits the buffered profiling data to a predetermined memory location of the JIT compiler. Committing the buffered profiling data at the snapshot point increases the amount of profiling data that can be used by the JIT compiler. For example, in experiments conducted using one embodiment, committing the buffered profiling data at a snapshot point doubled the amount of profiling data that can be used by the JIT compiler.

[0030] One embodiment uses a JIT compiler to compile one or more methods in the method list using the profiling data at a predetermined location. One embodiment compiles the code in a read-only mode so that the resulting snapshot after restore is shareable among multiple process VM instances. By performing compilation using as much profiling data as possible, the application throughput after the restore is improved without waiting for the application to reach a perfect performance level before taking the snapshot. In particular, at the snapshot point, some methods may have been executed sufficiently to accumulate good profiling, so the resulting compilation will have a correspondingly good throughput. Some methods may not have been executed sufficiently to accumulate good profiling, so the resulting compilation will have a correspondingly mediocre throughput. However, these methods can always be recompiled for improved throughput after the application is restored from the snapshot, without the snapshot process being delayed by waiting for these methods to be executed sufficiently to be compiled in normal operation. In addition, the overall throughput is still higher than if no profiling information was used at all, as is the case with some currently available solutions. Additionally, the overall throughput is comparable to solutions that require multiple runs of training type applications, but without the need to perform those multiple runs.

[0031] Another embodiment uses a JIT compiler to compile different optimized versions of one or more methods in the method list, trading off compilation time and snapshot size to improve application throughput and reduce ramp-up on restore.Another embodiment uses a JIT compiler to compile two different versions of a method in the method list, where one method is optimized normally and one method is compiled with debug support enabled, and allows normal operation and debugging using a single snapshot after restore.

[0032] Once an embodiment compiles the method, it stores the results of the compilation. One embodiment stores only one compilation result per method. Another embodiment stores two or more different optimized versions of a method in the snapshot, allowing different optimizations to be incorporated post-restore without recompiling while the application is running. Another embodiment stores both a compilation result that is normally optimized and a compilation result with debug support enabled, allowing normal operation and debugging using a single snapshot after restore. One embodiment also stores additional snapshot data. Some non-limiting examples of additional snapshot data are the classes loaded up to the snapshot point and the VM heap that has been populated by running some or all of the initializers for the classes loaded by the program up to the snapshot point.

[0033] When an application is restored from a snapshot, application profiling and JIT compilation are handled similarly to a normal running process VM. The new JIT compilation is expected to be a combination of recompilation of some performance-critical methods that were originally compiled during the snapshot, and initial compilation of methods from classes loaded after the restore. As a result, the restored application reaches peak performance with a shorter startup time than without using snapshots.

[0034] One embodiment can also be used to generate a native image at the snapshot point while the application continues to run normally (i.e., without the language constraints of some currently available solutions) and while benefiting from the profiling information already collected. The resulting native image will be smaller than the restored application, but will not have the improved throughput gained by including JIT compilation that runs normally after restoration. In addition, all methods or other code units that can be executed from the snapshot point will need to be compiled. This is because an interpreter or JIT compiler is not present in the native image and is not available to generate additional executable code.

[0035] The manner of compilation strategies for shareable application snapshots described herein is not available in currently available methods in the art related to snapshotting in process VMs. The method of one embodiment described herein, when implemented to run on a device or data processing system, comprises a substantial advance in the capabilities of the device or data processing system in building, for an application currently executing in a process VM at a snapshot point, a list of methods that can be executed after the snapshot point, committing collected profiling data of the application to a specified storage location, compiling the methods using the profiling data and a JIT compiler, and storing a snapshot including the compiled methods.

[0036] The exemplary implementations are described by way of example only with respect to certain types of process VMs, source code, bytecodes, machine instructions, computer language constructs, method listings, profiling data, predictions, thresholds, measurements, devices, data processing systems, environments, components, and applications. Any specific manifestations of these and other similar artifacts are not intended to limit the invention. Any suitable manifestations of these and other similar artifacts may be selected within the scope of the exemplary implementations.

[0037] Moreover, the 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 within the scope of the present invention, either locally at a data processing system or via a data network. Where an embodiment is described using a mobile device, any type of data storage device suitable for use with the mobile device may provide data to such an embodiment within the scope of the exemplary embodiments, either locally at the mobile device or via a data network.

[0038] The exemplary embodiments are described using specific code, designs, architectures, protocols, layouts, schematics, and tools as examples only, and not as limitations of the exemplary embodiments. Moreover, the exemplary embodiments may be described using specific software, tools, and data processing environments as examples only, for clarity of description. The exemplary embodiments may be used in combination with other structures, systems, applications, or architectures of equivalent or similar purposes. For example, other comparable 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.

[0039] 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 operations are contemplated by this disclosure, and the same are contemplated within the scope of the exemplary embodiments.

[0040] 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 enumerated above.

[0041] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings recited herein is not limited to a cloud computing environment. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0042] Cloud computing is a model of service delivery for enabling 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 the service provider. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0043] Its features are as follows.

[0044] On-demand self-service: A cloud consumer can unilaterally provision computing capacity, such as server time and network storage, as needed, without the need for human interaction with the provider of the service.

[0045] Broad Network Access: Capabilities are available over the network and accessed via standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, and PDAs).

[0046] Resource Pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, and various physical and virtual resources are dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the provided resources, but are said to be location-independent in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0047] Rapid Elasticity: Capabilities can be provisioned quickly and elastically, sometimes automatically, quickly scaled out, quickly released and quickly scaled in. To the consumer, the capabilities available for provisioning are often unlimited and can be purchased in any quantity at any time.

[0048] Measured Services: Cloud systems automatically control and optimize resource usage by using metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services being utilized.

[0049] The service model is as follows:

[0050] Software as a Service (SaaS): The capability offered to consumers to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface, e.g., a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0051] Platform as a Service (PaaS): A capability offered to a consumer to deploy consumer-created or acquired applications, created using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, e.g., including networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the application-hosting environment configuration.

[0052] Infrastructure as a Service (IaaS): The capability offered to consumers to provision processing, storage, network, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating systems, storage, deployed applications, and in some cases, limited control over selecting network components (e.g., host firewalls).

[0053] The deployment models are as follows:

[0054] Private Cloud: Cloud infrastructure is operated exclusively for an organization. The cloud infrastructure may be managed by the organization or a third party, and may be on-premises or off-premises.

[0055] Community Cloud: Cloud infrastructure is shared by several organizations and supports a particular community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organizations or a third party, and may reside on-premise or off-premise.

[0056] Public Cloud: The cloud infrastructure is available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0057] Hybrid Cloud: The cloud infrastructure remains a unique entity, but is a hybrid of two or more clouds (private, community, or public) brought together by standardized or specialized technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0058] A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0059]

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

[0060] 1 illustrates a block diagram of 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 wired communications links, wireless communications links, or fiber optic cables.

[0061] Client or server are merely exemplary roles of certain data processing systems connected to network 102 and are not intended to exclude other configurations or roles of these data processing systems. Server 104 and server 106 connect to network 102 along with storage unit 108. Software applications may run on any computer in data processing environment 100. Clients 110, 112, and 114 are also connected to network 102. A data processing system, for example server 104 or 106, or client 110, 112, or 114, may contain data as well as have software applications or software tools running thereon.

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

[0063] Device 132 is an example of a device 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. Any software application described in FIG. 1 as executing in another data processing system may be configured to execute in device 132 in a similar manner. Any data or information stored or generated in another data processing system in FIG. 1 may be configured to be stored or generated in device 132 in a similar manner.

[0064] The application 105 implements the embodiments described herein. The application 105 may run on any of the servers 104 and 106, the clients 110, 112 and 114, and the device 132.

[0065] The servers 104 and 106, the storage unit 108, and the clients 110, 112 and 114, and the device 132 may be coupled to the network 102 using wired connections, wireless communication protocols, or other suitable data connections. The clients 110, 112 and 114 may be, for example, personal computers or network computers.

[0066] In the illustrated example, server 104 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 104 in this example. Clients 110, 112, 114, or some combination thereof, may have their own data, boot files, operating system images, and applications. Data processing environment 100 may include additional servers, clients, and other devices not shown.

[0067] 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 its core, the Internet is a backbone of data communication links between major nodes or host computers, encompassing thousands of commercial, governmental, educational, and other computer systems that route data and messages. Of course, data processing environment 100 may also 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 an architectural limitation for different illustrative implementations.

[0068] 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 by using interactions between 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 together as a coherent business application. Data processing environment 100 may also take the form of a cloud and use 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 the provider of the service.

[0069] Referring to Figure 2, this figure illustrates a block diagram of a data processing system in which exemplary embodiments may be implemented. Data processing system 200 is an example of a computer, such as servers 104 and 106, or clients 110, 112, and 114 in Figure 1, or another type of device in which computer usable program code or instructions implementing the processes for the exemplary embodiments may be located.

[0070] Data processing system 200 is also representative of a data processing system or configuration thereof, such as data processing system 132 in FIG. 1, in which computer usable program code or instructions implementing the processing of the exemplary embodiments may be located. Data processing system 200 is described only as a computer by way of example and not by way of limitation. Implementations in the form of other devices, such as device 132 in FIG. 1, may modify data processing system 200, for example by adding a touch interface, or even remove certain illustrated components from data processing system 200, without departing from the general description of the operation and functionality of data processing system 200 described herein.

[0071] In the illustrated example, data processing system 200 uses a hub architecture including a North Bridge and memory controller hub (NB / MCH) 202 and a South Bridge and input / output (I / O) controller hub (SB / ICH) 204. A processing unit 206, a main memory 208, and a graphics processor 210 are connected to North Bridge 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 through an accelerated graphics port (AGP) in some implementations.

[0072] In the illustrated example, a local area network (LAN) adapter 212 is connected to the south bridge 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 connected to the south bridge and I / O controller hub 204 through a bus 238. A hard disk drive (HDD) or solid-state drive (SSD) 226 and a CD-ROM 230 are connected to the south bridge and I / O controller hub 204 through a bus 240. The PCI / PCIe devices 234 may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller while PCIe does not. 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 advanced technology attachment (SATA) interfaces, or variations thereof, such as external SATA (eSATA) and micro-SATA. Super I / O (SIO) device 236 may be coupled to south bridge and I / O controller hub (SB / ICH) 204 via bus 238.

[0073] Memory, 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 comprise computer usable storage media.

[0074] 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 work in conjunction with the operating system and may provide calls to the operating system from programs or applications running on data processing system 200.

[0075] Instructions for the operating system, the object-oriented programming system, and an application or program, such as application 105 in Figure 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.

[0076] Moreover, in some cases, the code 226A may be downloaded over the network 201A from a remote system 201B where similar code 201C is stored on a storage device 201D, and in other cases, the code 226A may be downloaded over the network 201A to the remote system 201B where the downloaded code 201C is stored on a storage device 201D.

[0077] 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. Additionally, the processing of the exemplary implementations may be applied to a multiprocessor data processing system.

[0078] In some illustrative examples, data processing system 200 may be a personal digital assistant (PDA), which is typically configured with flash memory to provide non-volatile memory for storing operating system files or user generated data, or a combination thereof. The bus system may include one or more buses, such as a system bus, an I / O bus, and a PCI bus. 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.

[0079] The communications unit may include one or more devices used to transmit 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 found in north bridge and memory controller hub 202. The processing unit may include one or more processors or CPUs.

[0080] 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 device or a wearable device.

[0081] 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 virtualized manifestations 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 some portion of main memory 208 available in the host data processing system, and disk 226 is manifested as a virtualized instance of all or some portion of disk 226 that may be available in the host data processing system. The host data processing system in such a case is represented by data processing system 200.

[0082] 3, which illustrates a block diagram of an exemplary configuration for a compilation strategy for shareable application snapshots in accordance with an exemplary embodiment. Application 300 is an example of application 105 in FIG. 1 and may run on any of servers 104 and 106, clients 110, 112 and 114, and device 132 in FIG.

[0083] Application 300 begins executing the application in a process VM, where the process VM is configured to prevent compilation of any application code. Instead, the application code is interpreted using the functionality of the existing process VM. Application 300 collects profiling data for the application as it executes in the process VM prior to a snapshot point. The profiling data is accumulated in one or more buffers. A point in the application execution is selected as a snapshot point, and application 300 configures a snapshot handler to be triggered when the application execution reaches the snapshot point.

[0084] When the snapshot handler is triggered at the snapshot point, a method list builder module 310 builds a method list. The method list contains a set of methods that can be executed by the currently running application after the snapshot point. To build the method list, module 310 references the call stacks of the application's active threads. Additional details of module 310 are provided with reference to FIG. 4.

[0085] When the buffer approaches capacity, or at predetermined time intervals, a profiled data commitment module 320 commits the buffered data to a predetermined location for use by the JIT compiler. Similarly, when the snapshot handler is triggered at a snapshot point, module 320 commits the JIT compiler's predetermined compiler buffered profiling data. Committing the buffered profiling data at the snapshot point increases the amount of profiling data available for use by the JIT compiler.

[0086] A compilation module 330 uses a JIT compiler to compile one or more methods in the method list using the profiling data to a predetermined location. Another implementation of module 330 uses a JIT compiler to compile different optimized versions of one or more methods in the method list, trading off compilation time and snapshot size to improve application throughput and reduce ramp-up on restore. Another implementation of module 330 uses a JIT compiler to compile two different versions of a method in the method list, where one method is optimized normally and one method is compiled with debug support enabled.

[0087] The snapshot data module 340 stores the results of the compilation. One implementation of the module 340 stores only one compilation result per method. Another implementation of the module 340 stores two or more different optimized versions of a method in the snapshot, allowing different optimizations to be incorporated post-restore without recompiling the application while it is running. Another implementation of the module 340 stores both a compilation result that is normally optimized and a compilation result with debug support enabled, allowing normal operation and debugging using a single snapshot after restore. The module 340 also stores additional snapshot data.

[0088] 4, which illustrates a block diagram of an exemplary configuration for a compilation strategy for shareable application snapshots in accordance with an exemplary embodiment. FIG. 4 illustrates a more detailed configuration of the method list builder module 310 in FIG.

[0089] To build the method list, method addition module 410 selects one method that was currently executing when the snapshot point was reached. Module 410 adds the selected method to the method list and determines if the selected method can call another method. If so, module 410 adds a new method to the method list and determines if the new method can itself call another method. Module 410 continues in this manner, accumulating all methods that can be called from the currently executing method. If another method was currently executing when the snapshot point was reached, module 410 repeats the process with that method. In addition, if multiple threads of the application were executing, module 410 repeats the process for another thread. Thus, the resulting method list includes any currently executing methods as well as any methods that the currently executing methods can call when execution continues after the snapshot point, either in the original VM or in a new instance restored from the snapshot. Module 410 maintains the method list in any currently known data structure, such as a static call graph.

[0090] During construction of the method list, or after module 410 has completed constructing the method list, method removal module 420 determines whether a method should be removed from the method list (or not added in the first place). Module 420 uses one or more criteria to determine whether a method should be filtered or removed from the method list. One non-limiting example of criteria for determining whether a method should be removed is based on an analysis of the probability of execution of the method. For example, if a method is executed only if a certain condition is true, and the condition is never true or has a probability of being true below a threshold, then the method is not needed in the method list and can be removed without affecting future application performance. Similarly, a method that is called only upon an exception may also not need to be compiled. As another example, all methods that are part of the calling method (e.g., methods embedded as inline code) may not need to be compiled separately because the calling method has already been compiled. As another example, when preparing a snapshot for an application framework to be used by other applications, some methods need to be placed in the correct layer of the framework, so methods that are appropriate for a different layer may be removed from the method list.

[0091] 5, which illustrates an example of a compilation strategy for a shareable application snapshot in accordance with an exemplary embodiment, which can be implemented using application 300 in FIG.

[0092] As shown, application 510 begins executing in a process VM. As application 510 executes prior to a snapshot point, profiling data 520 accumulates in profiling buffer 530. When buffer 530 approaches capacity, or at predefined time intervals, or at the snapshot point, application 300 transfers committed profiling data 540 into profiling data storage 550 for use by the JIT compiler.

[0093] 6, this figure illustrates an example of a compilation strategy for a shareable application snapshot according to an exemplary embodiment. The example can be implemented using application 300 in FIG. 3. Method addition module 410 is the same as method addition module 410 in FIG.

[0094] Source code 610 is a portion of an example of executing application 510 in Figure 5. As shown, source code 610 calls Method1(), then Method2(). Method2() calls Method3(). Method2() includes code to call Method4() only if Method1() is greater than Method2() (which never happens).

[0095] A snapshot point 620 occurs while method 1() in MyClass is executing. As a result, the method addition module 410 builds a method list 630. MyClass and method 1() are currently executing. Because method 2() is called after method 1(), method 2() is also in the method list 630 along with method 3() and method 4() because method 3() and method 4() can be called by method 2().

[0096] 7, which illustrates an example of a continuation of a compilation strategy for a shareable application snapshot in accordance with an exemplary embodiment. Method removal module 420 is the same as method removal module 420 in FIG. 4. Method list 630 is the same as method list 630 in FIG.

[0097] Here, method removal module 420 determines that method 4() does not need to be compiled because method 2() contains code to call method 4() only if method 1() is greater than method 2() (which never happens). Therefore, module 420 removes method 4() from method list 630, resulting in method list 730.

[0098] 8, which illustrates an example of a continuation of a compilation strategy for a shareable application snapshot in accordance with an exemplary embodiment. Compilation module 330 is the same as compilation module 330 in FIG. 3. Method list 730 is the same as method list 730 in FIG. 7. As shown, compilation module 330 compiles each of the methods in method list 730, resulting in compiled code 810.

[0099] 9, which illustrates an example of a continuation of a compilation strategy for a shareable application snapshot in accordance with an exemplary embodiment. Snapshot data module 340 is the same as snapshot data module 340 in FIG. 3. Application 510 and profiled data storage 550 are the same as application 510 and profiled data storage 550 in FIG. 5. Compiled code 810 is the same as compiled code 810 in FIG. 8. As shown, snapshot data module 340 populates compiled code 810, data from profiled data storage 550, and execution state data 910 of application 510 into snapshot data 920.

[0100] 10, which illustrates a flow chart diagram of an exemplary process for a compilation strategy for a shareable application snapshot in accordance with an exemplary embodiment. The process 1000 can be implemented in the application 300 in FIG.

[0101] In block 1002, the application starts a process virtual machine in a snapshot mode that prevents compilation of methods in the application in the process virtual machine. In block 1004, the application builds a method list for the application currently executing in the process virtual machine at the snapshot point, the method list including a set of methods that can be executed by the application after the snapshot point. In block 1006, the application commits profiling data of the currently executing application that was collected before reaching the snapshot point to a specified repository. In block 1008, the application compiles the set of methods in the method list using the profiling data and a just-in-time compiler of the process virtual machine. In block 1010, the application stores snapshot data including data of the execution state of the application at the snapshot point, where the snapshot data includes the results of the compilation. The application then terminates.

[0102] 11, a flow chart diagram of an exemplary process for a compilation strategy for a shareable application snapshot is illustrated, in accordance with an exemplary embodiment. The flow chart diagram illustrates block 1004 in FIG. 10 in greater detail.

[0103] In block 1102, the application selects a method currently being executed by the application. In block 1104, the application adds the currently selected method to a method list. In block 1106, the application determines whether the currently selected method calls another method. If so (the "Yes" path of block 1106), in block 1108, the application designates the called method as the currently selected method and then returns to block 1104. If not (the "No" path of block 1106), in block 1110, the application determines whether there is another method currently being executed to process. If so (the "Yes" path of block 1110), in block 1112, the application designates the next method to process as the currently selected method and then returns to block 1104. If not (the "No" path out of block 1110), the application filters the method list based on one or more criteria in block 1114. The application then terminates.

[0104] 12, an exemplary cloud computing environment 50 is illustrated. As illustrated, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, may communicate. The nodes 10 may communicate with each other. They may be physically or virtually grouped in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described herein (not shown). This allows the cloud computing environment 50 to provide infrastructure, platform, or software, or combinations thereof, as a service without the cloud consumer having to maintain resources on the local computing device. It is understood that the types of computing devices 54A-N illustrated are intended to be exemplary only, and that the computing nodes 10 and the cloud computing environment 50 communicate with any type of computerized device (e.g., using a web browser) over any type of network or network addressable connection or combinations thereof.

[0105] 13, there is shown a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 12). It should be understood that the illustrated components, layers and functions are intended to be merely exemplary, and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0106] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61, RISC (Reduced Instruction Set Computer) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0107] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73, including, for example, virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0108] In one example, the management layer 80 may provide multiple functions described below. Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, and protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides allocation and management of cloud computing resources such that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-provisioning and procurement of cloud computing resources where future requirements are predicted according to SLAs.

[0109] Workload tier 90 provides examples of functions for which the cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 91; software development and lifecycle management 92; virtual classroom instructional delivery 93; data analytics processing 94; transaction processing 95; and applications based on cumulative vulnerability risk assessment 96.

[0110] Thus, computer-implemented methods, systems or apparatus and computer program products are provided in exemplary embodiments for compilation strategies for shareable application snapshots and other related features, functions or operations. Where an embodiment or portion thereof is described with respect to a certain type of device, the computer-implemented method, system or apparatus and computer program product, or portion thereof, is adapted or configured for use with the appropriate and equivalent representation of that type of device.

[0111] When 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 the exemplary embodiment. In the SaaS model, the functionality of an application implementing an embodiment is provided to a user by executing the application in a cloud infrastructure. The user 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 light-weight client application. The user does not manage or control the underlying cloud infrastructure, such as the network, servers, operating system, or storage of the cloud infrastructure. In some cases, the user may not even manage or control the functionality of the SaaS application. In some other cases, the SaaS implementation of the application may allow possible exceptions to limited user-specific application configuration settings.

[0112] The present invention may be a system, method, or computer program product, or combination thereof, at any level of technical detail that may be integrated. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0113] The computer readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or a ridge structure in a groove in which instructions are recorded, or any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0114] The computer readable program instructions described herein can be downloaded from a computer readable storage medium to an individual computing device / processing device or to an external computer or external storage device via a network, such as 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 transmission, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions to the individual computing device / processing device for storage in a computer readable storage medium.

[0115] The computer readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, such as object-oriented programming languages, such as Smalltalk, C++, and the like, conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a stand-alone software package, 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 kind of network, such as a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, such as programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

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

[0117] These computer readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / operations specified in one or more blocks of the flowchart illustrations or block diagrams, or combinations thereof, to produce a machine. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer programmable data processing apparatus or other device, or combinations thereof, to function in a particular manner, such that a computer readable storage medium having stored thereon includes an article of manufacture including instructions that implement aspects of the functions / operations specified in one or more blocks of the flowchart illustrations or block diagrams, or combinations thereof.

[0118] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on a computer, other programmable data processing apparatus, or other device, implement the functions / acts identified in one or more blocks of the flowchart illustrations or block diagrams, or combinations thereof, to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process.

[0119] The flowchart diagrams and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products or computer programs according to various embodiments of the present invention. In this regard, each block in the flowchart diagrams or block diagrams may represent a module, segment, or portion of an instruction, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the drawings. For example, two blocks shown in succession may actually be accomplished as one step performed simultaneously, substantially simultaneously, partially or fully in a time-overlapping manner, depending on the functions involved, or the blocks may be performed in the reverse order. It should be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, as well as combinations of multiple blocks of the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special purpose hardware and computer instructions.

Claims

1. 1. A computer-implemented method comprising: building a method list for a currently executing application within a process virtual machine at a snapshot point, where the method list includes a set of methods that can be executed by the currently executing application after the snapshot point, and the snapshot point includes an execution state of the currently executing application when a snapshot process was triggered; committing profiling data of the currently executing application to a specified repository, where the profiling data was collected before reaching the snapshot point; compiling a method in the method list using the profiling data and a just-in-time compiler of the process virtual machine; and storing snapshot data, where the snapshot data includes data of the execution state of the currently-executing application at the snapshot point, and the snapshot data includes a result of the compiling; The method comprising:

2. Preventing compilation of methods of the application for the currently running application before the snapshot process is triggered. The computer-implemented method of claim 1 , further comprising:

3. Collecting the profiling data for the currently-running application before the snapshot process is triggered. The computer-implemented method of claim 1 , further comprising:

4. Constructing the method list comprises: adding to the method list a first method currently being executed by the currently-executing application at the snapshot point; and adding the second method to the method list in response to determining that the second method can be called by the first method.

2. The computer-implemented method of claim 1, comprising:

5. adding the third method to the method list in response to determining that the third method can be called by the second method. The computer-implemented method of claim 4 , further comprising:

6. removing the third method from the method list in response to determining that characteristics of a third method in the method list meet a criterion. The computer-implemented method of claim 4 , further comprising:

7. The computer-implemented method of claim 6 , wherein the criteria is based on an analysis of a probability of execution of the third method within the currently executing application.

8. 1. A computer program product for a compilation strategy for a shareable application snapshot, comprising: program instructions for constructing a method list for a currently executing application within a process virtual machine at a snapshot point, where the method list includes a set of methods that can be executed by the currently executing application after the snapshot point, and where the snapshot point includes an execution state of the currently executing application when a snapshot process is triggered; program instructions for committing profiling data of the currently executing application to a specified storage location, where the profiling data was collected before reaching the snapshot point; program instructions for compiling a method in the method list using the profiling data and a just-in-time compiler of the process virtual machine; and program instructions for storing snapshot data, wherein the snapshot data includes data of the execution state of the currently-executing application at the snapshot point, and the snapshot data includes a result of the compiling; The computer program product is executed by one or more processors.

9. program instructions for preventing compilation of methods of the application for the currently executing application before the snapshot process is triggered; The computer program product of claim 8 , further comprising the steps of:

10. program instructions for collecting the profiling data for the currently-executing application before the snapshot process is triggered; The computer program product of claim 8 , further comprising the steps of:

11. Constructing the method list comprises: program instructions for adding to the method list a first method currently being executed by the currently-executing application at the snapshot point; and program instructions for adding the second method to the method list in response to determining that the second method can be called by the first method; 9. The computer program of claim 8, comprising:

12. program instructions for adding a third method to the method list in response to determining that a third method can be called by the second method; The computer program product of claim 11 , further comprising the step of:

13. program instructions for removing the third method from the method list in response to determining that characteristics of the third method in the method list meet a criterion; The computer program product of claim 11 , further comprising the step of:

14. The computer program product of claim 13 , wherein the criteria is based on an analysis of a probability of execution of the third method within the currently executing application.

15. 9. The computer program product of claim 8, wherein each of the program instructions is stored within at least one of the one or more recording media of a local data processing system, and the stored program instructions are transferred over a network from a remote data processing system.

16. 9. The computer program product of claim 8, wherein each of the program instructions is stored in at least one of the one or more recording media of 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.

17. The computer program of claim 8 , wherein the computer program is provided as a service in a cloud environment.

18. 1. A computer system comprising one or more processors, one or more computer readable memories and one or more computer readable storage devices, and a plurality of program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more computer readable memories, the stored plurality of program instructions comprising: program instructions for constructing a method list for a currently executing application within a process virtual machine at a snapshot point, where the method list includes a set of methods that can be executed by the currently executing application after the snapshot point, and where the snapshot point includes an execution state of the currently executing application when a snapshot process is triggered; program instructions for committing profiling data of the currently executing application to a specified storage location, where the profiling data was collected before reaching the snapshot point; program instructions for compiling a method in the method list using the profiling data and a just-in-time compiler of the process virtual machine; and program instructions for storing snapshot data, wherein the snapshot data includes data of the execution state of the currently-executing application at the snapshot point, and the snapshot data includes a result of the compiling; The computer system comprising:

19. program instructions for preventing compilation of methods of the application for the currently executing application before the snapshot process is triggered; 20. The computer system of claim 18, further comprising:

20. program instructions for collecting the profiling data for the currently-executing application before the snapshot process is triggered; 20. The computer system of claim 18, further comprising:

Images