Sharing cached category data in a containerized environment

Abstract

A class shared orchestrator (CSO) operates as a subsystem of a container orchestrator. The CSO manages sharing of class data among containerized applications to improve startup performance, CPU consumption, and memory footprint. The CSO stores application class data in a shared class cache (SCC). The CSO provides a compatible SCC to each deployed application running within the CSO's purview. The CSO collects SCC data from running applications and processes the data offline to continuously improve the quality of the SCC provided to each deployment with minimal impact on the running applications. The CSO combines updates from running applications of a given type to generate an improved quality SCC for use by newly started applications of the same type. The CSO includes an SCC update mechanism that optimizes the size and network traffic associated with SCC data exchange and guarantees that SCC quality improves over time.

Description

Technical Field

[0001] This invention relates generally to the field of large-scale computing, and more specifically to a “platform as a service” computing environment with multiple isolated user spaces (sometimes referred to as “containers”). Background Technology

[0002] In a Platform as a Service (PaaS) computing environment, virtualization implemented at the operating system level is used to isolate user spaces from each other.

[0003] In some dynamic language computing environments, applications perform just-in-time (JIT) compilation at runtime, loading class files containing read-only class data and ahead-of-time (AOT) compiled code to be run on demand. Some systems use caching mechanisms where, at application startup, the required classes are quickly loaded from a memory-mapped file (a shared class cache residing in RAM), while the JIT compilation quickly loads the cached AOT compilation body. Summary of the Invention

[0004] According to one aspect of the invention, there exists a method, computer program product, and / or system for sharing class data in a cache, which performs the following operations (not necessarily in the following order): (i) initiating the startup of a managed runtime application in a container of a containerized environment; (ii) receiving information about the managed runtime application, including an application image identifier, arguments associated with the managed runtime application, and a worker node identifier corresponding to a worker node associated with the managed runtime application; (iii) locating a first shared class cache (using the combination of the application image identifier and arguments as keys) in a central SCC repository managed by a server. (iv) In response to locating the first SCC: (a) sending the first SCC to the client associated with the worker node, and (b) storing the first SCC in a local SCC repository; (v) receiving from the client a first update request associated with the type of the managed runtime application, the first update request including an application image identifier, parameters, information about the worker node, additional class data, pre-compiled data, and execution data about the first SCC generated and accumulated over time; (vi) determining to accept the first update request; and (vii) In response to accepting the first update request: (a) analyzing multiple update requests, including the first update request, to create analyzed update request data, (b) determining based on the analyzed update request data that the analyzed update request data includes new data common to one or more of the multiple update requests, and (c) modifying the first SCC based on the new data to generate a second SCC.

[0005] According to another aspect of the invention, there exists a method, computer program product, and / or system for sharing class data in a cache, which performs the following operations (not necessarily in the following order): (i) initiating the startup of a managed runtime application in a containerized environment; (ii) receiving information about the managed runtime application, including an application image identifier, parameters associated with the managed runtime application, and a worker node identifier corresponding to a worker node associated with the managed runtime application; (iii) locating a first shared class cache (SCC) in a central SCC repository managed by a server, with the combination of the application image identifier and parameters as the key; and (iv) responding to For locating the first SCC: (a) sending the first SCC to the client associated with the worker node, and (b) storing the first SCC in a local SCC repository; (v) receiving from the client a first update request originating from a managed runtime application and associated with the first SCC, wherein the first update request is associated with the type of the managed runtime application, including an application image identifier, parameters, information about the worker node, additional class data, ahead-compiled data, and execution data about the first SCC being generated and accumulated over time; (vi) determining to reject the first update request; and (vii) in response to rejecting the first update request, sending a second SCC to the client. Attached Figure Description

[0006] Figure 1 A cloud computing environment according to an embodiment of the present invention is shown;

[0007] Figure 2 An abstract model layer according to an embodiment of the present invention is shown;

[0008] Figure 3 This is a block diagram of a system according to at least one embodiment of the present invention;

[0009] Figure 4 This is a flowchart illustrating a method performed at least partially according to at least one embodiment of the present invention;

[0010] Figure 5 It is a block diagram illustrating the machine logic (e.g., software) portion of a system according to at least one embodiment of the present invention;

[0011] Figure 6 This is a block diagram illustrating some components of a system according to at least one embodiment of the present invention; and

[0012] Figure 7 This is a block diagram illustrating the information flow between various system components according to at least one embodiment of the present invention. Detailed Implementation

[0013] According to some embodiments of the present invention, the container orchestrator includes a class-sharing orchestrator (CSO) subsystem. The CSO manages the sharing of class data among containerized applications in a cloud environment to improve application startup performance, CPU consumption, and memory footprint. A shared class cache allows multiple virtual machines operating in isolation from each other to share a single cache, referred to herein as a "shared class cache" (SCC) that holds application class data. The class cache, configured as a memory-mapped file, stores three pieces of information: (1) the immutable parts of the class, (2) the Ahead-of-Time (AOT) compiled code, and (3) profiling data.

[0014] This detailed implementation section is divided into the following subsections: (i) hardware and software environment; (ii) example embodiments; (iii) further comments and / or embodiments; and (iv) definitions.

[0015] I. Hardware and Software Environment

[0016] 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.

[0017] Computer-readable storage media can be 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 punched 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.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] These computer-readable program instructions may be provided to a processor of a 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 the blocks of the flowchart and / or block diagram.

[0022] 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 the flowcharts and / or block diagrams.

[0023] 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, two blocks shown consecutively may actually be completed as a single step, executed substantially simultaneously, with partial or complete temporal overlap, or the blocks may sometimes be executed in reverse order, depending on the functions involved. 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, may 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.

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

[0025] 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.

[0026] The features are as follows:

[0027] 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.

[0028] 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).

[0029] 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).

[0030] 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.

[0031] 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.

[0032] The service model is as follows:

[0033] 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.

[0034] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created by the consumer or acquired 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.

[0035] 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).

[0036] The deployment model is as follows:

[0037] 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.

[0038] 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.

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

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

[0041] 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.

[0042] See now Figure 1 The diagram illustrates an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to 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. The 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 that cloud consumers do not need to maintain on their local computing devices. It should be understood that... Figure 1 The types of computing devices 54A-N shown are intended to be illustrative only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0043] See now Figure 2 This demonstrates the 50 (cloud computing environment) Figure 1 This provides a set of functional abstractions. It should be understood beforehand. Figure 2 The components, layers, and functions shown 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:

[0044] 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.

[0045] 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; virtual client 75; and class shared orchestrator 76.

[0046] 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.

[0047] Workload layer 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 layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; and transaction processing 95.

[0048] Embodiments of possible hardware and software environments for the software and / or methods according to the present invention will now be described in detail with reference to the accompanying drawings. Figure 3This is a functional block diagram showing the various parts of a networked computer system 100, including: a container orchestrator subsystem 102; a client computer subsystem 104; a communication network 114; a server computer 200; a communication unit 202; a processor group 204; an input / output (I / O) interface group 206; a memory 208; persistent storage 210; a display device 212; an external device 214; random access memory (RAM 230); a cache 232; and a container orchestrator program 300.

[0049] The container orchestrator subsystem 102 represents, in many respects, different computer subsystems of the present invention. Therefore, several parts of the container orchestrator subsystem 102 will now be discussed in the following paragraphs.

[0050] The container orchestrator subsystem 102 can be a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, personal digital assistant (PDA), smartphone, or any programmable electronic device capable of communicating with the client subsystem via the communication network 114. The container orchestrator program 300 is a collection of machine-readable instructions and / or data for creating, managing, and controlling certain software functions, which will be discussed in detail below in the exemplary embodiments subsection of the detailed implementation section.

[0051] The container orchestrator subsystem 102 is capable of communicating with other computer subsystems via a communication network 114. The communication network 114 can be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of both, and can include wired, wireless, or fiber optic connections. Generally, the communication network 114 can be any combination of connections and protocols that support communication between the server subsystem and the client subsystem.

[0052] The container orchestrator subsystem 102 is shown as a block diagram with numerous double arrows. These double arrows (without individual reference numerals) represent a communication structure that provides communication between the various components of the container orchestrator subsystem 102. This communication structure can be implemented using any architecture designed to transfer data and / or control information between processors (such as microprocessors, communication and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, the communication structure can be implemented at least partially using one or more buses.

[0053] Memory 208 and persistent storage 210 are computer-readable storage media. Typically, memory 208 may include any suitable volatile or non-volatile computer-readable storage media. It should also be noted that now and / or in the near future: (i) external device 214 may be able to provide some or all of the memory for container orchestrator subsystem 102; and / or (ii) devices external to container orchestrator subsystem 102 may be able to provide memory for container orchestrator subsystem 102.

[0054] The container orchestrator program 300 is stored in persistent storage 210 for access and / or execution by one or more corresponding computer processor groups 204, typically via one or more memories of memory 208. Persistent storage 210: (i) is at least more durable than a signal in transit; (ii) stores a program (including its soft logic and / or data) on a tangible medium (such as a magnetic or optical domain); and (iii) is significantly less durable than permanent storage. Alternatively, data storage may be more durable and / or more perpetual than the type of storage provided by persistent storage 210.

[0055] The container orchestrator program 300 may include machine-readable and executable instructions and / or substantial data (i.e., the type of data stored in the database). In this particular embodiment, persistent storage 210 includes a magnetic hard disk drive. To name some possible variations, persistent storage 210 may include a solid-state hard disk drive, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0056] The media used in persistent storage 210 can also be removable. For example, a removable hard disk drive can be used for persistent storage 210. Other examples include optical discs and disks, thumb drives and smart cards, which are inserted into the drive to be transferred to another computer-readable storage medium that is also part of persistent storage 210.

[0057] In these examples, communication unit 202 provides communication with other data processing systems or devices outside of container orchestrator subsystem 102. In these examples, communication unit 202 includes one or more network interface cards. Communication unit 202 can provide communication using either or both physical and wireless communication links. Any software modules discussed herein can be downloaded to persistent storage devices (such as persistent storage 210) via a communication unit (such as communication unit 202).

[0058] I / O interface group 206 allows data input and output to other devices that can be locally connected to server computer 200 in data communication. For example, I / O interface group 206 provides connectivity to external device 214. External device 214 may include devices such as keyboards, keypads, touchscreens, and / or other suitable input devices. External device 214 may also include portable computer-readable storage media, such as thumb drives, portable optical discs or disks, and memory cards. Software and data used to implement embodiments of the invention (e.g., container orchestrator program 300) may be stored on such portable computer-readable storage media. In these embodiments, the associated software may (or may not) be loaded, wholly or partially, onto persistent storage 210 via I / O interface group 206. I / O interface group 206 also has a data communication connection with display device 212.

[0059] Display device 212 provides a mechanism for displaying data to a user and may be, for example, a computer monitor or a smartphone display screen.

[0060] The procedures described herein are identified based on their implementation in specific embodiments of the invention. However, it should be understood that any particular procedural terminology used herein is for convenience only, and therefore the invention should not be limited to any particular application identified and / or implied by such terminology.

[0061] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements to technologies found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0062] ii. Example Implementation

[0063] Figure 4 A flowchart 250 of the method according to the present invention is shown. Figure 5 A container orchestrator program 300 is shown for performing at least some of the methodological operations of flowchart 250. This will now be extensively referenced within the procedures described in the following paragraphs. Figure 4 (For the method operation box) and Figure 5 (Regarding the software framework) Discuss the method and associated software. This can be... Figure 5 The container orchestrator program 300 is stored in a physical location in persistent storage 210 (see [link]). Figure 3 ).

[0064] Processing begins at operation S255, where the container orchestrator program 300 initiates the startup of the management runtime application in the first container of the containerized environment. The class-shared orchestrator module (CSO module 310) of the container orchestrator program 300 receives information about the managed runtime application, including the application image identifier, the parameter list passed to the first instance of the managed runtime application, and the worker node identifier corresponding to the worker node of the first instance of the managed runtime application.

[0065] Processing continues in operation S260, where the shared class cache module 312 of the container orchestrator program 300 searches the central SCC store for a shared class cache (SCC) suitable for use by the managed runtime application. Suitability is based on certain attributes associated with the managed runtime application. These attributes may include an identifier associated with the application image, one or more parameters associated with the application's startup or operation, and / or an identifier associated with the first container.

[0066] Processing continues in operation S265, wherein the cache shared orchestrator client submodule (CSO client submodule 316) of the CSO module 310 of the container orchestrator program 300 stores the shared class cache locally to the managed runtime application, i.e., in the first container.

[0067] Processing continues in operation S270, where the CSO central server submodule 314 receives update requests from the CSO client submodule 316 (corresponding to the managed runtime application, or any other application running inside or outside the first container).

[0068] Processing continues to decision S275, where the CSO central server submodule 314 determines, in response to operation S270, whether to accept or reject the received update request. If the CSO central server submodule 314 determines to reject the update request (decision S275, "reject" branch), processing continues at operation S280, where the CSO central server submodule 314 sends a second shared class cache to the requester (in this case, the CSO client submodule 316) for use by the managed runtime application.

[0069] If the CSO central server submodule 314 determines to accept the update request (decision S275, "accept" branch), then processing continues in operation S285, where the CSO central server submodule 314 stores the update request together with any other requests that have been previously received and stored (if any).

[0070] Once the threshold number of requests has accumulated (or any other triggering event has occurred), CSO central server submodule 314 analyzes the accumulated update requests. Figure 4In this embodiment, the CSO central server submodule 314 determines that two or more update requests share at least some common data. Note: In some embodiments, multiple update requests associated with the same application type are analyzed together.

[0071] Processing continues in operation S290, where the CSO central server submodule 314, in response to determining that two or more update requests share common data, adds the common data to a first shared class cache to generate a second shared class cache.

[0072] Processing continues in operation S295, where the CSO central server submodule 314 rejects subsequent update requests from deployments associated with the first shared class cache.

[0073] iii. Further comments and / or examples

[0074] Some embodiments of the present invention may recognize one or more of the following facts, potential problems and / or potential areas for improvement relative to the current state of the prior art for dynamic language environments (e.g., Java): (i) Just-in-time (JIT) compilation may increase overhead, which negatively impacts application performance, especially at startup when most JIT compilations occur; (ii) JIT compilation may hinder fast application startup and ramp-up; and / or (iii) although class files are loaded on demand, class loading may significantly lead to slow application startup for applications with a large number of classes to be loaded.

[0075] In some embodiments, the term "application" refers to a software program that runs on a virtual machine and can be compiled "just-in-time" (JIT). Non-exhaustive examples of such applications include a stock trading web application built from Spring Boot and a hotel booking web application built from Open Liberty. Spring Boot and Open Liberty run on top of the Java Virtual Machine.

[0076] While this document references certain products (e.g., "Java", "OpenJ9", and "JVM"), embodiments of the invention are not limited to such products. Some embodiments are also applicable to other dynamic runtime environments employing certain caching mechanisms, such as shared class caches. (Note: The terms "Spring Boot", "Open Liberty", "Java", "Java VirtualMachine", "OpenJ9", and / or "JVM" may be subject to trademark rights in various jurisdictions around the world, and are used herein only to refer to products or services appropriately named by the markings, provided such trademark rights may exist.)

[0077] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) a cache of methods for continuously improving compilation; (ii) a continuously and incrementally improving method, wherein JIT compilation can be tracked and merged into faster versions of the method in the cache; (iii) optimization around usage at application runtime in the cloud; (iv) a solution focused on an orchestration framework that automates container configuration; (v) statistics that can be used to improve performance are sent to a central location for reuse in order to continuously improve application build profiles; and (vi) build profiles are dynamic and can communicate centrally to obtain and improve build profiles associated with each appropriate workload on demand.

[0078] Some embodiments of the present invention are described herein in the context of OpenJ9, but are not limited to its applicability to OpenJ9. In OpenJ9, class data for Java applications is stored in a shared class cache (SCC). The shared class cache (SCC) is a memory-mapped file that stores information including: (i) the immutable portions of classes, (ii) Ahead-of-Time (AOT) compiled code, and (iii) analysis data. Application startup is accelerated because required classes can be quickly loaded from the memory-mapped file (SCC, which may reside in RAM), while JIT compilation is reduced to quickly load the cached AOT compiled body. The pooling of SCCs occurs transparently at runtime, which ensures that only the classes and methods required by the application are cached, and that the AOT body is customized, at least to some extent, for the running application. (Note: The terms “OpenJ9” and / or “Java” may be subject to trademark rights in various jurisdictions around the world, and are used herein only to refer to products or services appropriately named by the mark, provided that such trademark rights may exist.)

[0079] According to some embodiments of the present invention, a Class Shared Orchestrator (CSO) performs at least the following functions: (i) providing compatible, high-quality SCCs to each deployment of a Java application in the cloud; and (ii) continuously improving the quality of the SCCs provided to each deployment by collecting SCC data from the running application and performing offline processing based on the collected SCC data, while minimizing the impact on the running application.

[0080] The Class Shared Orchestrator (CSO) improves upon conventional solutions by: (i) enhancing the quality of the Shared Class Cache (SCC); and / or (ii) improving the availability of SCC sharing features for Java applications in container environments. These improvements are described in the following enumerated paragraphs.

[0081] Enhancing the quality of SCCs: In some embodiments, containerized Java applications contribute their own runtime class data to the corresponding (original) SCCs via an SCC consolidation mechanism. The consolidation mechanism combines updates from applications running the same type to generate newly formed SCCs of higher quality for future use. This mechanism guarantees that the newly formed SCCs are at least as good as, or better than, the original SCCs.

[0082] Improving the availability of SCC shared features for Java applications in container environments: In some embodiments, the SCC update mechanism optimizes the size of SCC data exchange and the time of SCC data exchange between applications running in the cloud to minimize the impact of CSO on running applications and network bandwidth.

[0083] Figure 6 Block diagram 600 illustrates an overview of the components of a system according to the present invention. The system includes: a container orchestrator 602 (for launching new Java applications); a central server agent for class sharing orchestrators (CSO) 604; an SCC integration mechanism 606; an SCC setup mechanism 608; an SCC update mechanism 610; a CSO client agent 612; a central shared class cache (SCC) repository 614; and a local SCC repository 616. Interactions and information flows between different system components are shown by arrows and discussed in the following paragraphs.

[0084] Some embodiments add the following software agents to the CSO: (i) CSO central server agent 604; and / or (ii) CSO client agent 612.

[0085] CSO Central Server Agent:

[0086] Some embodiments place the CSO central server agent 604 on a dedicated node, which is separate and distinct from any node hosting CSO client agents, such as CSO client agent 612. The CSO central server agent 604 performs the following functions: (i) providing a newly launched Java application container with a suitable SCC at startup, wherein the CSO central server agent 604 communicates with an existing container orchestration system to allow the CSO to obtain information about all running Java application images (within the CSO's scope); (ii) managing a central shared class cache (SCC) repository 614 for retaining SCCs for each Java application image; (iii) associating multiple Java application containers with multiple corresponding CSO client agents 612; and / or (iv) processing updates from the CSO client agents 612 to generate higher quality SCCs for each Java application image.

[0087] CSO client agent:

[0088] CSO client agent 612 is a background process that runs on each worker node and serves the applications running on it. The functions of CSO client agent 612 include: (i) monitoring the state of the Java Virtual Machine (JVM), where the state includes "active", "idle", or "exited"; (ii) sending updates to CSO central server agent 604 when the application state is "idle" or "exited"; and / or (iii) managing the local SCC repository 616 that maintains the shared class cache (SCC) on the worker nodes.

[0089] The Central Server Orchestrator (CSO) has three mechanisms implemented in combination with the CSO Central Server Agent 604 and the CSO Client Agent 612, including the following mechanisms: (i) SCC setup mechanism 608; (ii) SCC update mechanism 610; and / or (iii) SCC integration mechanism 606.

[0090] SCC configuration mechanism:

[0091] The SCC setup mechanism 608 establishes a suitable basic SCC for a newly launched Java application instance by performing at least some of the following operations: (i) receiving information about the new Java application instance; (ii) sending the basic SCC to the CSO client agent 612; and / or (iii) storing the basic SCC in the local SCC repository 616. These operations are further described in the following paragraphs.

[0092] Receive information about the new Java application instance:

[0093] CSO central server agent 604 receives information about the upcoming Java application instance from the existing container orchestration system (container orchestrator 602) and attempts to find a suitable base SCC. Note that the associated container may already be included in the SCC provided at image build time. The information received from container orchestrator 602 includes: (i) an image identifier (image ID) used to identify a suitable base SCC; (ii) parameters passed to the Java application instance used to identify a suitable base SCC; and / or (ii) the node running the Java application instance used to find the associated CSO client agent 612. Each base SCC in the central SCC repository 614 is keyed by the image ID and the parameters passed to the Java application instance. As a result, multiple Java application instances with the same image ID and the same parameters share the same base SCC.

[0094] Send basic SCC to the CSO client:

[0095] The CSO central server agent 604 identifies the appropriate basic SCC based at least in part on node information. The CSO central server agent 604 sends the basic SCC to the corresponding CSO client agent 612. The CSO central server agent 604 then sends the basic SCC required by the application via the associated CSO client agent 612. Each application is associated with a CSO client because they reside on the same node.

[0096] Basic SCC stored locally:

[0097] CSO client agent 612 stores the basic SCC in the local SCC store 616, which makes the basic SCC available for use by new Java application instances.

[0098] SCC update mechanism:

[0099] SCC update mechanism 610 manages SCC updates by performing at least some of the following actions: (i) updating the original SCC; (ii) associating a running application with a CSO client (see CSO client agent 612); (iii) increasing the SCC; and / or (iv) sending an SCC update request to CSO central server agent 604. CSO central server agent 604 may potentially reject the request for a variety of reasons. The foregoing actions and the reasons for possible rejection and their associated responses are described in the following paragraphs.

[0100] Update the original SCC:

[0101] An update is essentially the difference (variance) between the original (basic) SCC (available to the application's Java Virtual Machine (JVM) when a new Java application instance starts) and the new SCC subsequently generated by the JVM.

[0102] Associate the running application with the CSO client:

[0103] Some implementations associate each running application in the cloud with a CSO client (see CSO client agent 612). Therefore, there is one CSO client agent 612 for each worker node. The CSO client agent 612 calculates updates (class cache) for each application and sends them to the CSO central server agent 604 when the application is in an "idle" state or has completed execution (in an "exit" state). By waiting for the application to enter an "idle" or "exit" state, the CSO client agent 612 helps optimize network traffic because the updates do not compete with the application for network bandwidth. The timing of updates varies depending on the application and / or application workload. The CSO client utilizes the JVM idle detection mechanism to schedule the sending of application updates to the CSO central server (see CSO central server agent 604).

[0104] Growth SCC:

[0105] The Shared Class Cache (SCC) grows from both ends toward the middle, with class data added at one end and JIT data added at the other. For each SCC, there are two "base pointers" for the original SCC, and two "current pointers" for new additions made by the JVM. SCC updates include the content between the base pointers and the current pointers. The CSO client agent 612 tracks the base pointers and generates an SCC update for each Java application instance.

[0106] Send an SCC update request to the CSO central server:

[0107] Before sending an SCC update request, the CSO client agent 612 (associated with a specific node) sends a request to the CSO central server agent 604 to ensure that the SCC update will be accepted for further processing. If the CSO central server agent 604 rejects the request, it discards it. Subsequently, the next instance of the application on the specific node uses the new SCC provided by the CSO central server agent 604. The SCC update request includes the following information: (i) application image ID (used to identify the application type); (ii) parameters passed to the container (used to identify the application type); (iii) hardware information (used to identify the application type); (iv) node information (used to identify which CSO client it comes from); (v) SCC metadata (e.g., base SCC version, size, etc.); and / or (vi) execution behavior data (e.g., whether the application ends in the correct / expected / general way).

[0108] In some embodiments, the terms "application type," "managed runtime application type," and similar terms refer to a Docker image identifier (application image ID). For example, consider a stock trading web application. To enable the web application to run in the cloud, in some embodiments, the web application is packaged as a Docker image. The Docker image ID of the web application is the "application image ID." In embodiments of the invention, mechanisms and / or features associated with class data sharing are applied to applications of the same type. Instances of the same application can share data with each other. Regarding the Docker example above, the Docker image associated with the stock trading web application may have many different instances (Docker containers) deployed on different machines in the cloud (they can use various physical machines located in different physical locations to serve the stock trading service). All instances have the same Docker image ID and are therefore considered to be of the same type and are able to share data with each other. Now consider different applications, such as a video streaming web application. The video streaming web application and the stock trading web application have different Docker image IDs and are therefore not of the same type. Instances of the video streaming application have the same Docker image ID and are therefore able to share data with each other. However, instances of the video streaming application will not be able to share data with instances of the stock trading application.

[0109] Note: The term "Docker" may be subject to trademark rights in various jurisdictions worldwide, and is used here only to refer to products or services properly named by the mark, provided that such trademark rights may exist.

[0110] Potential reasons for request rejection, and associated responses:

[0111] CSO Central Server Agent 604 may reject a request for at least one of the following reasons or factors: (i) the SCC for the application type on the CSO Central Server is full and no longer accepts new updates, in which case CSO Client Agent 612 stops calculating and sending updates for the corresponding Java application instance; (ii) CSO Central Server Agent 604 determines that the application is not behaving correctly (e.g., the application returns an error code, a rare return code, and / or an unexpected return code), and considers the update invalid in response; and / or (iii) CSO Central Server Agent 604 considers the SCC update to be outdated, and therefore no longer accepts updates from such outdated versions. If CSO Central Server Agent 604 has a newer base SCC version than the base SCC version associated with the update, the SCC update is considered outdated, in which case CSO Client Agent 612 stops calculating and sending SCC updates for the corresponding Java application instance.

[0112] SCC integration mechanism:

[0113] According to some embodiments of the invention, SCC consolidation is based at least in part on SCC updates provided by a CSO client (e.g., CSO client agent 612) to generate higher-quality SCCs. The CSO central server agent 604 analyzes (offline) a threshold number of recently received SCC updates to establish a new base SCC that can be used by all subsequent Java application instances of the same type. Each SCC is mapped to an application type. Instances of the application populate a cache, and all instances of the application share the same SCC.

[0114] CSO Central Server Agent 604: Build a new basic SCC as follows:

[0115] Each time the CSO central server receives an update for a specific application type, it stores the update for later processing.

[0116] Once the CSO central server agent 604 receives an update to the threshold number, the CSO central server agent 604 stops receiving new updates and creates a new SCC based on the stored updates (the threshold number is heuristic-based - for example, in some embodiments, it is set to 80% of all application instances currently using the same basic SCC from the CSO central server);

[0117] If a base SCC associated with the application type exists on the CSO central server, all the base SCC content will be used in the new base SCC.

[0118] If there is common new data among more than one SCC update, the CSO Central Server Agent 604 adds the new data to the new SCC (e.g., if more than half of the updates indicate the compilation of the same method, the CSO Central Server Agent 604 considers the method "important" and includes the method in the new base SCC).

[0119] Once the CSO Central Server Agent 604 generates a new base SCC, the CSO Central Server Agent 604 rejects all update requests received from deployments started using the old SCC, and thereafter accepts updates only from deployments started using the new base SCC.

[0120] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) the shared class cache (SCC) may be dynamic (read / write) rather than static (read-only); (ii) analytics data and other just-in-time (JIT) compiler hints may vary over time; (iii) analytics data may accumulate over time to provide a better picture of the application's state; and / or (iv) dynamic data in the SCC enables developers to perform offline analytics on the state of different applications and dynamically modify the SCC to be optimized and more compact for each application.

[0121] Some embodiments of the present invention may identify one or more of the following facts, potential problems and / or potential areas for improvement over the prior art: (i) the SCC is a memory-mapped file; (ii) class data in the SCC includes immutable parts of the class; (iii) just-in-time (JIT) compiled data may include ahead-of-time (AOT) compiled code and analysis data; (iv) a “warm-up run” may be required to populate the shared class cache; (v) subsequent runs may have improved startup time and footprint; and / or (vi) may be required on the same node.

[0122] Figure 7 Block diagram 700 illustrates a process for establishing, updating, and integrating a shared class cache according to some embodiments of the present invention, including: a CSO central server agent 604; a first CSO client agent 612-1; a second CSO client agent 612-2; and a central SCC repository 614, including SCC5, SCC6...SCC k The first local SCC repository 616-1 includes SCC1, SCC2, ..., SCC. n The second local SCC repository 616-2 includes SCC3, SCC4...SCC m ; JVM1 701; JVM2 702; JVM3 703; JVM4 704; First node 721; Second node 722; Third node 723; and / or pending differences 724.

[0123] The operation numbers 1 to 11 below correspond to respectively Figure 7 Similar numbered arrows. Three processes according to some embodiments of the invention (and above regarding...). Figure 6 The following are discussed: SCC setup (operations 1 to 7); SCC update (operations 8 to 10); and SCC integration (operation 11).

[0124] SCC settings

[0125] 1. The cache shared orchestrator (first CSO client agent 612-1) receives information and relevant parameters about the container image to be launched from the first local shared class cache repository (first local SCC repository 616-1). The first CSO client agent 612-1 searches for a suitable SCC in the local repository 616-1.

[0126] 2. If the first CSO client agent 612-1 finds a suitable SCC, the first CSO client agent 612-1 installs the SCC in a Java Virtual Machine container (e.g., JVM1 701).

[0127] 3. If the first CSO client agent 612-1 does not find a suitable SCC in the local first local SCC storage 616-1, the first CSO client agent 612-1 sends a request to the CSO central server agent 604 to locate a suitable SCC.

[0128] 4. The CSO central server agent searches the central SCC repository (614, global SCC repository) to find and retrieve the appropriate SCC.

[0129] 5. The CSO central server agent 604 returns the appropriate SCC to the first CSO client agent 612-1.

[0130] 6. The first CSO client agent 612-1 installs the appropriate SCC in the local repository.

[0131] 7. The first CSO client agent 612-1 also installs the appropriate SCC in JVM1 701.

[0132] SCC Update

[0133] 8. The second CSO client agent 612-2 queries the status of the associated JVMs (JVM3 703 and JVM4 704). The second CSO client agent 612-2 also queries the SCC status stored in the second native SCC store 616-2 to determine whether JVM3 703 and / or JVM4 704 have new content that is not present in the corresponding SCC in the second native SCC store 616-2. If a threshold amount of new content exists in JVM3 703 and / or JVM4 704, the second CSO client agent 612-2, based on the content cached in the second native SCC store 616-2, calculates the difference (“diff”) between the content and JVM3 703 and / or JVM4 704.

[0134] 9. The second CSO client agent 612-2 sends an update request, including the difference, to the CSO central server agent 604. In some embodiments, the second CSO client agent 612-2 first sends a "probe message" to determine whether the CSO central server agent 604 will accept the update request.

[0135] 10. In response to accepting the update request, the CSO central server agent 604 stores the differences in Pending Differences 724.

[0136] SCC Integration

[0137] 11. In response to a new update request accumulating a threshold number in pending differences 724, the CSO server analyzes the update request (including the corresponding pending differences) and selects the information to propagate to the central SCC repository 614 (global repository). The central SCC repository 614 increments the updated arbitrary shared class caches (SCC5, SCC6...SCC) k The basic version of the CSO (Central Server Proxy) is currently experiencing a 604 error, rejecting updates for older versions.

[0138] Some embodiments of the present invention may include one or more of the following features, characteristics, and / or advantages: (i) sharing dynamic class data; (ii) continuously improving the quality of class data in a cloud environment; (iii) a cache update system that efficiently generates shared class cache updates by deploying a software agent on each node and by tracking a shared class cache base snapshot for each application running in the cloud environment; (iv) a cache consolidation system that continuously improves cache quality by efficiently collecting class cache updates from the software agent and efficiently consolidating updates using an improved set of rules that guarantees superiority over conventional solutions; (v) a cache orchestration system that manages cache data from all running applications in the cloud environment; (vi) a cache update and consolidation system that continuously improves cache results over time; (vii) improving the applicability of dynamic shared class data in a cloud environment; (viii) providing a class sharing orchestrator; (ix) sharing cloud-wide and / or cluster-wide class data; and / or (x) launching runtime applications managed in a containerized environment by a class sharing orchestrator.

[0139] Some embodiments of the present invention include a computer-implemented method for sharing class data in a cache, a computer program product for performing the method, and / or a computer system for performing the method, the method comprising: (i) in response to the launch of a managed runtime application in a containerized environment by a container orchestrator, receiving information from a central class sharing orchestrator server, the information including: an image ID, parameters passed to an instance of the managed runtime application, and an identifier of the worker node running the instance; (ii) in response to the central class sharing orchestrator server locating a suitable basic shared class cache in a central shared class cache store based on search criteria, the search criteria including parameters passed to the managed... (iii) Upon receiving the appropriate basic shared class cache from the class shared orchestrator central server, the class shared orchestrator central server sends the appropriate basic shared class cache to the corresponding class shared orchestrator client using information for worker node identification; (iv) Upon receiving the appropriate basic shared class cache from the class shared orchestrator central server, the corresponding class shared orchestrator client stores the appropriate basic shared class cache in the local shared class cache repository for use by the managed runtime application instances; (iv) Upon receiving a request for processing updates from the corresponding class shared orchestrator client (including image ID, passed parameters, hardware information, node information, and information about the class shared application instance), the class shared orchestrator central server sends the appropriate basic shared class cache to the corresponding class shared orchestrator client. (v) Additional shared class data of the basic SCC received by the class shared orchestrator client; the class shared orchestrator central server determines whether to accept the update; (v) In response to the class shared orchestrator central server rejecting the update request, the class shared orchestrator central server discards the update; (vi) The class shared orchestrator central server sends the new shared class cache to the corresponding class shared orchestrator client; (vii) In response to the class shared orchestrator central server accepting the update request, for specific types of managed runtime applications, the update is stored for later offline processing by the class shared orchestrator central server; (viii) Analyze the configurable number of maximum shared class data received by the class shared orchestrator central server. The following steps are taken: (ix) In response to the determination by the Class Shared Orchestrator Central Server that the analyzed data exists for a specific type in the Class Shared Orchestrator Central Server, a new basic shared class cache is generated using the entire contents of the old basic shared class cache; (x) In response to the determination by the Class Shared Orchestrator Central Server that there is common new data between more than one update, the new data is added to the new basic shared class cache by the Class Shared Orchestrator Central Server; and (xi) In response to the generation of the new basic shared class cache, update requests from deployments started using the old shared class cache are rejected by the Class Shared Orchestrator Central Server.

[0140] In the example embodiment, consider the following scenario where three nodes (Node 1, Node 2, and Node 3) respectively host: three instances of an application (app-1, app-2, and app-3, all of a given application type); three local cache shared orchestrator (CSO) clients (CSO-1, CSO-2, and CSO-3); and three local cache repositories (Cache-1, Cache-2, and Cache-3). A fourth node (Node-4) hosts a CSO central server and a central cache repository, which has a basic shared class cache (SCC) for applications specific to a given application type.

[0141] The CSO central server communicates with CSO-1, CSO-2, and CSO-3 to receive any local cache updates generated by app-1, app-2, and app-3 during execution. Based on the received local cache updates, the CSO central server updates the base SCC corresponding to the given application type in the central cache store.

[0142] When application-1 runs, CSO-1 collects and stores the associated cached data in its local cache repository (Cache-1). Now consider that CSO-1 eventually generates an update request and sends it to the CSO central server. The CSO central server searches for a suitable base SCC in the central cache repository. Once the CSO central server identifies the base SCC, it determines that Cache-1 (local to application-1) is outdated. In response, the CSO central server rejects the update request from CSO-1 and sends the base SCC from the central cache repository to CSO-1 on node-1. The same process occurs in application-2 and application-3, where CSO-2 and CSO-3 respectively collect and store the associated cached data in their respective local caches, send update requests to the CSO central server, and, if / when the corresponding local cache has been determined by the CSO central server to be outdated, receive updated base SCCs to update their local caches.

[0143] All means or steps in the following claims, plus corresponding structures, materials, actions, and equivalents of the functional elements, are intended to include any structure, material, or action for performing the function in conjunction with other claimed elements as specifically claimed. The description of this disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of this disclosure. Embodiments have been chosen and described in order to best explain the principles and practical application of this disclosure, and to enable others skilled in the art to understand this disclosure with respect to various embodiments having various modifications suitable for the particular intended use.

[0144] iv. Definition

[0145] The term "invention" should not be regarded as an absolute indication that the subject matter described by the term "invention" is covered by the filed claims or by the claims finally published after the patent application; although the term "invention" is used to help the reader get a general sense, the content disclosed herein is considered potentially new, and such understanding as indicated by the use of the term "invention" is provisional and temporary, and undergoes change during the patent application process as relevant information is developed and as the claims are potentially amended.

[0146] Example: See the definition of "invention" above - similar considerations apply to the term "example".

[0147] And / or: includes or; for example, A, B, "and / or" C means that at least one of A, B, or C is true and applicable.

[0148] Include (including) / include (including): unless otherwise expressly stated, means "including but not limited to".

[0149] Users / subscribers include, but are not limited to, the following: (i) a single individual; (ii) an artificial intelligence entity with sufficient intelligence to act as a user or subscriber; and / or (iii) a group of related users or subscribers.

[0150] Electrical connection: refers to direct or indirect electrical connection, which involves intermediate components; electrical connection may include, but is not limited to, components such as capacitors, inductors, transformers, vacuum tubes, etc.

[0151] Data communication: any type of data communication scheme now known or to be developed in the future, including wireless communication, wired communication and communication routing with wireless and wired components; data communication is not limited to: (i) direct data communication; (ii) indirect data communication; and / or (iii) data communication in which the format, packet state, medium, encryption state and / or protocol remain constant throughout the data communication process.

[0152] Receive / Provide / Send / Input / Output / Report: Unless otherwise expressly stated, these terms should not be construed as implying: (i) any particular degree of directness relative to the relationship between their objects and subjects; and / or (ii) the absence of any intermediate components, actions, and / or things inserted between their objects and subjects.

[0153] No substantial human intervention: A process that occurs automatically (usually through the operation of machine logic, such as software) with little or no human input; some examples involving “no substantial human intervention” include: (i) a computer is performing complex processing and is manually switched to an alternative power source (due to a power grid outage) so that the processing continues uninterrupted; (ii) a computer is about to perform resource-intensive processing and human verification is required that the resource-intensive processing should indeed be performed (in this case, the verification process considered separately involves substantial human intervention, but the resource-intensive processing does not involve any substantial human intervention, although a simple yes-no pattern verification is required); and (iii) using machine logic, a computer has made a weight decision (e.g., the decision to land all aircraft in anticipation of severe weather), but the computer must obtain a simple yes-no pattern verification from a human source before implementing the weight decision.

[0154] Automatic: No human intervention is required.

[0155] Module / Submodule: Any group of hardware, firmware, and / or software that is operable to perform a certain function, without regard to whether the module is: (i) in a single local vicinity; (ii) distributed over a wide area; (iii) located in a single adjacent area within a larger software code segment; (iv) located within a single software code segment; (v) located in a single storage device, memory, or medium; (vi) mechanically connected; (vii) electrically connected; and / or (viii) a data communication connection.

[0156] Computer: Any device with significant data processing and / or machine-readable instruction reading capabilities, including but not limited to: desktop computers, mainframe computers, laptop computers, field-programmable gate array (FPGA) based devices, smartphones, personal digital assistants (PDAs), wearable or plug-in computers, embedded device type computers, and / or application-specific integrated circuit (ASIC) based devices.

Claims

1. A computer-implemented method for sharing cached class data, the method comprising: Start the management runtime application within the containerized environment; Receive information about the managed runtime application, including an application image identifier, parameters associated with the managed runtime application, and a worker node identifier corresponding to the worker node associated with the managed runtime application; Locate the first shared class cache, i.e., the first SCC, in the central shared class cache store managed by the server, which uses the combination of the application image identifier and the parameters as the key; as well as In response to locating the first SCC: The first SCC is sent to the client associated with the worker node, and Store the first SCC in the local SCC repository. The method further includes: The client receives a first update request associated with the type of the managed runtime application. The first update request includes the application image identifier, the parameters, information about the worker node, additional class data, pre-compiled data, and execution data about the first SCC generated and accumulated over time. Confirm acceptance of the first update request; and In response to accepting the first update request: The analysis includes multiple update requests from the first update request to create the analysis's update request data. Based on the analyzed update request data, it was determined that the analyzed update request data includes new data shared by more than one of the multiple update requests, and The first SCC is modified based on the new data to generate the second SCC.

2. The method according to claim 1, further comprising: The client receives a first update request originating from the managed runtime application and associated with the first SCC, wherein the first update request is associated with the type of the managed runtime application and includes the application image identifier, the parameters, information about the worker node, additional class data, pre-compiled data, and execution data about the first SCC generated and accumulated over time. Determine to reject the first update request; and In response to rejecting the first update request, a second SCC is sent to the client.

3. The method according to claim 1, wherein, The type of the managed runtime application is based on the application image identifier, wherein multiple managed runtime applications with a common application image identifier are of the same type.

4. The method according to claim 1, wherein, The server is placed on a dedicated node that is separate from and different from the working node.

5. The method according to claim 1, wherein, The server performs tasks selected from the group consisting of the following: The first SCC is provided to the container in conjunction with the launch of the managed runtime application; Communicate with the container orchestration system to obtain information about the managed runtime application images within the server scope; Manage the central SCC repository; Associate the container with the corresponding client; as well as The first SCC is updated according to the update request received from the client.

6. The method according to claim 2, wherein, The decision to reject the first update request is based on a selection from the group consisting of: (i) the first SCC is full; (ii) the managed runtime application returns an error code; (iii) the managed runtime application returns an unexpected return code; and (iv) the second SCC is newer than the first SCC.

7. A computer program product for sharing cached class data, comprising: Program instructions, including instructions programmed to perform the following operations: Start the management runtime application within the containerized environment; Receive information about the managed runtime application, including an application image identifier, parameters associated with the managed runtime application, and a worker node identifier corresponding to the worker node associated with the managed runtime application; Locate the first shared class cache, i.e., the first SCC, in the central shared class cache store managed by the server, which uses the combination of the application image identifier and the parameters as the key; as well as In response to locating the first SCC: Send the first SCC to the client associated with the worker node; and Store the first SCC in the local SCC repository. The program instructions also include instructions programmed to perform the following operations: The client receives a first update request associated with the type of the runtime application being managed, including the application image identifier, the parameters, information about the worker node, additional class data, pre-compiled data, and execution data about the first SCC being generated and accumulated over time. Confirm acceptance of the first update request; as well as In response to accepting the first update request: The analysis includes multiple update requests from the first update request to create the analysis's update request data. Based on the analyzed update request data, it was determined that the analyzed update request data includes new data shared by more than one of the multiple update requests, and The first SCC is modified based on the new data to generate the second SCC.

8. The computer program product of claim 7, further comprising instructions programmed to perform the following operations: The client receives a first update request originating from the managed runtime application and associated with the first SCC, wherein... The first update request is associated with the type of the managed runtime application, including the application image identifier, the parameters, information about the worker node, additional class data, pre-compiled data, and execution data about the first SCC generated and accumulated over time; The first update request is rejected. as well as In response to rejecting the first update request, a second SCC is sent to the client.

9. The computer program product according to claim 7, wherein, The type of the managed runtime application is based on the application image identifier, wherein multiple managed runtime applications with a common application image identifier are of the same type.

10. The computer program product according to claim 7, wherein, The server is placed on a dedicated node that is separate from and different from the working node.

11. The computer program product according to claim 7, wherein, The server performs tasks selected from the group consisting of the following: The first SCC is provided to the container in conjunction with the launch of the managed runtime application; Communicate with the container orchestration system to obtain information about the managed runtime application images within the server scope; Manage the central SCC repository; Associate the container with the corresponding client; as well as The first SCC is updated according to the update request received from the client.

12. The computer program product according to claim 8, wherein, The decision to reject the first update request is based on a selection from the group consisting of: (i) the first SCC is full; (ii) the managed runtime application returns an error code; (iii) the managed runtime application returns an unexpected return code; and (iv) the second SCC is newer than the first SCC.

13. A computer system for sharing cached class data, comprising: Processor group; and One or more computer-readable storage media: wherein: The processor group is constructed, positioned, linked, and / or programmed to execute program instructions stored on one or more computer-readable storage media; and The program instructions include instructions programmed to perform the following operations: Start the management runtime application within the containerized environment; The Class Shared Orchestrator (CSO) central server receives information about the managed runtime applications, including application image identifiers, parameters associated with the managed runtime applications, and worker node identifiers corresponding to the worker nodes associated with the managed runtime applications. Locate the first shared class cache, i.e., the first SCC, in the central shared class cache store managed by the CSO central server, using the combination of the application image identifier and the parameters as the key; and In response to locating the first SCC: Send the first SCC to the CSO client associated with the worker node; and Store the first SCC in the local SCC repository. The program instructions also include instructions programmed to perform the following operations: The client receives a first update request associated with the type of the managed runtime application. The first update request includes the application image identifier, the parameters, information about the worker node, additional class data, pre-compiled data, and execution data about the first SCC generated and accumulated over time. Confirm acceptance of the first update request; and In response to accepting the first update request: The analysis includes multiple update requests from the first update request to create the analysis's update request data. Based on the analyzed update request data, it was determined that the analyzed update request data includes new data shared by more than one of the multiple update requests, and The first SCC is modified based on the new data to generate the second SCC.

14. The computer system of claim 13, further comprising instructions programmed to perform the following operations: The client receives a first update request originating from the managed runtime application and associated with the first SCC, wherein... The first update request is associated with the type of the managed runtime application, including the application image identifier, the parameters, information about the worker node, additional class data, pre-compiled data, and execution data about the first SCC generated and accumulated over time; The first update request is rejected. as well as In response to rejecting the first update request, a second SCC is sent to the client.

15. The computer system according to claim 13, wherein, The type of the managed runtime application is based on the application image identifier, wherein multiple managed runtime applications with a common application image identifier are of the same type.

16. The computer system according to claim 14, wherein, The decision to reject the first update request is based on a selection from the group consisting of: (i) the first SCC is full; (ii) the managed runtime application returns an error code; (iii) the managed runtime application returns an unexpected return code; and (iv) the second SCC is newer than the first SCC.

17. The computer system according to claim 13, wherein, The server performs tasks selected from the group consisting of the following: The first SCC is provided to the container in conjunction with the launch of the managed runtime application; Communicate with the container orchestration system to obtain information about the managed runtime application images within the server scope; Manage the central SCC repository; Associate the container with the corresponding client; as well as The first SCC is updated according to the update request received from the client.

Images