Optimizing the just-in-time compilation process

Abstract

Techniques are provided for optimizing a just-in-time (JIT) compilation process. A source pod in a container orchestrated execution environment is determined to be saturated. Profile data from the JIT compiler, virtual machine state, and native compiled code state are collected. The profile data, virtual machine state, and native compiled code state are stored in data structures in a persistent data repository. In response to a restart or redeployment of the source pod and an application running on the source pod, the stored profile data, virtual machine state, and native compiled code state are reused in a new target pod without requiring monitoring and identification of hot code areas in the application after the source pod becomes saturated.

Description

[Technical Field]

[0001] The present invention relates to performance management in a container orchestrated execution environment, and more particularly to optimizing just-in-time (JIT) compilation processes in a container orchestrated execution environment. [Background technology]

[0002] Container technology and cloud platforms, such as the Kubernetes® container orchestration system, have paved the way for many software application systems to be auto-scalable, self-healing, and employ off-the-shelf load balancing. Kubernetes is a registered trademark of the Linux Foundation, San Francisco, California. Traditional software engineering techniques and technologies are improved by using out-of-the-box capabilities available to software applications deployed on cloud platforms such as the Kubernetes platform, where such capabilities include, for example, auto-scaling, high availability, self-healing, and automated rollout. Furthermore, deployment on cloud platforms makes it possible to optimize some elements of software applications (e.g., elements in Java® application and service stacks). Java is a registered trademark of Oracle America, Inc., Redwood Shores, California.

[0003] In a typical Java application, only a small subset of the code is executed frequently, and the performance of the application depends primarily on how fast sections of code in that small subset execute. These sections of code are known as hot spots or hot code. When a virtual machine runs a Java application, it does not immediately begin compiling the code. If the code in a Java application is to be executed only once, compilation is an inefficient approach. It is faster to interpret Java bytecode compared to compiling and executing the code only once. Compilation is worthwhile if the code is a frequently called method or loop that is executed many iterations. The cycles required to compile the code are outweighed by the savings from multiple executions of faster compiled code. Summary of the Invention

[0004] In one embodiment, the present invention provides a computer system comprising a central processing unit (CPU), a memory coupled to the CPU, and one or more computer-readable storage media coupled to the CPU. The one or more computer-readable storage media collectively comprise instructions executed by the CPU via the memory to implement a method for optimizing a just-in-time (JIT) compilation process. The method comprises the computer system determining that a source pod in a container orchestrated execution environment is saturated. The method further comprises the computer system collecting profile data from a JIT compiler, information about the state of a virtual machine of the source pod, and a native-compiled code state of the virtual machine in response to the source pod being determined to be saturated. The method further comprises the computer system storing the collected profile data, the collected information about the state of a virtual machine of the source pod, and the collected native-compiled code state of the virtual machine in well-defined data structures in a hierarchical manner in a persistent data repository. The method further includes a step in which, in response to restarting or redeploying the source pod and the application running on the source pod, the computer system reuses the stored profile data, stored information regarding the state of the source pod's virtual machine, and the stored native compiled code state of the virtual machine in the new target pod without requiring monitoring and identification of hot code areas in the application following saturation of the source pod.

[0005] Computer program products and methods corresponding to the computer systems summarized above are also described and claimed herein. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a block diagram of a system for optimizing a JIT compilation process in a container-orchestrated execution environment according to an embodiment of the present invention.

[0007] [Figure 2] 1 is a flowchart of a process for optimizing a JIT compilation process in a container-orchestrated execution environment according to an embodiment of the present invention.

[0008] [Figure 3] 3 is a flowchart of an optimization reuse process included in the process of FIG. 2 according to an embodiment of the present invention.

[0009] [Figure 4] 3 is a flowchart of an optimized data transport process included in the process of FIG. 2 according to an embodiment of the present invention.

[0010] [Figure 5] 2, 3, and 4 according to an embodiment of the present invention. FIG. 3 is a block diagram of a computer included in the system of FIG. 1 and implementing the processes of FIGS.

[0011] [Figure 6] FIG. 1 illustrates a cloud computing environment according to an embodiment of the present invention.

[0012] [Figure 7] FIG. 2 illustrates abstraction model layers according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] [Summary] For containerized Java applications or applications running on a polyglot runtime deployed on a cloud platform, the containers and pods hosting the application are deployed and reused multiple times over a period of time. The reasons for the multiple deployments and reuses mentioned above include rollouts, auto-scaling based on incoming load, and sudden crashes of the container or pod. When a pod is started anew, the entire application stack, including the Java Virtual Machine (JVM), starts anew. JVM is a registered trademark of Oracle America, Inc. Specialized subsystems, such as the JVM system and JIT compiler, which are part of the application stack, gather a significant amount of insight over time while the application is running. These insights are used to optimize operation. For example, a JIT compiler monitors the execution patterns of a Java application to identify hot code in the application (i.e., methods and / or loops in the application that are executed more frequently than a specified threshold amount). The JIT compiler optimizes the hot code by compiling the hot code into a native format so that the hot code areas execute faster compared to an interpreted version of the same code. Identifying hot code areas and optimizing the hot code for better performance is a continuous process. The JIT compiler and JVM® system continue to perform the above-mentioned hot spot identification and optimization tasks throughout the application's lifetime, thereby improving the application's performance over the application's lifetime. When the JVM® system and JIT compiler are shut down, either triggered by a cloud platform orchestrator or due to a pod or container crash, the insights gathered by the JIT compiler are lost.When a pod or container is restarted or redeployed, the entire stack is started from scratch, thereby requiring a time-consuming repetition of the same process of identifying and optimizing hot code.

[0014] The JIT compiler optimizes the compilation of the application's code based on running the application for a significant amount of time and monitoring execution patterns to determine hot code areas. The JIT compiler collects information for optimization by using two counters in the JVM® system: the number of times a method is called and the number of times any loop in the method takes a branch back. The branch back indicates the number of times a loop completes execution, either because the end of the loop is reached or because a branching statement is executed. When the application and the JVM® system are shut down, the information for the above optimization is lost.

[0015] Embodiments of the present invention address the unique challenges described above related to pod or container restarts or redeployments, or application shutdowns. In one embodiment, a JIT compilation optimization system maintains insights gathered by a JIT compiler about hot code in an application and other application optimization characteristics in a container orchestration system. In one embodiment, these insights are stored externally and include platform-independent aspects, along with Java heap, class loading, and native compiled code structure. When a container or pod is restarted or redeployed, the maintained insights are reused by the new instance of the container or pod, thereby avoiding time-consuming repetition of the same process of monitoring and identifying hot code areas in the application. Instead, the JIT compiler reuses the maintained insights and begins compiling the hot code areas listed in the maintained data. Because the application remains the same after a restart or redeployment, the application code execution patterns also remain the same. Reusing details about hot code areas from previous runs of an application significantly improves application performance in cloud platforms, such as the Kubernetes platform, where instance restarts are common. In response to pods and applications running on the pods restarting, embodiments of the present invention enable the JIT compiler to immediately begin compiling the hot code areas without wasting significant CPU time in repeating the steps of monitoring and identifying hot code areas and then compiling the identified hot code.

[0016] Embodiments of the present invention reuse application optimization insights across virtual machines and real machines in a cluster topology. Embodiments of the present invention employ serialization to reuse application optimization insights. In one embodiment, a JIT compilation optimization system derives optimized code and optimization-related metadata from a fully optimized source system and transports the derived code and metadata to a target system in a serialized manner. Embodiments of the present invention adjust object heap sizing for the target system based on the source system's insights.

[0017] Embodiments of the present invention coordinate multiple optimizations (e.g., class hierarchy analysis, devirtualization techniques, etc.) based on a hierarchical approach such that a particular state of the system at a given level suggests the application of optimizations relevant to levels below the given level.

[0018] Embodiments of the present invention use insights gathered from JIT compilation in a source system and employ insights in a target system in a replica set within a container-orchestrated cluster, based on the fact that the systems are identical, the workloads are identical, and most of the insights in the source system are applicable in the target system.

[0019] Embodiments of the present invention organize insights and their data capture hierarchically to provide portions of insights based on the level of affinity that a target system has to a source system.Embodiments of the present invention transport data related to insights between systems.

[0020] Embodiments of the present invention provide a newly created execution invention that optimizes performance from a saturated execution environment, where (i) the performance optimization includes, but is not limited to, dynamic compiler optimization, virtual machine state, and virtual memory characteristics; (ii) the saturation of the environment is the virtual machine state in which the application code is fully optimized; (iii) the execution environment is a distributed computing node; and (iv) the computing node is a unit of a replica set in a container orchestration system.

[0021] Embodiments of the present invention provide the above-mentioned performance optimization using a hierarchical technique, where (i) optimization opportunities are hierarchically classified, (ii) the hierarchy is defined based on the applicability of types of optimizations in heterogeneous execution environments, (iii) the applicability is determined based on a comparison of similar attributes of the execution environments, and (iv) the optimization is applied if applicability exists and discarded if applicability does not exist, which results in maximizing the application of optimizations across environments. A system for optimizing the JIT compilation process

[0022] 1 is a block diagram of a system 100 for optimizing a JIT compilation process in a container orchestration execution environment according to an embodiment of the present invention. The system 100 includes a computer 102 having a software-based compilation process optimization system 104 for optimizing a JIT compilation process. The compilation process optimization system 104 includes a cluster optimization manager (COM) 106, which coordinates the decision-making process and data flow associated with optimizing the JIT compilation process.

[0023] The system 100 includes a software-based runtime agent 108 that coordinates control decisions for the subject runtime and data flow associated with optimizing the JIT compilation process and works in conjunction with the COM 106 .

[0024] COM 106 communicates with pods 110-1, ..., pod 110-N, where N is an integer greater than or equal to 1. Pods 110-1, ..., 110-N are saturated pods. Saturated pods are also referred to herein as source pods. As used herein, a saturated pod is defined as a pod that has executed a workload for a sufficient amount of time such that the JIT compiler has optimized a portion of the pod's total number of methods, where the portion exceeds a specified threshold amount. A pod is the basic scheduling unit of a container orchestrated execution environment, contains one or more containers (e.g., Docker containers), and represents a single instance of an execution process in a cluster.

[0025] The compilation process optimization system 104 identifies pods that are saturated pods by requesting them through the compiler's application programming interface (API) or by examining the current compilation pattern. Each runtime agent 108 communicates with the underlying virtual machine (not shown) to obtain information about the state of the compiled code.

[0026] Pods 110-1, ..., 110-N store the following information in predefined data structures (not shown) in data repository 112 (i.e., persistent volumes): (1) profile data from the JIT compiler (i.e., runtime profile information of the dynamic compiler), (2) information about the state of the pod's virtual machine (i.e., the pod's execution environment), (3) the virtual machine's native compiled code state (i.e., the virtual machine's compiled code characteristics), and (4) augmented data from the information in (1), (2), and (3) listed above.

[0027] COM 106 also communicates with a new pod 114 (also referred to herein as a new target pod) that is the result of respawning one of saturated pods 110-1, ..., 110-N. The runtime system retrieves the profile data, execution environment information, and compiled code information in predefined data structures from data repository 112 and reuses that information in new pod 114 without requiring a process to identify and optimize hot code areas in new pod 114.

[0028] The COM 106 includes an alarm 116 that executes timer handler code at regular time intervals, which captures and stores information in the predefined data structures described above.

[0029] The functionality of the components shown in FIG. 1 is explained in more detail in the discussion of FIGS. 2, 3, 4, 5, 6, and 7 presented below. The process of optimizing the JIT compilation process

[0030] 2 is a flowchart of a process for optimizing a JIT compilation process in a container orchestrated execution environment according to an embodiment of the present invention. The process of FIG. 2 begins at start node 200. At stage 202, compilation process optimization system 104 (see FIG. 1) determines that a source pod (i.e., one of pods 110-1, ..., 110-N in FIG. 1) in the container orchestrated execution environment has become saturated.

[0031] In step 204, in response to determining that the source pod is saturated in step 202, the compilation process optimization system 104 (see FIG. 1) collects profile data from the JIT compiler, information about the state of the source pod's virtual machine, and the virtual machine's native compiled code state.

[0032] In one embodiment, the information about the state of the source pod's virtual machine includes information such as the size of the Java heap, the size of the compiled code heap, the loaded class loaders, and the loaded classes (i.e., the loaded state of the classes).

[0033] In one embodiment, the native compiled code state of the virtual machine includes a compiled code cache, methods and classes corresponding to the compiled code cache, and virtual address ranges into which the methods and classes are loaded. For example, the native compiled code state of the virtual machine includes the output from a UNIX system pmap command. UNIX is a registered trademark of The Open Group, Ltd., Reading, Berkshire, UK.

[0034] In step 206, the compilation process optimization system 104 (see FIG. 1) stores (i) profile data, (ii) information about the virtual machine state, and (iii) the virtual machine's native compiled code state in a persistent memory or persistent volume (i.e., data repository 112 (see FIG. 1)) in a well-defined data structure and hierarchical manner. The data structure is well-defined because it is mutable and serializable and can be reconstructed in another execution environment. The storage of (i), (ii), and (iii) listed above is done in a hierarchical manner because each set of data is used separately in a new pod based on its relevance and context. The data repository 112 (see FIG. 1) is persistent in that information is not lost when a saturated pod is recycled.

[0035] In step 208, in response to restarting or redeploying the source pod and the application running on the source pod, the compilation process optimization system 104 (see FIG. 1) reuses the profile data, information about the virtual machine state, and the virtual machine's native compiled code state in the new target pod (i.e., new pod 114 in FIG. 1) without requiring monitoring and identification of hot code areas in the application after the restart or redeployment.

[0036] The process of FIG. 2 ends at end node 210.

[0037] 3 is a flowchart of an optimization reuse process included in the process of FIG. 2 according to an embodiment of the present invention. The process of FIG. 3 begins at start node 300. In step 302, the runtime system (see FIG. 1) of compilation process optimization system 104 applies profile data of a source pod (i.e., one of pods 110-1, ..., 110-N in FIG. 1) without any changes in the new virtual machine of a new target pod (i.e., new pod 114 in FIG. 1) (i.e., a newly booted-up pod). The application of the profile data in step 302 defines a compilation plan for the method. The profile data is independent of the idiosyncrasies of any particular execution environment and platform, instead focusing only on the hotness of the method.

[0038] In step 304, the compilation process optimization system 104 (see FIG. 1) determines that the execution environment of the new target pod matches (ie, corresponds to) the execution environment of the source pod.

[0039] In step 306, in response to determining in step 304 that the execution environment of the new target pod matches the execution environment of the source pod, compilation process optimization system 104 (see FIG. 1) applies information about the virtual machine state to the new target pod's new virtual machine. For example, if the memory capacity of the new target pod is equal to or higher than the memory capacity of the source pod, compilation process optimization system 104 (see FIG. 1) specifies the Java heap as recorded in the execution environment profile data, with appropriate alignment rules applied. Similarly, if the class loaded state and class loaders for the new target pod are the same as those of the source pod, further optimizations applicable to the class hierarchy are reused from the metadata. Examples of such optimizations include class hierarchy analysis optimizations and method devirtualization optimizations.

[0040] In step 308, the compilation process optimization system 104 (see FIG. 1) determines that the state of the virtual mapping and the location of the assigned machine code in the new target pod matches (i.e., corresponds to) the state of the virtual mapping and the location of the code in the source pod (i.e., the native compiled code state of the source pod's virtual machine).

[0041] In step 310, in response to determining in step 308 that the state of the virtual mapping and the location of the assigned machine code in the new target pod match the state of the virtual mapping and the location of the code in the source pod, the compilation process optimization system 104 (see FIG. 1) stores the compiled code that resides at the location in the source pod in the same location in the new target pod. For example, if a compiled code section starts at virtual address 0x7fffffff00000000 in the source pod and the new target pod, and the compiled code for an arbitrary method Foo.foo() is stored at location 0x7fffffff10000000, then the compilation process optimization system 104 (see FIG. 1) stores the same compiled code in the same location in the new target pod and reuses the same compiled code in the new target pod as if the code was compiled in the new target pod.

[0042] The process of Figure 3 ends at end node 312. In one embodiment, the process of Figure 3 continues with steps 202, 204, and 206 in Figure 2.

[0043] Figure 4 is a flowchart of an optimized data transport process included in the process of Figure 2, according to an embodiment of the present invention. The process of Figure 4 begins at start node 400. In step 402, alarm 116 (see Figure 1) is activated at regular time intervals (i.e., compilation process optimization system 104 (see Figure 1) detects the alarm of a timer at regular time intervals). The activation of alarm 116 (see Figure 1) executes timer handler code in steps 404, 406, 408, 410, and 412, as described below.

[0044] In step 404, the compilation process optimization system 104 (see FIG. 1) captures the profile data and stores it in a profile data structure where the application's methods are the keys and the profile data are the values. If the profile data already exists, the existing profile data is updated with the new profile data.

[0045] In step 406, the compilation process optimization system 104 (see FIG. 1) captures data about the execution environment of the source pod and stores the captured data about the execution environment in an environment data structure. After the first capture of data about the execution environment, the environment data structure is updated in subsequent instances as needed. Some items may remain unchanged (e.g., loaded classes), while other items may change (e.g., managed heap).

[0046] In step 408, the compilation process optimization system 104 (see FIG. 1) captures the code compiled by the JIT compiler and the mapping of the captured code to virtual memory addresses, and stores the captured code and the mapping of the captured code to virtual memory addresses in a code data structure.

[0047] The compiled code also includes the compilation level (i.e., compilation intensity or compilation degree; e.g., cold, warm, hot, etc.) of each method of the application. The compilation process optimization system 104 (see FIG. 1) performs an aggregation over the degree of the compiled code to obtain an optimization score or optimization index for the pod at a given instance of alarm execution. If an optimization score was already obtained at a previous instance, the existing score is updated.

[0048] In step 410, the compilation process optimization system 104 (see FIG. 1) expands the data in the profile data structure, the environment data structure, and the code data structure into a single expanded structure.

[0049] In step 412, the compilation process optimization system 104 (see FIG. 1) serializes the augmented data in a single augmented data structure to the data repository 112 (see FIG. 1), along with the source pod identifiers and the optimization scores for the source pods.

[0050] The process of FIG. 4 ends at end node 414.

[0051] In one embodiment, when a new pod is spawned, cluster optimization manager 106 (see FIG. 1) iterates through the data in data repository 112 (see FIG. 1) and deserializes the data into an in-memory structure. COM 106 (see FIG. 1) iterates through the optimization scores from each record and determines the maximum score. COM 106 (see FIG. 1) separates the data elements into those within its own scope and those that need to be passed to runtime agent 108 (see FIG. 1). COM 106 (see FIG. 1) uses the extracted data to perform homogenization. For example, COM 106 (see FIG. 1) initializes the pod using memory-specific execution environment data. COM 106 (see FIG. 1) passes other data to runtime agent 108 (see FIG. 1), which uses the data to optimize runtime. Computer Systems

[0052] 5 is a block diagram of a computer included in the system of FIG. 1 and implementing the processes of FIGS. 2, 3, and 4 according to an embodiment of the present invention. Computer 102 is a computer system generally including a central processing unit (CPU) 502, memory 504, an input / output (I / O) interface 506, and a bus 508. Computer 102 is further coupled to an I / O device 510 and a computer data storage unit 512. CPU 502 performs computational and control functions of computer 102, including executing instructions included in program code 514 for compilation process optimization system 104 (see FIG. 1) to perform a method for optimizing a JIT compilation process in a container-orchestrated execution environment, where the instructions are executed by CPU 502 via memory 504. CPU 502 may include a single processing unit or processor, or may be distributed across one or more processing units or one or more processors at one or more locations (e.g., on a client and a server).

[0053] Memory 504 includes known computer-readable storage media, as described below. In one embodiment, cache memory elements of memory 504 provide temporary storage of at least some program code (e.g., program code 514) to reduce the number of times the code must be retrieved from bulk storage while instructions of the program code are being executed. Moreover, like CPU 502, memory 504, which includes one or more types of data storage, may reside in a single physical location or may be distributed across multiple physical systems or multiple computer-readable storage media in various forms. Furthermore, memory 504 may include data distributed across, for example, a local area network (LAN) or a wide area network (WAN).

[0054] I / O interface 506 includes any system for exchanging information with external resources. I / O devices 510 include any known type of external device, including a display, keyboard, etc. Bus 508 provides a communication link between each of the components in computer 102 and may include any type of transmission link, including electrical, optical, wireless, etc.

[0055] The I / O interface 506 also enables the computer 102 to store and retrieve information (e.g., data or program instructions, such as program code 514) on and from the computer data storage unit 512 or another computer data storage unit (not shown). The computer data storage unit 512 includes one or more known computer-readable storage media, where computer-readable storage media are described below. In one embodiment, the computer data storage unit 512 is a non-volatile data storage device, such as a solid-state drive (SSD), a network-attached storage (NAS) array, a storage area network (SAN) array, a magnetic disk drive (i.e., a hard disk drive), or an optical disk drive (e.g., a CD-ROM drive that receives a CD-ROM disc or a DVD drive that receives a DVD disc).

[0056] Memory 504 and / or storage unit 512 may store computer program code 514 including instructions executed by CPU 502 via memory 504 to optimize the JIT compilation process in a container-organized execution environment. While Figure 5 illustrates memory 504 as including program code, the present invention contemplates embodiments in which memory 504 does not include all of code 514 simultaneously, but instead includes only a portion of code 514 at a time.

[0057] Additionally, memory 504 may include an operating system (not shown) and may include other systems not shown in FIG.

[0058] As will be appreciated by those skilled in the art, in a first embodiment, the present invention may be a method; in a second embodiment, the present invention may be a system; and in a third embodiment, the present invention may be a computer program product.

[0059] Any of the components of an embodiment of the present invention may be deployed, managed, serviced, etc., by a service provider offering to deploy or integrate computing infrastructure for optimizing JIT compilation processes in a container-orchestrated execution environment. Accordingly, one embodiment of the present invention discloses a process for supporting a computer infrastructure, wherein the process comprises providing at least one support service for at least one of integrating, hosting, maintaining, and deploying computer-readable code (e.g., program code 514) on a computer system (e.g., computer 102) including one or more processors (e.g., CPU 502), wherein the processor executes instructions included in the code that cause the computer system to optimize JIT compilation processes in a container-orchestrated execution environment. Another embodiment discloses a process for supporting a computer infrastructure, wherein the process comprises integrating computer-readable program code into a computer system including a processor. The integrating step includes storing the program code in a computer-readable storage device of the computer system through use of the processor. The program code, when executed by the processor, implements a method for optimizing JIT compilation processes in a container-orchestrated execution environment.

[0060] While it is understood that program code 514 for optimizing the JIT compilation process in a container orchestrated execution environment may be deployed by manually loading directly onto client, server, and proxy computers (not shown) via loading a computer-readable storage medium (e.g., computer data storage unit 512), program code 514 may also be automatically or semi-automatically deployed to computer 102 by sending program code 514 to a central server or group of central servers. Program code 514 is then downloaded to client computers (e.g., computer 102) that will execute program code 514. Alternatively, program code 514 is sent directly to client computers via email. Program code 514 is then either detached to a directory on the client computer or loaded into a directory on the client computer by a button on the email that executes a program that detaches program code 514 to the directory. Another alternative is to send program code 514 directly to a directory on the client computer hard drive. In the case where a proxy server is present, the process selects the proxy server code, determines on which computer the proxy server code should be located, transmits the proxy server code, and then installs the proxy server code on the proxy computer. The program code 514 is transmitted to the proxy server, where it is then stored.

[0061] Another embodiment of the present invention provides a method for executing process steps on a subscription, advertising, and / or fee basis. That is, a service provider may offer to create, maintain, support, etc., a process that optimizes a JIT compilation process in a container-orchestrated execution environment. In this case, the service provider may create, maintain, support, etc., the computer infrastructure that executes the process steps for one or more customers. In return, the service provider may receive payments from customers under a subscription and / or fee agreement, and / or the service provider may receive payments from sales of advertising content to one or more third parties.

[0062] The present invention may be a system, method, and / or computer program product at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or media) (i.e., memory 504 and computer data storage unit 512) having computer-readable program instructions 514 for causing a processor (e.g., CPU 502) to perform aspects of the present invention.

[0063] A computer-readable storage medium may be a tangible device that can hold and store instructions (e.g., program code 514) for use by an instruction execution device (e.g., computer 102). A computer-readable storage medium may 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 of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, 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 versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves that record instructions, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as a radio 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 a wire.

[0064] The computer-readable program instructions (e.g., program code 514) described herein can be downloaded from a computer-readable storage medium to a respective computing / processing device (e.g., computer 102) or to an external computer or external storage device (e.g., computer data storage unit 512) via a network (not shown), such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card (not shown) or network interface (not shown) in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computing / processing device for storage.

[0065] The computer-readable program instructions (e.g., program code 514) that carry out the operations of the present invention can 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, including object-oriented programming languages ​​such as Smalltalk®, C++, etc., and conventional procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, as a standalone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions to personalize the electronic circuitry by utilizing state information of the computer readable program instructions to perform aspects of the present invention.

[0066] Aspects of the present invention are described herein with reference to flowchart illustrations (e.g., FIGS. 2, 3, and 4) and / or block diagrams (e.g., FIGS. 1 and 5) of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions (e.g., program code 514).

[0067] These computer-readable program instructions may be provided to a processor (e.g., CPU 502) of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus (e.g., computer 102) to produce a machine, whereby the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium (e.g., computer data storage unit 512), whereby the instructions can instruct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having the instructions stored thereon comprises an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0068] Furthermore, computer-readable program instructions (e.g., program code 514) can be loaded into a computer (e.g., computer 102), other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device implement the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0069] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implement the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be realized as a single step and executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0070] While embodiments of the present invention have been described herein for purposes of illustration, many modifications and variations will become apparent to those skilled in the art. It is therefore intended in the appended claims to cover all such modifications and variations as fall within the scope of the invention. Cloud Computing Environment

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

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

[0073] The characteristics are as follows:

[0074] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider.

[0075] Wide network access: This capability is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg, cell phones, laptops, and PDAs).

[0076] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. There is location independence in that consumers generally have no control or knowledge over the exact location of the provided resources, but may be able to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0077] Rapid Elasticity: This capacity can be rapidly and elastically provisioned, in some cases automatically, to rapidly scale out, and rapidly released to rapidly scale in. To the consumer, the capacity available for provisioning often appears unlimited, and can be purchased in any quantity at any point in time.

[0078] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a 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 utilized.

[0079] The service model is as follows:

[0080] Software as a Service (SaaS): The consumer is offered the ability 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 such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0081] Platform as a Service (PaaS): The ability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the application hosting environment configuration.

[0082] Infrastructure as a Service (IaaS): The ability offered to consumers is to provision processing, storage, network, and other basic computing resources, on which they 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 control the operating systems, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0083] The deployment model is as follows:

[0084] Private Cloud: This cloud infrastructure operates solely for an organization. It may be managed by the organization or a third party and may exist on-premise or off-premise.

[0085] Community Cloud: This cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies and compliance considerations). It may be managed by those organizations or a third party and may exist on-premises or off-premises.

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

[0087] Hybrid Cloud: This cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain distinct entities but are bound together by standard or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0088] Cloud computing environments are service-oriented with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0089] Referring now to FIG. 6 , an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 comprises one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N, may communicate. The nodes 10 may communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as a private, community, public, or hybrid cloud, or combinations thereof, as described hereinabove. This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on their local computing device. The types of computing devices 54A, 54B, 54C and 54N shown in FIG. 6 are intended to be illustrative only, and it will be understood that computing node 10 and cloud computing environment 50 may communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0090] Referring now to Figure 7, a set of functional abstraction layers provided by cloud computing environment 50 (see Figure 6) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 7 are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0091] Hardware and software layer 60 comprises 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, software components include network application server software 67 and database software 68.

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

[0093] In one example, management layer 80 may provide the 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, 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 computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides advance arrangements and procurement of cloud computing resources where future requirements are anticipated according to SLAs.

[0094] The workload tier 90 provides examples of functions for which a 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 instruction delivery 93; data analytics processing 94; transaction processing 95; and compilation process optimization 96. (Other possible items) [Item 1] 1. A computer system comprising: Central Processing Unit (CPU); a memory coupled to the CPU; and one or more computer-readable storage media coupled to the CPU; the one or more computer-readable storage media collectively containing instructions that are executed by the CPU via the memory to implement a method for optimizing a just-in-time (JIT) compilation process, the method comprising: determining, by the computer system, that a source pod in a container orchestrated execution environment has become saturated; In response to the source pod being determined to be saturated, the computer system collects profile data from a JIT compiler, information about a virtual machine state of the source pod, and a native compiled code state of the virtual machine; the computer system storing the collected profile data, the collected information about the state of the virtual machines of the source pods, and the collected native compiled code state of the virtual machines in well-defined data structures in a hierarchical manner in a persistent data repository; and and in response to restarting or redeploying the source pod and the application running on the source pod, the computer system reusing the stored profile data, the stored information regarding the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in a new target pod without requiring monitoring and identification of hot code areas in the application following saturation of the source pod. 2. A computer system comprising: [Item 2] The step of collecting the information about the state of the virtual machine comprises: the computer system collecting the size of the Java heap, the size of the compiled code heap, and the loaded state of classes and class loaders; Item 1. The computer system of item 1, comprising: [Item 3] The step of collecting the native compiled code state of the virtual machine comprises: The computer system collects a compiled code cache, methods and classes corresponding to the compiled code cache, and virtual address ranges into which the collected methods and classes are loaded. Item 1. The computer system of item 1, comprising: [Item 4] reusing the stored profile data, the stored information about the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in the new target pod, applying the stored profile data without modification to a new virtual machine in the new target pod by the computer system; the computer system determining that the execution environment of the new target pod matches the execution environment of the source pod; in response to determining that the execution environment of the new target pod matches the execution environment of the source pod, the computer system applies the information regarding the state of the virtual machine to the new virtual machine in the new target pod; determining by the computer system that the state of virtual address mappings and assigned machine code locations in the new target pod matches the native compiled code state of the virtual machine of the source pod; and and in response to determining that the state of the virtual address mapping and the location of the assigned machine code in the new target pod match the native compiled code state of the virtual machine in the source pod, the computer system stores, in the same location in the new target pod, the compiled code that resided in the location in the source pod. Item 1. The computer system of item 1, comprising: [Item 5] The method comprises: the computer system detecting an alarm at regular time intervals; and said computer system executing timer handler code in response to said detecting said alarm step. and the performing step further comprises: capturing the profile data and storing the profile data in a profile data structure having the application's methods as keys and the profile data as values; capturing data about an execution environment of the source pod and storing the data about the execution environment in an environment data structure; capturing code compiled by the JIT compiler and a mapping of the captured code to virtual memory addresses, and storing the captured code and the mapping of the captured code to virtual memory addresses in a code data structure; and expanding the data in the profile data structure, the environment data structure, and the code data structure into a single expanded data structure. Item 1. The computer system of item 1, comprising: [Item 6] The step of executing a timer handler method includes: serializing the augmented data in the single augmented data structure to the persistent data repository along with an identifier for the source pod and an optimization score for the source pod. Item 6. The computer system of item 5, further comprising: [Item 7] The method comprises: the computer system determining a compilation level of each method in the application at the time of the detected alarm. Further comprising: a given compilation level of a given method indicates how frequently the given method is executed; The step of executing the timer handler code comprises: capturing the compilation level and storing the compilation level in the persistent data repository; and calculating the optimization score for the source pod by aggregating the compilation levels; Item 7. The computer system of item 6, further comprising: [Item 8] 1. A computer program product for optimizing a just-in-time (JIT) compilation process, the computer program product comprising: One or more computer readable storage media having computer readable program code collectively stored on said one or more computer readable storage media the computer-readable program code is executed by a central processing unit (CPU) of the computer system to cause the computer system to perform a method, the method comprising: the computer system determining that a source pod in a container orchestrated execution environment has become saturated; responsive to the source pod being determined to be saturated, the computer system collecting profile data from a JIT compiler, information about the state of a virtual machine of the source pod, and a native compiled code state of the virtual machine; the computer system storing the collected profile data, the collected information about the state of the virtual machines of the source pods, and the collected native compiled code state of the virtual machines in well-defined data structures in a hierarchical manner in a persistent data repository; and and in response to restarting or redeploying the source pod and the application running on the source pod, the computer system reuses the stored profile data, the stored information regarding the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in a new target pod without requiring monitoring and identification of hot code areas in the application following saturation of the source pod. a computer program product, [Item 9] The step of collecting the information about the state of the virtual machine includes: The computer system collects the size of the Java heap, the size of the compiled code heap, and the loaded state of classes and class loaders. Item 9. The computer program product of item 8, comprising: [Item 10] The step of collecting the native compiled code state of the virtual machine comprises: The computer system collects a compiled code cache, methods and classes corresponding to the compiled code cache, and virtual address ranges into which the collected methods and classes are loaded. Item 9. The computer program product of item 8, comprising: [Item 11] The step of reusing the stored profile data, the stored information about the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in the new target pod comprises: the computer system applying the stored profile data without modification in a new virtual machine of the new target pod; the computer system determining that the execution environment of the new target pod matches the execution environment of the source pod; in response to determining that the execution environment of the new target pod matches the execution environment of the source pod, the computer system applies the information regarding the state of the virtual machine to the new virtual machine in the new target pod; the computer system determining that the state of virtual address mappings and assigned machine code locations in the new target pod match the native compiled code state of the virtual machine of the source pod; and In response to determining that the state of the virtual address mapping and the location of the assigned machine code in the new target pod match the native compiled code state of the virtual machine in the source pod, the computer system stores the compiled code that resided at a location in the source pod in the same location in the new target pod. Item 9. The computer program product of item 8, comprising: [Item 12] The method comprises: the computer system detecting an alarm at regular time intervals; and said computer system executing timer handler code in response to said detecting said alarm; The method further includes the steps of: capturing the profile data and storing the profile data in a profile data structure having the application's methods as keys and the profile data as values; capturing data about an execution environment of the source pod and storing the data about the execution environment in an environment data structure; capturing code compiled by the JIT compiler and a mapping of the captured code to virtual memory addresses, and storing the captured code and the mapping of the captured code to virtual memory addresses in a code data structure; and expanding the data in the profile data structure, the environment data structure, and the code data structure into a single expanded data structure. Item 9. The computer program product of item 8, comprising: [Item 13] The step of executing the timer handler method includes: serializing the augmented data in the single augmented data structure to the persistent data repository along with an identifier for the source pod and an optimization score for the source pod. Item 13. The computer program product of item 12, further comprising: [Item 14] The method comprises: the computer system determining the compilation level of each method in the application at the time of the detected alarm; Further comprising: a given compilation level of a given method indicates how frequently the given method is executed; The step of executing the timer handler code comprises: capturing the compilation level and storing the compilation level in the persistent data repository; and calculating the optimization score for the source pod by aggregating the compilation levels; Item 14. The computer program product of item 13, further comprising: [Item 15] 1. A computer-implemented method comprising: determining, by one or more processors, that a source pod in the container orchestrated execution environment is saturated; collecting, by the one or more processors, profile data from a JIT compiler, information about a state of a virtual machine of the source pod, and a native compiled code state of the virtual machine in response to the source pod being determined to be saturated; storing, by the one or more processors, the collected profile data, the collected information about the state of the virtual machines of the source pods, and the collected native compiled code state of the virtual machines in well-defined data structures in a hierarchical manner in a persistent data repository; and and reusing, by the one or more processors, the stored profile data, the stored information regarding the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in a new target pod in response to restarting or redeploying the source pod and the application running on the source pod, without requiring monitoring and identification of hot code areas in the application following saturation of the source pod. A method comprising: [Item 16] The step of collecting the information about the state of the virtual machine comprises: collecting, by the one or more processors, the size of the Java heap, the size of the compiled code heap, and the loaded state of classes and class loaders. Item 16. The method according to Item 15, comprising: [Item 17] The step of collecting the native compiled code state of the virtual machine comprises: collecting, by the one or more processors, a compiled code cache, methods and classes corresponding to the compiled code cache, and virtual address ranges into which the collected methods and classes are loaded. Item 16. The method according to Item 15, comprising: [Item 18] reusing the stored profile data, the stored information about the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in the new target pod, applying, by the one or more processors, the stored profile data without modification in a new virtual machine of the new target pod; determining, by the one or more processors, that an execution environment of the new target pod matches an execution environment of the source pod; applying, by the one or more processors, the information regarding the state of the virtual machine to the new virtual machine in the new target pod in response to determining that the execution environment of the new target pod matches the execution environment of the source pod; determining, by the one or more processors, that the state of virtual address mappings and the locations of assigned machine code in the new target pod match the native compiled code state of the virtual machine of the source pod; and storing, by the one or more processors, compiled code residing at a location in the source pod in the same location in the new target pod in response to determining that the state of the virtual address mapping and the location of the assigned machine code in the new target pod match the native compiled code state of the virtual machine in the source pod. Item 16. The method according to Item 15, comprising: [Item 19] The method comprises: detecting, by the one or more processors, an alarm at regular time intervals; and executing, by the one or more processors, timer handler code in response to detecting the alarm. and the performing step further comprises: capturing the profile data and storing the profile data in a profile data structure having the application's methods as keys and the profile data as values; capturing data about an execution environment of the source pod and storing the data about the execution environment in an environment data structure; capturing code compiled by the JIT compiler and a mapping of the captured code to virtual memory addresses, and storing the captured code and the mapping of the captured code to virtual memory addresses in a code data structure; and expanding the data in the profile data structure, the environment data structure, and the code data structure into a single expanded data structure. Item 16. The method of item 15, comprising: [Item 20] The step of executing a timer handler method includes: serializing the augmented data in the single augmented data structure to the persistent data repository along with an identifier for the source pod and an optimization score for the source pod. 20. The method of claim 19, further comprising:

Claims

1. 1. A computer system comprising: Central Processing Unit (CPU); a memory coupled to the CPU; and one or more computer-readable storage media coupled to the CPU; the one or more computer-readable storage media collectively containing instructions that are executed by the CPU via the memory to implement a method for optimizing a just-in-time (JIT) compilation process, the method comprising: determining, by the computer system, that a source pod in a container orchestrated execution environment has become saturated; In response to the source pod being determined to be saturated, the computer system collects profile data from a JIT compiler, information about the state of a virtual machine of the source pod, and a native compiled code state of the virtual machine; the computer system storing the collected profile data, the collected information about the state of the virtual machines of the source pods, and the collected native compiled code state of the virtual machines in well-defined data structures in a hierarchical manner in a persistent data repository; and and in response to restarting or redeploying the source pod and the application running on the source pod, the computer system reusing the stored profile data, the stored information regarding the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in a new target pod without requiring monitoring and identification of hot code areas in the application following saturation of the source pod.

2. A computer system comprising:

2. The step of collecting the information about the state of the virtual machine comprises: the computer system collecting the size of the Java heap, the size of the compiled code heap, and the loaded state of classes and class loaders.

10. The computer system of claim 1, comprising:

3. The step of collecting the native compiled code state of the virtual machine comprises: The computer system collects a compiled code cache, methods and classes corresponding to the compiled code cache, and virtual address ranges into which the collected methods and classes are loaded.

10. The computer system of claim 1, comprising:

4. reusing the stored profile data, the stored information about the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in the new target pod, applying the stored profile data without modification to a new virtual machine in the new target pod by the computer system; the computer system determining that the execution environment of the new target pod matches the execution environment of the source pod; in response to determining that the execution environment of the new target pod matches the execution environment of the source pod, the computer system applies the information regarding the state of the virtual machine to the new virtual machine of the new target pod; determining by the computer system that the state of virtual address mappings and the locations of assigned machine code in the new target pod matches the native compiled code state of the virtual machine of the source pod; and and in response to determining that the state of the virtual address mapping and the location of the assigned machine code in the new target pod match the native compiled code state of the virtual machine in the source pod, the computer system stores, in the same location in the new target pod, the compiled code that resided in the location in the source pod.

10. The computer system of claim 1, comprising:

5. The method comprises: the computer system detecting an alarm at regular time intervals; and said computer system executing timer handler code in response to said detecting said alarm step. and the performing step further comprises: capturing the profile data and storing the profile data in a profile data structure having the application's methods as keys and the profile data as values; capturing data about an execution environment of the source pod and storing the data about the execution environment in an environment data structure; capturing code compiled by the JIT compiler and a mapping of the captured code to virtual memory addresses, and storing the captured code and the mapping of the captured code to the virtual memory addresses in a code data structure; and expanding the data in the profile data structure, the environment data structure, and the code data structure into a single expanded data structure.

5. A computer system according to claim 1, comprising:

6. The step of executing a timer handler method includes: serializing the augmented data in the single augmented data structure to the persistent data repository along with an identifier for the source pod and an optimization score for the source pod. The computer system of claim 5 further comprising:

7. The method comprises: the computer system determining a compilation level of each method in the application at the time of the detected alarm. Further comprising: a given compilation level of a given method indicates how frequently the given method is executed; The step of executing the timer handler code comprises: capturing the compilation level and storing the compilation level in the persistent data repository; and calculating the optimization score for the source pod by aggregating the compilation levels; The computer system of claim 6 further comprising:

8. 1. A computer program for optimizing a just-in-time (JIT) compilation process, the computer program comprising: comprising computer readable program code; The computer readable program code, when executed by a central processing unit (CPU) of a computer system, causes the computer system to: the computer system determining that a source pod in a container orchestrated execution environment has become saturated; In response to the source pod being determined to be saturated, the computer system collects profile data from a JIT compiler, information about the state of a virtual machine of the source pod, and a native compiled code state of the virtual machine; the computer system storing the collected profile data, the collected information about the state of the virtual machines of the source pods, and the collected native compiled code state of the virtual machines in well-defined data structures in a hierarchical manner in a persistent data repository; and and in response to restarting or redeploying the source pod and the application running on the source pod, the computer system reuses the stored profile data, the stored information regarding the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in a new target pod without requiring monitoring and identification of hot code areas in the application following saturation of the source pod. A computer program for causing a computer to carry out a method comprising:

9. The step of collecting the information about the state of the virtual machine includes: The computer system collects the size of the Java heap, the size of the compiled code heap, and the loaded state of classes and class loaders.

9. The computer program of claim 8, comprising:

10. The step of collecting the native compiled code state of the virtual machine comprises: The computer system collects a compiled code cache, methods and classes corresponding to the compiled code cache, and virtual address ranges into which the collected methods and classes are loaded.

9. The computer program of claim 8, comprising:

11. The step of reusing the stored profile data, the stored information about the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in the new target pod comprises: the computer system applying the stored profile data without modification to a new virtual machine in the new target pod; the computer system determining that the execution environment of the new target pod matches the execution environment of the source pod; in response to determining that the execution environment of the new target pod matches the execution environment of the source pod, the computer system applies the information regarding the state of the virtual machine to the new virtual machine in the new target pod; the computer system determining that the state of virtual address mappings and assigned machine code locations in the new target pod match the native compiled code state of the virtual machine of the source pod; and In response to determining that the state of the virtual address mapping and the location of the assigned machine code in the new target pod match the native compiled code state of the virtual machine in the source pod, the computer system stores the compiled code that resided at a location in the source pod in the same location in the new target pod.

9. The computer program of claim 8, comprising:

12. The method comprises: the computer system detecting an alarm at regular time intervals; and said computer system executing timer handler code in response to said detecting said alarm; The method further includes the steps of: capturing the profile data and storing the profile data in a profile data structure having the application's methods as keys and the profile data as values; capturing data about an execution environment of the source pod and storing the data about the execution environment in an environment data structure; capturing code compiled by the JIT compiler and a mapping of the captured code to virtual memory addresses, and storing the captured code and the mapping of the captured code to virtual memory addresses in a code data structure; and expanding the data in the profile data structure, the environment data structure, and the code data structure into a single expanded data structure.

12. A computer program according to any one of claims 8 to 11, comprising:

13. The step of executing the timer handler method includes: serializing the augmented data in the single augmented data structure to the persistent data repository along with an identifier for the source pod and an optimization score for the source pod. The computer program of claim 12 further comprising:

14. The method comprises: the computer system determining the compilation level of each method in the application at the time of the detected alarm; Further comprising: a given compilation level of a given method indicates how frequently the given method is executed; The step of executing the timer handler code comprises: capturing the compilation level and storing the compilation level in the persistent data repository; and calculating the optimization score for the source pod by aggregating the compilation levels; The computer program of claim 13 further comprising:

15. 1. A computer-implemented method comprising: determining, by one or more processors, that a source pod in a container orchestrated execution environment is saturated; collecting, by the one or more processors, profile data from a JIT compiler, information about a state of a virtual machine of the source pod, and a native compiled code state of the virtual machine in response to the source pod being determined to be saturated; storing, by the one or more processors, the collected profile data, the collected information about the state of the virtual machines of the source pods, and the collected native compiled code state of the virtual machines in well-defined data structures in a hierarchical manner in a persistent data repository; and and reusing, by the one or more processors, the stored profile data, the stored information regarding the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in a new target pod in response to restarting or redeploying the source pod and the application running on the source pod, without requiring monitoring and identification of hot code areas in the application following saturation of the source pod. A method comprising:

16. The step of collecting the information about the state of the virtual machine comprises: collecting, by the one or more processors, the size of the Java heap, the size of the compiled code heap, and the loaded state of classes and class loaders.

16. The method of claim 15, comprising:

17. The step of collecting the native compiled code state of the virtual machine comprises: collecting, by the one or more processors, a compiled code cache, methods and classes corresponding to the compiled code cache, and virtual address ranges into which the collected methods and classes are loaded.

16. The method of claim 15, comprising:

18. reusing the stored profile data, the stored information about the state of the virtual machine of the source pod, and the stored native compiled code state of the virtual machine in the new target pod, applying, by the one or more processors, the stored profile data without modification in a new virtual machine of the new target pod; determining, by the one or more processors, that an execution environment of the new target pod matches an execution environment of the source pod; applying, by the one or more processors, the information regarding the state of the virtual machine to the new virtual machine in the new target pod in response to determining that the execution environment of the new target pod matches the execution environment of the source pod; determining, by the one or more processors, that the state of virtual address mappings and the locations of assigned machine code in the new target pod match the native compiled code state of the virtual machine of the source pod; and storing, by the one or more processors, compiled code residing at a location in the source pod in the same location in the new target pod in response to determining that the state of the virtual address mapping and the location of the assigned machine code in the new target pod match the native compiled code state of the virtual machine in the source pod.

16. The method of claim 15, comprising:

19. The method comprises: detecting, by the one or more processors, an alarm at regular time intervals; and executing, by said one or more processors, timer handler code in response to said detecting said alarm. and the performing step further comprises: capturing the profile data and storing the profile data in a profile data structure having the application's methods as keys and the profile data as values; capturing data about an execution environment of the source pod and storing the data about the execution environment in an environment data structure; capturing code compiled by the JIT compiler and a mapping of the captured code to virtual memory addresses, and storing the captured code and the mapping of the captured code to the virtual memory addresses in a code data structure; and expanding the data in the profile data structure, the environment data structure, and the code data structure into a single expanded data structure.

19. The method of any one of claims 15 to 18, comprising:

20. The step of executing a timer handler method includes: serializing the augmented data in the single augmented data structure to the persistent data repository along with an identifier for the source pod and an optimization score for the source pod.

20. The method of claim 19 further comprising:

Images