Compilation strategies for shareable application snapshots

Abstract

A method list is built for a currently executing application at an intrinsic snapshot point of a process virtual machine, the method list including a set of methods that can be executed by the currently executing application after the snapshot point, the snapshot point including an execution state of the currently executing application when a snapshot process is triggered. Sidecar data of the currently executing application collected prior to reaching the snapshot point is committed to a designated storage location. Using the sidecar data and a just-in-time compiler of the process virtual machine, the methods in the method list are compiled. Snapshot data is stored, the snapshot data including data of the execution state of the currently executing application at the snapshot point, including results of the compilation.

Description

Background Technology

[0001] This invention generally relates to a method, system, and computer program product for application compilation. More specifically, this invention relates to a method, system, and computer program product for a compilation strategy that allows for sharing application snapshots.

[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 the host operating system. The 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 execute on platforms with different configurations without modification.

[0003] Several options are available for application execution within a process VM environment. First, the application's source code (such as that of a high-level language like Java) can be compiled into an executable file with processor-specific instructions, also known as a native executable, native image, or native machine code. (Java is a registered trademark of Oracle America, Inc. in the U.S. and other countries.) At runtime, the environment loads the executable into memory and executes the instructions. While executables do not require additional processing at runtime, their static nature means that program code must be separated from data, and other dynamic language features require additional runtime support, resulting in a performance penalty. Similarly, because static executables must include code for handling exceptions, they contain a small amount of executable code that consumes additional memory space.

[0004] Another option for application execution is to compile the application source code into an intermediate representation called bytecode. Bytecode is similar to machine code for a specific processor or processor family, but it is not processor-specific. Then, to execute the application's bytecode, the process VM uses an interpreter that translates one or more bytecode instructions at a time into corresponding processor-specific instructions, which the specific processor then executes. Because the interpretation process adds execution time, interpreted code doesn't execute as well as statically executable files, but it is better suited for changing environments and avoids unnecessary code processing.

[0005] The third option is a Just-In-Time (JIT) compiler, which translates parts of bytecode into processor-specific instructions (also known as machine code) while the application is executing and saves the compiled results for reuse. Compilation can be done per file, per method, or on another unit of code. A method (also known as a procedure, subroutine, or function) is a block of code that runs only when it is called. Because the compilation process itself takes time, most process VMs improve overall application performance by compiling code only when it is about to be used (hence the term Just-In-Time compilation), compiling only the most frequently used code (and interpreting the rest of the code), or a combination of these techniques. Some process VMs collect profiling information while the application is executing and use this information to further refine the decision of whether to compile a part of the code and improve both the resulting compiled code.

[0006] Two currently known examples of process virtual machines 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 U.S. and other countries.) The Java Virtual Machine (JVM) is a process virtual machine that supports source code written in Java and other supported source code languages.

[0007] A snapshot is a point in the execution flow of an application that allows the execution state to be stored for resumption in another instance of the process VM. A snapshot is data about the process VM state at that 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 JIT-compiled code for part or all of the application, classes loaded up to the snapshot point, and the VM's heap populated by running some or all initializers for the classes up to the snapshot point. Once a snapshot is saved, it can be used in another instance of the process VM to resume execution from the snapshot point by recreating and repopulating the necessary data structures in the new instance. Summary of the Invention

[0008] Illustrative embodiments provide a method, system, and computer program product. One embodiment includes a method for establishing a list of methods for a currently executing application at a snapshot point within a process virtual machine. This list includes a set of methods that can be executed by the currently executing application after the snapshot point, which includes the execution state of the currently executing application when a snapshot process is triggered. The embodiment submits profile data of the currently executing application to a designated storage location, the profile data being collected prior to reaching the snapshot point. The embodiment uses the profile data and a just-in-time (JIT) compiler of the process virtual machine to compile the methods in the method list. The embodiment stores snapshot data, which includes data on the execution state of the currently executing application at the snapshot point, and includes the results of the compilation.

[0009] The embodiments include a computer-usable program product. The computer-usable program product includes one or more computer-readable storage devices and program instructions stored on at least one of the one or more storage devices.

[0010] The embodiment includes a computer system. The computer system includes one or more processors, one or more computer-readable memories, and one or more computer-readable storage devices, as well as 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 memories. Attached Figure Description

[0011] Certain novel features considered 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 be best understood by reading in conjunction with the accompanying drawings and by referring to the following detailed description of illustrative embodiments, wherein:

[0012] Figure 1 A block diagram of a network that can implement an illustrative embodiment of a data processing system is shown;

[0013] Figure 2 A block diagram of a data processing system that can implement illustrative embodiments is shown;

[0014] Figure 3 A block diagram depicts an example configuration of a build strategy for shareable application snapshots according to an illustrative embodiment;

[0015] Figure 4 A block diagram depicts an example configuration of a build strategy for shareable application snapshots according to an illustrative embodiment;

[0016] Figure 5 An example of a compilation strategy for shareable application snapshots, according to an illustrative embodiment, is described;

[0017] Figure 6 Further examples of a compilation strategy for shareable application snapshots, according to illustrative embodiments, are described;

[0018] Figure 7 Further examples of a compilation strategy for shareable application snapshots, according to illustrative embodiments, are described;

[0019] Figure 8 Further examples of a compilation strategy for shareable application snapshots, according to illustrative embodiments, are described;

[0020] Figure 9 Further examples of a compilation strategy for shareable application snapshots, according to illustrative embodiments, are described;

[0021] Figure 10 A flowchart depicts an example process for a compilation strategy for shareable application snapshots according to an illustrative embodiment;

[0022] Figure 11 A flowchart depicts an example process for a compilation strategy for shareable application snapshots according to an illustrative embodiment;

[0023] Figure 12 A cloud computing environment according to an embodiment of the present invention is described; and

[0024] Figure 13 An abstract model layer according to an embodiment of the present invention is shown. Detailed Implementation

[0025] The illustrative embodiments recognize that in modern cloud computing, servers are typically removed from the service when they are no longer needed by user requests, and are returned to the service when needed again. However, the startup time required to bring process VMs and applications from startup to full performance levels can take longer than the time available to respond to demand spikes, resulting in slower-than-expected customer service and potentially violating the service level agreement between the service provider and its users.

[0026] The illustrative embodiments recognize that one currently available solution to the problem of rapidly instantiating new server instances is to compile application code into a statically typed native executable, while incorporating some startup time and memory footprint optimizations. An example of this technique is the GraalVM native image, where the native image runs within a VM (Substrate VM) that includes runtime components such as an optimizer, garbage collector, thread scheduler, etc. (GraalVM is a registered trademark of Oracle International, Inc. in the U.S. and other countries.) The resulting program has faster startup time and lower runtime memory overhead compared to the Java VM. However, SubstrateVM can only support a subset of the Java programming language. As a result, implementing existing applications built using a traditional server-based model within SubstrateVM may require significant code changes.

[0027] The illustrative embodiments recognize that an improved solution to the problem of rapidly instantiating new server instances can be achieved using snapshot capabilities without modifying existing applications. Specifically, the process VM and application are instantiated and executed until the desired execution point, at which point a snapshot is taken. Then, to create another instance of the application, the stored snapshot is restored in the new instance, thus skipping the original initialization process. Similarly, multiple instances can be created in parallel from a single snapshot, saving additional time.

[0028] The illustrative embodiments also recognize that taking snapshots at appropriate times within application execution is important for the effectiveness of the improved solution. If snapshots are taken late in application execution, open resources such as files and network connections may not be captured during the snapshot process, leading to incorrect recovery. However, snapshots that have been executed long enough to cover common application code paths (as they will be under full load of client requests) have already compiled the code in those common code paths and made additional tweaks to optimize the application for full performance. Conversely, if snapshots are taken early in application execution, incorrect snapshots due to open resources are not a risk, but once the application is recovered, too much additional code will need to be executed, increasing the time until a new instance is available to respond to client requests. Furthermore, code that has not yet been executed has not yet had the opportunity to be profiled and optimized using profiled information, increasing the time required for the application to reach optimized performance levels.

[0029] The illustrative embodiments recognize that other currently known solutions either do not use profile information or use profile information from previous training runs of the application to generate profile information for subsequent compilation. Static compilers (e.g., for generating native executables from C or C++ source code) typically use this technique, but it requires separate training that the user spends very little time performing.

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

[0031] Therefore, the illustrative embodiments recognize the need for improved snapshot-based application instantiation solutions that optimize application startup time and performance while maintaining code sharing. The illustrative embodiments recognize that currently available tools or solutions do not address these needs or provide sufficient solutions for them. The illustrative embodiments used to describe the invention generally focus on and resolve the above-mentioned problems and other issues related to compilation strategies for shareable application snapshots.

[0032] The implementation examples can be implemented as software applications. Applications implementing the implementation examples can be configured as modifications to an existing process VM snapshot system, standalone applications that operate in conjunction with an existing process VM snapshot system, independent applications, or some combination thereof.

[0033] In particular, some illustrative embodiments provide a method for building a list of methods that can be executed after the snapshot point for a currently executing application within the process VM, submitting collected application profile data to a specified storage location, compiling the methods using the profile data and a JIT compiler, and storing snapshot data including the compiled methods.

[0034] The embodiment begins by executing the application within a process VM, where the process VM is configured to prevent the compilation of any application code. Instead, existing process VM capabilities are used to interpret the application code. Forcing code to be interpreted instead of compiled can result in a penalty to application throughput up to the snapshot point, since compiled code typically executes faster than interpreted code. However, delaying compilation until the snapshot point provides control over which parts of the application code are included in the snapshot in compiled form and maximizes the profile data available for use during and after the snapshot. Controlling the snapshot contents allows for adjustments to optimize application startup time and performance while maintaining code sharing across application instances recovered from the snapshot. In one embodiment, compilation blocking is achieved by launching the process VM in a special snapshot mode that alters the normal JIT compiler heuristic, thereby allowing profile data collection while preventing compilation decisions based on profile data.

[0035] While the application is executing within the process VM prior to a snapshot point, the embodiment collects profile data of the application. Some non-limiting examples of profile data include: for conditional branches, the frequency of conditions being true versus the frequency of conditions being false, and for virtual calls, the class type of the object used as the receiver of the call. Both types of profile data help the JIT compiler optimize compiled code by predicting possible execution paths. In one embodiment, profile data is accumulated in one or more buffers. When a buffer is nearing capacity or at predetermined time intervals, the embodiment flushes or commits the buffered data to a predetermined storage location for use by the JIT compiler. In one embodiment, the predetermined storage location is a hash table of the JIT compiler. Other types of data structures and other storage locations within the process VM are also possible and are considered to be within the scope of the illustrative embodiment.

[0036] Points within the application execution are selected as snapshot points, and embodiments configure snapshot handlers to be triggered when the application execution reaches a snapshot point. One embodiment receives the selected snapshot point during process VM initialization, for example, as a parameter in the VM startup command or configuration file. Another embodiment allows a user to select a snapshot point by invoking a snapshot command from within the executing application via an application programming interface (API). In another embodiment, the process VM uses its own internal heuristics to select snapshot points. For example, when the rate at which the executing application loads new classes has fallen below a threshold rate, the process VM can invoke a snapshot, indicating that the application has completed ramping up and reached a stable performance state where a snapshot should be taken. As another example, the process VM can invoke a snapshot when the application has begun processing representative work (e.g., when a server application has processed at least one client request). Embodiments use any currently known techniques to trigger snapshot handlers at desired points.

[0037] When the snapshot handler is triggered at a snapshot point, the embodiment constructs 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 construct the method list, the embodiment consults the call stack of the application's active threads (i.e., those invoked but not yet completed at the snapshot point). The 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 upon completion of its execution. 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 do not need to be methods.

[0038] Specifically, to construct the method list, if the code unit in the method list is a method, the embodiment selects the method currently being executed at the snapshot point. The embodiment adds the selected method to the method list and determines whether the selected method can call another method. If so, the embodiment adds a new method to the method list and determines whether the new method can call another method itself. The embodiment continues in this manner, accumulating all methods that can be called from the currently executing method. If another method currently exists in the call stack when the snapshot point is reached (i.e., that method has already called the executing method), the embodiment repeats this process for that method. Furthermore, if multiple threads of the application are executing, the embodiment repeats this process for each thread. Note that it is not necessary to analyze all methods from all threads to include in the method list. Conversely, if the embodiment has a means to determine that the execution frequency of a particular method or group of methods is very low, compiling such methods may unnecessarily bloat the resulting snapshot, with the reward of a relatively small performance improvement when the application is restored. Therefore, the resulting method list includes any currently executing method and any methods that the currently executing method can call in the original VM or in a new instance restored from the snapshot when execution continues after the snapshot point. In embodiments where the method list includes code units that are not exclusive methods, in order to construct the method list, the embodiment analyzes the currently executing application to add currently executing code units along with code units that can be executed from a snapshot point to the method list.

[0039] The implementation maintains the method list in any currently known data structure. A 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 loops in the graph indicate recursive method calls.

[0040] During method list construction, or after an embodiment has completed method list construction, the embodiment determines whether a method should be removed from the method list (or not initially added). The embodiment uses one or more criteria to determine whether a method should be filtered or removed from the method list. A non-limiting example of a criterion for determining whether a method should be removed is based on an analysis of the method's execution probability. For example, if a method will only execute if a condition is true, but that condition may never be true or has a probability below a threshold for being true, then that method does not need to be in the method list and can be removed without affecting future application execution. Similarly, methods that are only called in case of exceptions do not need to be compiled. As another example, a method that is already part of all its calling methods (e.g., a method incorporated as inline code) may not need to be compiled separately because its calling methods are already compiled. As yet another example, when preparing a snapshot of an application framework for use by other applications, some methods may need to be placed in the correct layer of the framework, and therefore methods appropriate for different layers may be removed from the method list.

[0041] When a snapshot handler is triggered at a snapshot point, the embodiment commits buffered profile data to a predetermined storage location of the JIT compiler. Committing buffered profile data at a snapshot point increases the amount of profile data available for use by the JIT compiler. For example, in an experiment performed using one embodiment, committing buffered profile data at a snapshot point doubled the amount of profile data available to the JIT compiler.

[0042] The implementation uses a JIT compiler to compile one or more methods from a method list using profile data in a predetermined storage location. One implementation compiles the code in read-only mode, making the resulting snapshot shareable across multiple process VM instances after recovery. Using as much profile data as possible to perform the compilation improves application throughput after recovery without waiting for the application to reach full performance levels before taking a snapshot. In particular, because some methods will have already run sufficiently to accumulate excellent profiles at the snapshot point, the resulting compilation will have correspondingly excellent throughput. Some methods will not have run sufficiently to accumulate excellent profiles, and the resulting compilation will have correspondingly normal throughput. However, the snapshot process is not delayed by waiting for these methods to execute sufficiently for compilation during normal operation, and these methods can always be recompiled after restoring the application from the snapshot to improve throughput. Furthermore, the overall throughput is still higher than in cases where profile information is not used at all, such as in some currently available solutions. Moreover, the overall throughput is comparable to solutions that require multiple training types of application executions without having to perform those multiple executions.

[0043] Another embodiment uses a JIT compiler to compile different optimized versions of one or more methods in the method list, thereby balancing compilation time and snapshot size for improved application throughput and reduced scalability during recovery. Yet another embodiment uses a JIT compiler to compile two different versions of methods in the method list, one normally optimized and the other compiled with debug support enabled, allowing for normal operation and debugging using a single snapshot after recovery.

[0044] Once the implementation has compiled these methods, it stores the compilation results. One implementation stores only one compilation result per method. Another implementation stores two or more different optimized versions of the methods in a snapshot, allowing different optimizations to be combined after restoration without requiring recompilation by running the application. Another implementation stores both the normal optimized compilation result and the compilation result with debug support enabled, allowing normal operation and debugging using a single snapshot after restoration. The implementation also stores additional snapshot data. Some non-limiting examples of additional snapshot data are classes loaded up to the snapshot point and the VM heap filled by loading some or all initializers of classes up to the snapshot point by running the program.

[0045] When an application is restored from a snapshot, application profiling and JIT compilation are performed against any normally executing process VM. The expectation is that the new JIT compilation is a combination of recompiling some performance-critical methods that were originally compiled during the snapshot (which can improve application throughput) and initial compilation of methods from classes loaded after restoration. As a result, the restored application does indeed achieve peak performance, with a shorter startup time than when no snapshot was used.

[0046] The implementation can also be used to generate a native image at a snapshot point while the application is running normally (i.e., without the language constraints of certain currently available solutions) and while benefiting from the profiling information already collected. The resulting native image is smaller than the restored application, but will not have the improved throughput gained by including JIT compilation for normal execution after restoration. Furthermore, every method or other unit of code executable from the snapshot point will need to be compiled, as no interpreter or JIT compiler will be present in the native image and available to generate additional executable code.

[0047] The compilation strategy for shareable application snapshots described herein is unavailable in currently available methods in the art related to snapshotting efforts within a process VM. The methods of the embodiments described herein, when implemented for execution on a device or data processing system, include substantial advancements in the functionality of that device or data processing system when performing the following actions: establishing a list of methods for the currently executing application within the process VM that can be executed after the snapshot point; submitting collected application profile data to a designated storage location; compiling the methods using the profile data and a JIT compiler; and storing snapshot data including the compiled methods.

[0048] The illustrative embodiments are described by way of example only, relating to certain types of process VMs, source code, bytecode, machine instructions, computer language constructs, method lists, profile data, prediction, thresholding, measurement, devices, data processing systems, environments, components, and applications. Any specific manifestation of these and other similar products is not intended to limit the invention. Any suitable manifestation of these and other similar products may be chosen within the scope of the illustrative embodiments.

[0049] Furthermore, illustrative embodiments can be implemented with respect to any type of data, data source, or access to a data source via a data network. Within the scope of the invention, any type of data storage device can provide data to embodiments of the invention locally within a data processing system or via a data network. Within the scope of the illustrative embodiments, where embodiments are described using mobile devices, any type of data storage device suitable for use with mobile devices can provide data to such embodiments locally within the mobile device or via a data network.

[0050] The illustrative embodiments are described using specific code, designs, architectures, protocols, layouts, diagrams, and tools as examples only, and are not limited to these illustrative embodiments. Furthermore, for clarity, specific software, tools, and data processing environments are used in some instances as examples only to describe the illustrative embodiments. The illustrative embodiments can be used in conjunction with other comparable or similar structures, systems, applications, or architectures. For example, within the scope of this invention, other equivalent mobile devices, structures, systems, applications, or architectures can be used in conjunction with such embodiments of the invention. The illustrative embodiments can be implemented in hardware, software, or a combination thereof.

[0051] The examples in this disclosure are for clarity of description only and are not limited to illustrative embodiments. Additional data, operations, actions, tasks, activities, and manipulations will arise from this disclosure and are contemplated within the scope of the illustrative embodiments.

[0052] Any advantages listed herein are merely illustrative and not intended to limit the illustrative embodiments. Additional or different advantages may be achieved through specific illustrative embodiments. Furthermore, certain illustrative embodiments may have some, all, or none of the advantages listed above.

[0053] It should be understood that while this disclosure includes a detailed description of cloud computing, the implementation of the teachings recorded herein is not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0054] Cloud computing is a service delivery model that enables 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), which can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0055] The features are as follows:

[0056] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0057] Extensive network access: Capabilities are available through networks and accessed via standard mechanisms that facilitate the use of heterogeneous thin client or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0058] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence because consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0059] Rapid flexibility: The ability to provide capacity quickly and flexibly, automatically scaling down and up rapidly in some situations to scale up rapidly. For consumers, the available supply capacity often appears unlimited and can be purchased in any quantity at any time.

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

[0061] The service model is as follows:

[0062] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from different client devices via thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with possible exceptions such as limited user-specific application configuration settings.

[0063] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created or acquired by the consumer using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environment.

[0064] Infrastructure as a Service (IaaS): The capabilities offered to consumers are processing, storage, networking, and other basic computing resources that enable consumers to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0065] The deployment model is as follows:

[0066] Private cloud: A cloud infrastructure that operates solely for an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0067] Community cloud: A cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

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

[0069] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported (e.g., cloud bursting for load balancing between clouds).

[0070] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure comprising a network of interconnected nodes.

[0071] Refer to the attached diagram and for details. Figure 1 and 2 These figures are example diagrams of a data processing environment that can implement illustrative embodiments. Figure 1 and 2 This is merely an example and is not intended to assert or imply any limitation regarding the environments in which different embodiments may be implemented. Specific implementations may be modified in many ways based on the environments depicted in the following description.

[0072] Figure 1 A block diagram of a data processing system network that can implement illustrative embodiments is shown. Data processing environment 100 is a network of computers that can implement illustrative embodiments. Data processing environment 100 includes network 102. Network 102 is a medium for providing communication links between different devices and computers connected together within data processing environment 100. Network 102 may include connections such as wired, wireless communication links, or fiber optic cables.

[0073] The client or server are merely example 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. Servers 104 and 106 are coupled to network 102 along with storage unit 108. Software applications can execute on any computer in data processing environment 100. Clients 110, 112, and 114 are also coupled to network 102. Data processing systems (such as servers 104 or 106 or clients 110, 112, or 114) can contain data and can have software applications or software tools executing on them.

[0074] This is merely an example and does not imply any limitations on such an architecture. Figure 1 Certain components available in the example implementations of the embodiments are depicted. For example, servers 104 and 106 and clients 110, 112, and 114 are depicted as servers and clients only by way of example and are not intended to imply a limitation on the client-server architecture. As another example, embodiments may be distributed across several data processing systems and data networks shown, while another embodiment may be implemented on a single data processing system within the scope of the illustrative embodiments. Data processing systems 104, 106, 110, 112, and 114 also represent example nodes in clusters, partitions, and other configurations suitable for implementing the embodiments.

[0075] Device 132 is an example of the device described herein. For example, device 132 may take the form of a smartphone, tablet computer, laptop computer, client 110 in fixed or portable form, wearable computing device, or any other suitable device. Figure 1Any software application running in another data processing system within the device can be configured to run in a similar manner in device 132. Figure 1 Any data or information stored or generated in another data processing system can be configured to be stored or generated in device 132 in a similar manner.

[0076] Application 105 implements the embodiments described herein. Application 105 is executed in any of servers 104 and 106, clients 110, 112 and 114, and device 132.

[0077] Servers 104 and 106, storage unit 108, clients 110, 112 and 114, and device 132 can be coupled to network 102 using wired connections, wireless communication protocols, or other suitable data connectivity. Clients 110, 112, and 114 can be, for example, personal computers or network computers.

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

[0079] In the depicted example, data processing environment 100 can be the Internet. Network 102 can represent a collection of networks and gateways that communicate with each other using Transmission Control Protocol / Internet Protocol (TCP / IP) and other protocols. The core of the Internet is the backbone of data communication links between master nodes or master computers (including thousands of commercial, government, educational, and other computer systems that route data and messages). Of course, data processing environment 100 can also be implemented as many different types of networks, such as, for example, intranets, local area networks (LANs), or wide area networks (WANs). Figure 1 This is intended as an example, not as an architectural limitation for different illustrative embodiments.

[0080] Among other uses, the data processing environment 100 can be used to implement a client-server environment in which illustrative embodiments can be implemented. The client-server environment enables software applications and data to be distributed across a network, allowing applications to function through interaction between client data processing systems and server data processing systems. The data processing environment 100 can also employ a service-oriented architecture, where interoperable software components distributed across a network can be encapsulated together as a consistent business application. The data processing environment 100 can also take the form of a cloud and employ a service-delivered cloud computing model 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), which can be rapidly provisioned and released with minimal management effort or interaction with service providers.

[0081] See Figure 2 The figure depicts a block diagram of a data processing system that can implement illustrative embodiments. Data processing system 200 is an example of a computer, such as... Figure 1 The servers 104 and 106 or clients 110, 112 and 114, or another type of device in which computer-usable program code or instructions for performing the process, for the purposes of the illustrative embodiments, may reside.

[0082] Data processing system 200 also refers to a data processing system or its configuration, such as Figure 1 The data processing system 132 may contain computer-usable program code or instructions for implementing the processing of the illustrative embodiments. The data processing system 200 is described as a computer by way of example only and is not limited thereto. Other devices (e.g., Figure 1 The implementation of the device 132 in the data processing system 200 can be modified, for example, by adding a touch interface and even removing certain depicted components from the data processing system 200, without departing from the general description of the operation and function of the data processing system 200 described herein.

[0083] In the depicted example, the data processing system 200 employs a central 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, main memory 208, and a graphics processor 210 are coupled to the Northbridge and Memory Controller Hub (NB / MCH) 202. The processing unit 206 may contain one or more processors and may be implemented using one or more heterogeneous processor systems. The processing unit 206 may be a multi-core processor. In some implementations, the graphics processor 210 may be coupled to the NB / MCH 202 via an Accelerated Graphics Port (AGP).

[0084] In the depicted example, a local area network (LAN) adapter 212 is coupled to the 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 a PCI / PCIe device 234 are coupled to the Southbridge and I / O controller hub 204 via 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 via bus 240. The PCI / PCIe device 234 may include, for example, an Ethernet adapter, an insert 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 can use, for example, integrated drive electronics (IDE), Serial Advanced Technology Attachment (SATA) interface, or variants such as external SATA (eSATA) and micro SATA (mSATA). Super I / O (SIO) device 236 can be coupled to the southbridge and I / O controller hub (SB / ICH) 204 via bus 238.

[0085] 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-ROMs 230, and other similar available devices are some examples of computer-usable storage devices that include computer-usable storage media.

[0086] The operating system runs on processing unit 206. The operating system coordinates and provides... Figure 2 The data processing system 200 controls various components within it. The operating system can be a commercially available operating system for any type of computing platform, including but not limited to server systems, personal computers, and mobile devices. Object-oriented or other types of programming systems can operate in conjunction with the operating system and provide calls to the operating system from programs or applications executing on the data processing system 200.

[0087] Operating systems, object-oriented programming systems, and applications or programs (such as...) Figure 1The instructions for application 105 are located on a storage device (such as in the form of code 226A on hard disk drive 226) and can be loaded into at least one of one or more memories (such as main memory 208) for execution by processing unit 206. Processing in an exemplary embodiment can be executed by processing unit 206 using computer-implemented instructions that may reside in memory, such as, for example, main memory 208, read-only memory 224, or one or more peripheral devices.

[0088] Furthermore, in one scenario, code 226A can be downloaded from a remote system 201B via network 201A, where similar code 201C is stored on storage device 201D. In another scenario, code 226A can be downloaded to a remote system 201B via network 201A, where the downloaded code 201C is stored on storage device 201D.

[0089] Figure 1-2 The hardware within can vary depending on the implementation. (Except for or replacing...) Figure 1-2 The hardware described herein can be replaced with other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disc drives. Furthermore, the processes of the illustrative embodiments can be applied to multiprocessor data processing systems.

[0090] In some illustrative examples, the 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 and / or user-generated data. The bus system may include one or more buses, such as a system bus, I / O bus, and PCI bus. Of course, the bus system can be implemented using any type of communication structure or architecture that provides data transfer between different components or devices attached to the structure or architecture.

[0091] The communication unit may include one or more means for sending and receiving data, such as a modem or network adapter. Memory may be, for example, main memory 208 or a cache, such as the cache found in the northbridge and memory controller hub 202. The processing unit may contain one or more processors or CPUs.

[0092] Figure 1-2 The examples depicted and those described above are not intended to imply architectural limitations. For example, the data processing system 200 could take the form of a tablet computer, laptop computer, or telephone device, in addition to being a mobile or wearable device.

[0093] 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 a manner that the data processing system 200 uses virtualized representations of some or all of the components depicted in the data processing system 200. For example, in a virtual machine, virtual device, or virtual component, processing unit 206 is represented as a virtualized instance of all or some of the hardware processing units 206 available in the host data processing system, main memory 208 is represented as a virtualized instance of all or some of the main memory 208 available in the host data processing system, and disk 226 is represented as a virtualized instance of all or some of the disk 226 available in the host data processing system. In this case, the host data processing system is represented by data processing system 200.

[0094] See Figure 3 This figure depicts a block diagram of an example configuration for a build strategy for shareable application snapshots according to an illustrative embodiment. Application 300 is... Figure 1 Example of application 105 and in Figure 1 It can be executed in any of the servers 104 and 106, clients 110, 112 and 114, and device 132.

[0095] Application 300 begins execution within the process VM, where the process VM is configured to prevent the compilation of any application code. Instead, existing process VM capabilities are used to interpret the application code. As the application executes within the process VM prior to a snapshot point, application 300 collects profile data for the application. This profile data is accumulated in one or more buffers. A point within the application's execution is selected as a snapshot point, and application 300 configures a snapshot handler to be triggered when the application execution reaches that snapshot point.

[0096] When a snapshot handler is triggered at a snapshot point, the method list builder module 310 constructs 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 construct the method list, module 310 consults the call stack of the application's active threads. See also... Figure 4 Additional details for module 310 are provided.

[0097] When the buffer approaches its capacity, or at predetermined time intervals, the profile data submission module 320 submits the buffered data to a predetermined storage location for use by the JIT compiler. Similarly, when a snapshot handler is triggered at a snapshot point, module 320 submits the cached profile data to a predetermined storage location for the JIT compiler. Submitting buffered profile data at snapshot points increases the amount of profile data available for use by the JIT compiler.

[0098] Compiler module 330 uses a JIT compiler to compile one or more methods in the method list using profiled data in a predetermined storage location. Another implementation of module 330 uses a JIT compiler to compile different optimized versions of one or more methods in the method list, thus balancing compilation time and snapshot size for improved application throughput and reduced scalability during recovery. Yet another implementation of module 330 uses a JIT compiler to compile two different versions of methods in the method list, one optimized normally and the other compiled with debug support enabled.

[0099] Snapshot data module 340 stores the results of compilation. One implementation of module 340 stores only one compilation result per method. Another implementation of module 340 stores two or more different optimized versions of a method in a snapshot, allowing different optimizations to be combined after restoration without requiring recompilation using application execution. Yet another implementation of module 340 stores both the compilation result with normal optimizations and the compilation result with debug support enabled, allowing normal operation and debugging using a single snapshot after restoration. Module 340 also stores additional snapshot data.

[0100] See Figure 4 The figure depicts a block diagram of an example configuration of a compilation strategy for shareable application snapshots according to an illustrative embodiment. Figure 4 Depicting Figure 3 More details on the method list builder module 310.

[0101] To construct the method list, the method adding module 410 selects the method currently being executed at the snapshot point. Module 410 adds the selected method to the method list and determines whether the selected method can call another method. If so, module 410 adds the new method to the method list and determines whether the new method can call another method itself. Module 410 continues in this manner, accumulating all methods that can be called from the currently executing method. If another method is currently being executed when the snapshot point is reached, module 410 repeats the process with that method. Furthermore, if multiple threads of the application are executing, module 410 repeats the process for another thread. Therefore, the resulting method list includes any currently executing method and any methods that the currently executing method can call in the original VM or a new instance restored from the snapshot when execution continues after the snapshot point. Module 410 maintains the method list in any currently known data structure (e.g., a static call graph).

[0102] During method list construction, or after module 410 has completed method list construction, method removal module 420 determines whether a method should be removed from the method list (or not initially added). Module 420 uses one or more criteria to determine whether a method should be filtered or removed from the method list. A non-limiting example of a criterion for determining whether a method should be removed is based on an analysis of the method's execution probability. For example, if a method will only execute if a condition is true, but that condition may never be true or has a probability of being true below a threshold, then that method does not need to be in the method list and can be removed without affecting future application performance. Similarly, methods that are only called in case of exceptions do not need to be compiled. As another example, a method that is already part of all its calling methods (e.g., a method incorporated as inline code) may not need to be compiled separately because its calling methods are already compiled. As yet another example, when preparing a snapshot of an application framework for use by other applications, some methods may need to be placed in the correct layer of the framework, so methods appropriate for different layers may be removed from the method list.

[0103] See Figure 5 This figure depicts an example of a compilation strategy for shareable application snapshots according to an illustrative embodiment. This example can be used... Figure 3 The application 300 is used to execute.

[0104] As depicted, application 510 begins execution in the process VM. As application 510 executes prior to a snapshot point, profile data 520 accumulates in profile buffer 530. When buffer 530 approaches its capacity, either at a predetermined time interval or at a snapshot point, application 300 transfers committed profile data 540 to profile data storage 550 for use by the JIT compiler.

[0105] See Figure 6 This figure depicts a further example of a compilation strategy for shareable application snapshots according to an illustrative embodiment. This example can be used... Figure 3 The application 300 is used to execute the method. Module 410 is added to the method. Figure 4 The method for adding module 410 is the same.

[0106] Source code 610 is Figure 5 The example section of application 510 is executed in source code 610. As depicted, source code 610 calls method1(), which then calls method2(). Method2() calls method3(). Method2() includes code that calls method4(), but this will never happen unless 1 is greater than 2.

[0107] Snapshot point 620 occurs while method1() within MyClass is executing. As a result, method list 630 is added to module 410. MyClass and method1() are currently executing. Because method2() will be called after method1(), method2(), as well as method3() and method4(), are also in method list 630, since they can be called by method2().

[0108] See Figure 7 This figure depicts a further example of a compilation strategy for shareable application snapshots according to an illustrative embodiment. The method removes module 420 and... Figure 4 The method for removing module 420 is the same as in method list 630. Figure 6 The method list in 630 is the same.

[0109] Here, module 420 determines that because method2() includes code that calls method4() only when 1 is greater than 2, which will never happen, method4() does not need to be compiled. Therefore, module 420 removes method4() from method list 630, resulting in method list 730.

[0110] See Figure 8 This figure depicts a further example of a compilation strategy for shareable application snapshots according to an illustrative embodiment. Compiler module 330 and... Figure 3 The compiler module 330 is the same as that in the previous version. Method list 730 is the same as... Figure 7 The method list 730 is the same. As depicted, compiler module 330 compiles each method in method list 730, resulting in compiled code 810.

[0111] See Figure 9 This figure depicts a further example of a compilation strategy for shareable application snapshots according to an illustrative embodiment. Snapshot data module 340 and... Figure 3 The snapshot data module 340 is the same as that in the application 510 and the write data storage 550. Figure 5 The application 510 and the side-write data storage 550 are the same. The compiled code 810 is... Figure 8 The compiled code 810 is the same as that in the snapshot data module 340. As depicted, the snapshot data module 340 merges the compiled code 810, the data from the write data storage 550, and the execution status data 910 of the application 510 into the snapshot data 920.

[0112] See Figure 10 This figure depicts a flowchart of an example process for a compilation strategy for shareable application snapshots according to an illustrative embodiment. Process 1000 can be... Figure 3 The application is executed in 300.

[0113] In box 1002, the application launches a process virtual machine in snapshot mode, which prevents the compilation of methods in the application within that process virtual machine. In box 1004, the application builds a list of methods for the currently executing application within the process virtual machine at the snapshot point. This list includes a set of methods that can be executed by the application after the snapshot point. In box 1006, the application commits profile data of the currently executing application, collected before reaching the snapshot point, to a specified storage location. In box 1008, the application uses the profile data and the process virtual machine's just-in-time (JIT) compiler to compile a set of methods from the method list. In box 1010, the application stores snapshot data, which includes data on the application's execution state at the snapshot point, including the results of compilation. The application then terminates.

[0114] See Figure 11 This diagram depicts a flowchart of an example process for a compilation strategy for shareable application snapshots according to an illustrative embodiment. The flowchart illustrates... Figure 10 More details on box 1004 in the image.

[0115] In box 1102, the application selects the method currently being executed by the application. In box 1104, the application adds the currently selected method to the method list. In box 1106, the application determines whether the currently selected method calls another method. If yes (the "Yes" path in box 1106), then in box 1108, the application designates the called method as the currently selected method and returns to box 1104. Otherwise (the "No" path in box 1106), in box 1110, the application determines that there is another currently executing method to process. If yes (the "Yes" path in box 1110), then in box 1112, the application designates the next method to process as the currently selected method and returns to box 1104. Otherwise (the "No" path in box 1110), in box 1114, the application filters the method list based on one or more criteria. Then the application ends.

[0116] See now Figure 12The diagram illustrates an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers can communicate. These local computing devices include, for example, personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. Nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platforms, and / or software as services for which cloud consumers do not need to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N depicted are intended to be illustrative only, and the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connectivity (e.g., using a web browser).

[0117] See now Figure 13 This demonstrates a cloud computing environment of 50 ( Figure 12 This provides a set of functional abstraction layers. It should be understood in advance that the depicted components, layers, and functions are intended to be illustrative only, and embodiments of the invention are not limited thereto. As described, the following layers and corresponding functions are provided:

[0118] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a mainframe 61; a RISC (Reduced Instruction Set Computer) based server 62; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0119] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0120] In one example, management layer 80 may provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as 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 cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources based on anticipated future needs according to the SLA.

[0121] Workload tier 90 provides examples of functionalities that can be leveraged in a cloud computing environment. Examples of workloads and functionalities that can be provided from this tier include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; transaction processing 95; and application selection based on cumulative vulnerability risk assessment 96.

[0122] Thus, in the illustrative embodiments, computer-implemented methods, systems, or apparatuses and computer program products are provided for compilation strategies that allow for sharing application snapshots and other related features, functions, or operations. When embodiments or portions thereof are described with respect to the type of apparatus, the computer-implemented methods, systems, or apparatuses, computer program products, or portions thereof are adapted or configured for use with suitable and comparable performance to that type of apparatus.

[0123] Where embodiments are described as being implemented within an application, the concept of delivering an application in a Software as a Service (SaaS) model is contemplated within the scope of the illustrative embodiments. In a SaaS model, the capabilities of an application implementing an embodiment are provided to a user by executing the application within a cloud infrastructure. Users can access the application using various client devices through thin client interfaces such as web browsers (e.g., web-based email) or other lightweight client applications. Users do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage of the cloud infrastructure. In some cases, users may not even manage or control the capabilities of the SaaS application. In some other cases, the SaaS implementation of the application may allow for limited user-specific application configuration settings that may be anomalous.

[0124] This invention can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may include a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0125] Computer-readable storage media can be a tangible means for retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

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

[0127] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, 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, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of this invention.

[0128] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should 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.

[0129] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0130] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, such that the instructions executed on the computer, other programmable apparatus, or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than indicated in the figures. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

Claims

1. A computer-implemented method for a build strategy that allows for sharing application snapshots, comprising: For the currently executing application at a snapshot point within the process virtual machine, a method list is constructed. 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 the execution state of the currently executing application when the snapshot process is triggered. Submit the profile data of the currently executing application to a specified storage location, the profile data being collected before reaching the snapshot point; The methods in the method list are compiled using the profiled data and the just-in-time compiler of the process virtual machine; as well as Store snapshot data, which includes data on the execution state of the currently executing application at the snapshot point, and includes the compilation results.

2. The computer-implemented method according to claim 1, further comprising: Before the snapshot process is triggered, compilation of the application's methods is prevented for the currently executing application.

3. The computer-implemented method according to claim 1, further comprising: The profile data is collected for the currently executing application before the snapshot process is triggered.

4. The computer-implemented method according to claim 1, wherein constructing the method list includes: Add the first method currently being executed by the currently executing application at the snapshot point to the method list; as well as In response to determining that the second method can be invoked by the first method, the second method is added to the method list.

5. The computer-implemented method according to claim 4, further comprising: In response to determining that the third method can be invoked by the second method, the third method is added to the method list.

6. The computer-implemented method according to claim 4, further comprising: In response to determining that the characteristics of a third method in the method list meet the criteria, the third method is removed from the method list.

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

8. A computer program product for a build strategy that allows for sharing application snapshots, the computer program product comprising: One or more computer-readable storage media, and program instructions commonly stored on the one or more computer-readable storage media, the program instructions comprising: Program instructions for constructing a list of methods for the currently executing application at a snapshot point within the process virtual machine, the list of methods comprising a set of methods that can be executed by the currently executing application after the snapshot point, the snapshot point comprising the execution state of the currently executing application when the snapshot process is triggered; Program instructions for submitting profile data of the currently executing application to a specified storage location, the profile data being collected before reaching the snapshot point; Program instructions for compiling the methods in the method list using the profiled data and the just-in-time compiler of the process virtual machine; and Program instructions for storing snapshot data, the snapshot data including data on the execution state of the currently executing application at the snapshot point, and the snapshot data including the compilation result.

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

10. The computer program product according to claim 8, further comprising: Program instructions for collecting profile data for the currently executing application before the snapshot process is triggered.

11. The computer program product of claim 8, wherein the list of methods for constructing the product comprises: Program instructions for adding a first method currently being executed by the currently executing application at the snapshot point to the method list; as well as A program instruction for adding the second method to the method list in response to determining that the second method can be invoked by the first method.

12. The computer program product according to claim 11, further comprising: A program instruction for adding the third method to the method list in response to determining that the third method can be invoked by the second method.

13. The computer program product according to claim 11, further comprising: A program instruction for removing a third method from the method list in response to determining that a characteristic of the third method in the method list satisfies a criterion.

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

15. The computer program product of claim 8, wherein the stored program instructions are stored in at least one of the one or more storage media of the local data processing system, and wherein the stored program instructions are transmitted from a remote data processing system via a network.

16. The computer program product of claim 8, wherein the stored program instructions are stored in at least one of the one or more storage media of the server data processing system, and wherein the stored program instructions are downloaded via 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 product of claim 8, wherein the computer program product is provided as a service in a cloud environment.

18. A computer system for a build strategy that allows for sharing application snapshots, comprising one or more processors, one or more computer-readable memories and one or more computer-readable storage devices, and 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 memories, the stored program instructions comprising: Program instructions for constructing a list of methods for the currently executing application at a snapshot point within the process virtual machine, the list of methods comprising a set of methods that can be executed by the currently executing application after the snapshot point, the snapshot point comprising the execution state of the currently executing application when the snapshot process is triggered; Program instructions for submitting profile data of the currently executing application to a specified storage location, the profile data being collected before reaching the snapshot point; Program instructions for using the profiled data and the just-in-time compiler of the process virtual machine to compile the methods in the method list; as well as Program instructions for storing snapshot data, the snapshot data including data on the execution state of the currently executing application at the snapshot point, and the snapshot data including the compilation result.

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

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

Images