Cleaning up runtime resources with containers when uninstalling shared libraries

Abstract

Use containers to clean up runtime resources when unloading shared libraries. Embodiments of the present invention include a computer-implemented method comprising: accessing a loader library using a processor; generating a simulated library including a simulated version of the loader library using the processor; containerizing the loader library using the processor; and unloading the loader library using the processor.

Description

Technical Field

[0001] This invention generally relates to programmable computer systems. More specifically, it relates to computer systems, computer-implemented methods, and computer program products that utilize containers to clean up runtime resources when unloading shared libraries, thereby avoiding segmentation faults. Background Technology

[0002] Microservices are a type of software architecture where the functionality of a software application is broken down into smaller pieces to make the application more resilient and scalable. These smaller pieces are called "services." Each service is modular because each service focuses on only a single function of the application and is isolated from other services, making each one independent. Modularity allows development teams to work on different services independently without requiring complex design-related coordination between teams.

[0003] Different microservices can communicate with each other via APIs or web services to perform overall application functionality. For example, microservices can communicate with each other and with other software applications using the Remote Procedure Call (RPC) protocol. RPC is a protocol that allows a program to request services from a program on another computer on a network without needing to understand the network details. The RPC protocol uses a client-server model. The requesting program is the client, and the service provider is the server.

[0004] Applications utilize libraries to improve the efficiency of application development and execution. A library is a collection of non-volatile resources used by computer programs. Libraries are commonly used in software development. Libraries can include configuration data, documentation, help data, message templates, pre-written code, pre-written subroutines, etc. Programmers who want to write more advanced programs can use libraries to make system calls instead of implementing them one by one. Library code is organized so that it can be used by multiple programs that are not connected to each other, while code that is part of a program is organized so that it is used only within that one program. Libraries are organized to be reused by independent programs or subroutines, and users only need to know the interface, not the internal details of the library. Libraries enable the reuse of standardized program elements. When a program calls a library, it obtains the behavior implemented in the library, without having to implement the behavior itself. Libraries encourage modular code sharing and simplify code distribution.

[0005] The behavior implemented by a library can be linked to the calling program at different stages of the program's lifecycle. If the library's code is accessed when the calling program is created, the library is called a static library. An alternative is to create an executable file for the calling program and distribute it independently of the library implementation. The library behavior is linked after the executable file is invoked for execution, either as part of the start of execution or during execution. In this case, the library is called a dynamic library (loaded at runtime). Dynamic libraries can be loaded and linked when preparing a program for execution by the linker. Alternatively, the application can explicitly request the module to be loaded during execution. Summary of the Invention

[0006] Embodiments of the present invention include a computer-implemented method comprising: accessing a loader library using a processor; generating a simulated library including a simulated version of the loader library using the processor; containerizing the loader library using the processor; and unloading the loader library using the processor.

[0007] Several embodiments of the present invention also provide computer systems and computer program products having substantially the same features as the computer-implemented methods described above.

[0008] Additional features and advantages are achieved through the technology of this invention. Other embodiments and aspects of the invention are described in detail herein and are considered part of the claimed invention. For a better understanding of the advantages and features of the invention, please refer to the specification and drawings. Attached Figure Description

[0009] The subject matter considered to be the invention is specifically pointed out and clearly claimed in the claims at the end of this specification. The foregoing and other features and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0010] Figure 1 A block diagram illustrating a system embodying various aspects of the present invention is depicted;

[0011] Figure 2 A block diagram illustrating a system embodying various aspects of the present invention is depicted;

[0012] Figure 3 A block diagram illustrating a system embodying various aspects of the present invention is depicted;

[0013] Figure 4 A block diagram illustrating a system embodying various aspects of the present invention is depicted;

[0014] Figure 5 Details of exemplary computing systems capable of implementing various aspects of the present invention are described;

[0015] Figure 6A cloud computing environment according to an embodiment of the present invention is described;

[0016] Figure 7 An abstract model layer according to an embodiment of the present invention is described. Detailed Implementation

[0017] For the sake of brevity, conventional techniques related to the manufacture and use of various aspects of the present invention may or may not be described in detail herein. Specifically, various aspects of the computing systems and particular computer programs used to implement the different technical features described herein are well known. Therefore, for the sake of brevity, many conventional implementation details are only briefly mentioned or omitted entirely herein, without providing well-known system and / or process details.

[0018] Many functional units of the systems described in this specification are designated as modules. Embodiments of the invention are applicable to a wide variety of module implementations. For example, a module can be implemented as hardware circuitry, including custom VLSI circuitry or gate arrays, off-the-shelf semiconductors (such as logic chips, transistors, or other discrete components). Modules can also be implemented in programmable hardware devices (such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc.). Modules can also be implemented in software for execution by different types of processors. The identified executable code modules may, for example, comprise one or more physical or logical blocks of computer instructions, which may, for example, be organized as objects, procedures, or functions. However, the executable files of the identified modules do not need to be physically located together, but may include different instructions stored in different locations that, when logically joined together, function as a module and achieve the module's intended purpose.

[0019] For ease of explanation, the different components, modules, and sub-functions of the system shown herein are described separately. In embodiments of the invention, unless otherwise specified, the operations performed by the various components, modules, and sub-functions may be distributed differently than shown, without departing from the scope of the various embodiments of the invention described herein.

[0020] For convenience, informal expressions are used to convey some of the technical functions and / or operations described herein. For example, a processor having data stored in its cache memory can be described as a processor that "knows" that data. Similarly, a user sending a command to a processor to load data can be described as the user "telling" the processor to load data. It should be understood that any such informal expressions in the Detailed Description section should be interpreted as encompassing—and those skilled in the art will understand that such informal expressions encompass—the corresponding more formal and technical descriptions.

[0021] Turning now to a more specific technical overview related to various aspects of the invention, as noted above, microservices are a type of software architecture in which the functionality of a software application is broken down into smaller pieces to make the application more resilient and scalable. These smaller pieces are called “services.” Each service is modular because each service focuses on only a single function of the application and is isolated from other services, making each one independent. Modularity allows development teams to work on different services independently without requiring complex design-related coordination between teams.

[0022] Different microservices can communicate with each other via APIs or web services to perform overall application functionality. For example, microservices can communicate with each other and with other software applications using the Remote Procedure Call (RPC) protocol. RPC is a protocol that allows a program to request services from a program on another computer on a network without needing to understand the network details. The RPC protocol uses a client-server model. The requesting program is the client, and the service provider is the server.

[0023] Applications leverage libraries to improve the efficiency of application development and execution. A library is a collection of non-volatile resources used by computer programs. Libraries are commonly used in software development. Libraries may include configuration data, documentation, help data, message templates, pre-written code, pre-written subroutines, etc. Programmers who want to write more advanced programs can use libraries to make system calls instead of implementing them repeatedly. Library code is organized so that it can be used by multiple programs that are not connected to each other, while code that is part of a program is organized so that it is used only within that one program. Libraries are organized for reuse by independent programs or subroutines, and users only need to know the interface, not the internal details of the library. Libraries enable the reuse of standardized program elements. When a program calls a library, it obtains the behavior implemented in the library, without having to implement the behavior itself. Libraries encourage modular code sharing and simplify code distribution.

[0024] The behavior implemented by a library can be linked to the calling program at different stages of the program's lifecycle. If the library's code is accessed when the calling program is created, the library is called a static library. An alternative is to create an executable file for the calling program and distribute it independently of the library implementation. The library behavior is linked after the executable file is invoked for execution, either as part of the start of execution or during execution. In this case, the library is called a dynamic library (loaded at runtime). Dynamic libraries can be loaded and linked when preparing a program for execution by the linker. Alternatively, the application can explicitly request the module to be loaded during execution.

[0025] Dynamic loading is a mechanism that allows a computer program to load libraries (or other binary files) into memory at runtime; retrieve the addresses of functions and variables contained in the library; execute these functions or access these variables; and unload the library from memory. gRPC ( Remote Procedure Call (RPC) is a modern, open-source, high-performance RPC framework that can run in any environment. Some RPC frameworks (e.g., gRPC) do not support "cross-process calls," therefore, the gRPC library cannot be unloaded. More specifically, in such RPC frameworks, segmentation failures occur when a shared object is unloaded.

[0026] Turning now to an overview of various aspects of the invention, embodiments of which provide computer systems, computer-implemented methods, and computer program products that avoid segmentation faults that occur when known RPC frameworks attempt to unload shared libraries by utilizing containers to clean up runtime resources during shared library unloading. Novel computer-implemented methods according to embodiments of the invention are provided to unload shared libraries and safely clean up the runtime environment. Embodiments of the invention use containerized libld.so (i.e., containerized dynamic linker / loader) and target shared libraries (i.e., the shared libraries to be unloaded) to create a language environment that can be safely destroyed during target shared library unloading. Shared libraries always have the suffix ".so". Program instructions / functions "libtarget_go.so" and "libld.so" are shared libraries. However, "libld.so" is a special shared library because "libld.so" (or ld.so) is a dynamic linker / loader that provides dlopen() / dlsym() / dlcose() for loading / unloading other shared libraries.

[0027] The Dynamic Link (DL) interceptor module manages the container lifecycle, including creating / destroying containers and passing data and function requests from the host to the container. It also manages the session lifecycle, including creating / destroying sessions to communicate with the container when DL functions enter. The stack handling module performs translation between the stack and protocol buffers. Protocol buffers are language-independent, platform-independent, and scalable mechanisms for serializing structured data. Users define how the data will be constructed once, and then easily write and read structured data from various data streams using specially generated source code in various languages. The DL interceptor module and the Mapping Stub module use this functionality to transform data and then pass it between each other. The Mapping Stub module uses libdl.so from the container created by the DL interceptor module to load the target shared library into the memory address space and then records the mapping between session IDs and handlers. Then, when a DL function enters, the data is routed to the target library. When a dlclose request arrives, the DL interceptor module destroys the container and invalidates the session ID. Therefore, in embodiments of the invention, containerization of the shared library allows unloading the shared library without incurring a segmentation failure. Although segmentation may occur within the container, according to embodiments of the invention, the entire container is destroyed upon unloading. Therefore, using aspects of the invention, end users outside the container will never see a "segmentation failure."

[0028] Now we turn to a more detailed description of various aspects of the invention. Figure 1 System 100 according to an embodiment of the present invention is described. Before describing system 100, several open-source concepts related to various aspects of the present invention are described. The programs libld.so and ld-linux.so locate and load the shared objects (shared libraries) required by a program, prepare the program for execution, and then run the program. Therefore, the program "libld.so" is a dynamic linker / loader. It provides dlopen() / dlsym() / dlcose() for loading / unloading other shared libraries. Furthermore, the protocol buffer is a language-independent, platform-independent, and extensible mechanism for serializing structured data. Users define how the data will be constructed once, and then, using specially generated source code in various languages, structured data can be easily written to and read from various data streams.

[0029] Refer again Figure 1System 100 includes an external entity 110 that communicates with containerization platform 150 via stack processing module 132, configured and arranged as shown in the figure. Entity 110 includes a set of software instructions (or computer code) 112 and a dynamic linker (DL) interceptor module 114. More specifically, the software instructions 112 are programs / applications that load shared libraries. The program “libtarget_go.so” is an example name of the shared library. It can be any shared library. The program instructions dlopen() / dlsym() / dlclose() in computer code 112 are three functions provided by libld.so for loading shared libraries. Computer code 112 demonstrates the process of loading / unloading the shared library libtarget_go.so by utilizing simulated dlopen() / dlsym() / dlclose() provided by a simulated dynamic linker / loader (i.e., libld.so).

[0030] Without benefiting from various aspects of the present invention, computer code 112 may interact with or invoke "libld.so". However, "libld.so" cannot clean up the entire environment when unloading shared libraries. Sometimes, "libld.so" may cause errors during unloading, such as "segmentation fault" errors, affecting computer code 112. According to various aspects of the present invention, DL interceptor module 114 introduces a new mock libld.so 116, allowing computer code 112 to interact with (or invoke) the mock libld.so 116 instead of interacting with or invoking the real "libld.so". DL interceptor module 114 is configured to manage container lifecycles and also pass data and feature requests from computer code 112 to containerization platform 150. DL interceptor module 114 also manages session lifecycles. It unloads shared libraries by destroying the container containing the shared library. Therefore, unexpected errors within the container will not affect applications / programs located on the host. The simulated libld.so 116 is a mock "libld.so". The simulated libld.so 116 receives requests from computer code 112, which are processed and passed to the real "libld.so". When an end user invokes a dl function (i.e., dlopen / dlsym / dlclose), it is actually invoking the mock dl function within the simulated libld.so.

[0031] The DL interceptor module 114 also includes a Session Lifecycle Management module 118 and a container processing module 120, configured and arranged as shown in the figure. The Session Lifecycle Management module 118 creates a session structure, with one unique session structure corresponding to one program / application. The session structure includes a "session ID," which is the "target shared library name." When the customized container starts, the "target shared library name" is loaded by the dynamic linker / loader (libld.so) within the container. For the container processing module 120, DL means "dynamic linking," and "dynamic link library" has the same meaning as "shared library." Therefore, the "DL name" is the dynamic link library name, which is also the shared library name. Thus, the container processing module 120 provides container management functionality. For example, module 120 provides Init() and Destroy() functions. Init(session ID, DL name) creates the container and passes the DL name (shared library name) to the container so that the dynamic linker / loader (libld.so) knows which shared library to load within the container. Destroy() destroys the container that was created.

[0032] Stack processing module 132 includes analysis and transformation module 134, which is communicatively coupled to call stack 136 and protocol buffer 138. Generally, a call stack is a stack data structure that stores information about active subroutines of a computer program. While maintaining the call stack is important for the proper functioning of most software, in high-level programming languages, the details are often hidden and automatic. Many computer instruction sets provide special instructions for manipulating the stack. The call stack serves several related purposes, but the primary reason for having a call stack is to track the point where each active subroutine should return control upon completion of execution. An active subroutine is a subroutine that has been called but has not yet completed execution and should return control to the calling point upon completion. This activation of subroutines can be nested at any level (a special case is recursion), thus requiring a stack structure.

[0033] The analysis and conversion module 134 of module 132 undertakes the main work of the stack processing module 132. Parameters in computer code in "stack" form are difficult to transmit, while parameters in protocol buffer form are easy to transmit. Therefore, the analysis and conversion module 134 provides two parameter manipulation methods, Pack() and UnPack(), for conversion. The stack processing module 132 reads parameters from the call stack 136 of the running computer code and then converts the parameters into protocol buffer form (protocol buffer 138). It can also convert parameters from protocol buffer form and then write the parameters back to the call stack 136 of the computer code. As described above, through the analysis and conversion module 134, the stack processing module 132 provides two parameter manipulation methods, Pack() and UnPack(). The Pack() method reads parameters from the call stack 136 of the running computer code and then converts the parameters into protocol buffer form (protocol buffer 138). The UnPack() method converts parameters from protocol buffer form and then writes the parameters to the call stack 136 of the computer code.

[0034] The containerization platform 150 includes the mapping stub module 152, the libld.so command / function set, and the libtarget_go.so command / function set. Typically, the containerization platform 150 can be an open-source containerization platform configured and arranged for building, deploying, and managing containerized applications. Open-source containerization platforms enable developers to package applications into containers—standardized executable components that combine application source code with operating system (OS) libraries and the dependencies required to run that code in any environment. Containers simplify the delivery of distributed applications and are becoming increasingly popular as organizations move towards cloud-native development and hybrid multi-cloud environments. An open-source containerization platform is essentially a toolkit that enables developers to build, deploy, run, update, and stop containers using simple commands and work-saving automation through a single API. The process isolation and virtualization features built into the Linux kernel make containers possible. These capabilities—such as control groups (cgroups) for allocating resources among processes and namespaces for restricting a process's access to or visibility into other resources or regions of the system—enable multiple application components to share the resources of a single instance of the host operating system, just as a hypervisor allows multiple virtual machines (VMs) to share the CPU, memory, and other resources of a single hardware server. Therefore, container technology provides all the functionality and benefits of virtual machines, including application isolation, cost-effective scalability, and disposability.

[0035] Containerization platforms use so-called "images," which contain executable application source code along with all the tools, libraries, and dependencies required for the application code to run as a container. When an image is run, it becomes one (or more) instance of a container. While it's possible to build an image from scratch, most developers pull images from public repositories. Multiple images can be created from a single base image, sharing the commonalities of their stack. Images consist of layers, each corresponding to a version of the image. Whenever a developer makes changes to an image, a new top layer is created, replacing the previous top layer as the current version of the image. Previous image layers are saved for rollback or reuse in other projects. Each time a container is created from an image, another new layer called the container layer is created. Changes made to the container (such as adding or deleting files) are only saved to the container layer and exist only while the container is running. This iterative image creation process enables improved overall efficiency because multiple live container instances can run from a single base image, and when multiple live containers are running, they utilize a common stack. A container is a live instance of an image. Although the image is a read-only file, containers are live, ephemeral executables. Users can interact with them, and administrators can use docker commands to adjust their settings and conditions.

[0036] More specifically, see containerized platform 150, which is a container containing mapping stub module 152, a dynamic linker / loader (i.e., libdl.so), and other shared libraries (such as libtarget_go.so). When computer code on system 100 calls dlclose(), dlclose() uses DL interceptor module 114 to destroy the entire container. Therefore, everything within the container is destroyed. Any failures occurring within the container (such as segmentation failures) will not affect the locale of system 100.

[0037] The mapping stub module 152 loads libld.so into the memory address space of the containerization platform 150. Then, libld.so loads libtarget_go.so into the memory address space of the containerization platform 150. The mapping between session IDs and handlers is then recorded. When the dl function arrives, data and the dlsym() request are routed to the target library. The libld.so function adapt module receives protocol buffer data from the host. The mapping stub module 152 maintains the mapping between session IDs and handlers so that when a dlsym() request arrives, the mapping stub module 152 knows the target location it should be routed to.

[0038] "libtarget.go.so" is a shared library that contains a series of functions such as "func1()", "func2()", and "func3()". Figure 1 This illustrates how the "func1" request is handled in system 100. When computer code 112 wants to call "funcl()" in "libtarget_go.so", it uses a mock dlopen() in the DL interceptor module 114 to create the containerized platform 150. It uses a mock dlsym(p, "func1") to send a request to the containerized platform. It uses a mock dlclose() to destroy the containerized platform 150.

[0039] System 100 operation in Figure 2 , 3 As shown in Figure 4, reference will be made to Figure 2 , 3 The various operational steps shown in sections 4 and 5 are described. Figure 2 and Figure 3 Provided Figure 1 Additional details of some components of the system 100 shown. For example... Figure 2 As shown, the simulated libld.so 116 contains "simulated dlsym", "simulated dlclose", and "simulated dlopen". The existing "libld.so" contains "dlsym()", "dlclose()", and "dlopen()". By using Figures 2 to 4 The method shown, when computer code 112 calls "dlsym()", "dlclose()", and "dlopen()", actually calls "simulated dlsym", "simulated dlclose", and "simulated dlopen" in simulated libld.so 116. Simulated libld.so 116 routes the function request to the actual libld.so within the containerized platform 150.

[0040] like Figure 2As shown, within the session lifecycle management module 118 are "session," "ID," "DL name," "container operations," and "parameter operations." When computer code calls the dlopen function, it actually calls the simulated dlopen within libdl.so. The simulated dlopen interacts with the session lifecycle management module 118. The session lifecycle control module 118 creates the session structure. Each piece of computer code 112 creates a unique session structure containing a unique session ID. The "session ID" is the session identifier. The "DL name" is the dynamic link library name, which is the shared library name. "Container operations" contain operations on the Init(), Destroy(), and Invoke() functions. Init() initializes the container. Destroy() destroys the container. Invoke() calls the real functions (functions 1, 2, and 3) in libtarget_go.so within the container. "Parameter operations" refer to the Pack() and UnPack() methods. The Pack() method reads parameters from the call stack 136 of the running computer code 112 and then converts the parameters into a "protocol buffer" form. The Unpack() method converts the parameters from the form of a "protocol buffer" and then writes the parameters to the call stack 136 of computer code 112.

[0041] like Figure 2 As shown, the container processing module 120 includes "container operations," "initialization," "destruction," and "calling shared libraries." The container processing module 120 provides these operations to initialize the containerization platform 150, destroy the containerization platform 50, and pass dlsym() requests to the containerization platform 120.

[0042] like Figure 2 As shown, the box labeled "Analysis and Transformation" (134) contains "Parameter Operations," "Pack()," and "UnPack()." "Parameter Operations" refers to the Pack() and UnPack() methods. These are used to pack data for transformation and to unpack data when it arrives.

[0043] like Figure 3 As shown, the containerized platform 150 internally contains "libtarget_golang.so". "libtarget_go.so" is the example name of the shared library. It can be any name. Embodiments of this invention focus on completely unloading the shared library "libtarget_go.so" without causing any pollution to the original language environment.

[0044] Now for reference Figures 2 to 4The method shown, for dlopen in S1, when the end user calls the dlopen function, it actually calls the "simulated" dlopen within the libdl.so shared library. In S2, the simulated dlopen interacts with the session lifecycle management module 118. The session lifecycle module 118 creates a session structure, which includes a new UUID as the session ID, a new DL name, the target shared library to be loaded, a container registration operation provided by the container processing module 120, and registration parameter operations provided by the stack processing module 132. In S3, the simulated dlopen uses the init() method to create a new container.

[0045] In S4, when the end user invokes the `dlclose` function, it actually calls a mock `dlclose` within the `libdl.so` shared library. In S5, the mock `dlclose` invalidates the session ID in the session structure. In S6, the mock `dlclose` uses the `destroy()` method to destroy the container and release the session structure.

[0046] For dlsym in S7, when the end user invokes the dlsym function, it actually invokes the simulated dlsym within the libdl.so shared library. In S8, the simulated dlsym interacts with the session lifecycle management module 118. In S9, the session lifecycle control module 118 uses the pack() method registered in S2 by the stack processing module 132 to transfer parameters from the call stack 136 to the protocol buffer 138. In S10, the simulated dlsym uses the invoke() method registered in S2 by the container processing module 120 to invoke the protocol buffer 138 from the previous step. In S11, the simulated dlsym retrieves the results and parameters, and then uses the unpack() method to transfer them from the protocol buffer 138 to the call stack 136.

[0047] Figure 3 and 4 Additional operations S31-S39 are described. For example... Figure 3As shown, in S31, the `init()` method creates the container and uses the host image as the base image. System directories on the host, specifically the library directories, are mapped to the container, and the mapping stub module 152 is initialized. Mapping stub module 152 loads `libld.so` into the address space. In S32, protocol buffer data including the session ID, target library name, and function name is passed to the container. The target library is loaded into the address space using `dlopen()` from `libld.so`. `dlopen()` returns a handler, which will be used by `dlsym()` and `dlclose()`. In S34, the session ID is mapped to the handler generated in the previous step. In S35, the `destroy()` method destroys the container created in S31.

[0048] like Figure 4 As shown, in S36, the invoke() method passes protocol buffer data, including the session ID, function name, and function parameters, to the mapping stub module 152. In S37, the mapping stub module 152 obtains the handler using the session ID. In S38, the mapping stub module 152 uses libld.so along with the handler, function name, and function parameters to invoke the target function. In S39, libld.so invokes the actual function.

[0049] Therefore, it can be seen that the embodiments of the present invention provide technical advantages and effects. The embodiments of the present invention can clean up all resources of the shared library when uninstalling the shared library. Changes are transparent to the end user, and code changes need to be made by the end user. The embodiments of the present invention are not limited to shared libraries or programming languages. The simulated library (simulated libld.so) container is located outside the container. libld.so is located inside the container, and the simulated libld.so passes requests to the libld.so inside the container. libld.so is a loader library, and the simulated libld.so is a simulated loader library.

[0050] Therefore, embodiments of the present invention provide a novel computer-implemented method configured to unload shared libraries and securely clean up the locale using a DL interceptor, stack handling, and containerization of the target shared library. The DL interceptor module manages the shared library session lifecycle and container lifecycle, creating the container when a dlopen request arrives and destroying it when a dlclose request arrives. When a dlsym arrives, data and function requests are transferred from the host to the container. Sessions associated with handlers are created and destroyed. The stack handling module performs translation between the stack and protocol buffer. The DL interceptor module and the mapping stub module use this function to translate data and then pass it to each other. The mapping stub module uses libdl to load the target shared library into the memory address space. Therefore, the mapping between session IDs and handlers is then recorded. When a DL function arrives, data and dlsym requests are routed to the target library.

[0051] Figure 5 Examples of computer systems 500 that can be used to implement various embodiments of the invention described herein are illustrated. Computer system 500 includes an exemplary computing device (“computer”) 520 configured to perform various aspects of content-based semantic monitoring operations according to various aspects of the invention described herein. In addition to computer 520, exemplary computer system 500 includes a network 534 connecting computer 520 to other systems (not shown) and may include one or more wide area networks (WANs) and / or local area networks (LANs), such as the Internet, intranets, and / or wireless communication networks. Computer 520 communicates with other systems via network 534, for example, to transfer data between them.

[0052] The exemplary computer 520 includes a processor core 52, main memory (“memory”) 528, and input / output components 530 communicating via a bus 532. The processor core 52 includes a cache memory (“cache”) 524 and control logic 526, which includes a branch prediction structure and associated search, hit, detection, and update logic, which will be described in more detail below. The cache 524 may include multiple cache levels (not shown) on or off-chip of the processor core 52. The memory 528 may include various data stored therein, such as instructions, software, routines, etc., which may be transferred to / from the cache 524 via the control logic 526 for execution by the processor core 52. One or more input / output components 530 may include one or more components, such as a display, keyboard, modem, network adapter, etc. (not shown), that facilitate local and / or remote input / output operations to / from the computer 520.

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

[0054] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services), which can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0055] The features are as follows:

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

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

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

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

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

[0061] The service model is as follows:

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

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

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

[0065] The deployment model is as follows:

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

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

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

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

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

[0071] See now Figure 6This describes 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 6 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).

[0072] See now Figure 7 This demonstrates a cloud computing environment of 50 ( Figure 6 This provides a set of functional abstractions. It should be understood beforehand. Figure 7 The components, layers, and functions shown are intended to be illustrative only, and embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

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

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

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

[0076] The 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 instruction delivery 93; data analysis and processing 94; transaction processing 95; and automatically avoiding segmentation faults by utilizing containers to clean up runtime resources when unloading shared libraries 96.

[0077] This invention can be a system, method, and / or computer program product at 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.

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

[0079] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network may include copper transmission cables, optical transmission 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 computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the corresponding computing / processing device.

[0080] 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, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, etc.) and conventional 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 be personalized to execute computer-readable program instructions by utilizing state information from the computer-readable program instructions in order to perform aspects of this invention.

[0081] 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 [various aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention]. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

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

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

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

[0085] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well. The terms “comprising,” “having,” “including,” and “containing,” as used in the specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0086] The term "exemplary" as used herein means "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as superior to other embodiments or designs. The terms "at least one" and "one or more" can include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "multiple" can include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" can include both indirect "connection" and direct "connection."

[0087] The terms “approximately,” “substantially,” and their equivalents are intended to include the degree of error associated with a specific number of measurements based on the equipment available at the time of application submission. For example, “approximately,” “substantially,” can include a range of ±8%, 5%, or 2% of a given value.

[0088] Although the invention has been described in detail with reference to only a limited number of embodiments, it should be readily understood that the invention is not limited to the embodiments thus disclosed. Instead, modifications can be made to the invention to include any number of variations, alterations, substitutions, or equivalent arrangements that, while not described herein, are commensurate with the spirit and scope of the invention. Furthermore, although various embodiments of the invention have been described, it should be understood that aspects of the invention may include only some of the embodiments described. Therefore, the invention should not be considered limited to the foregoing description, but only to the scope of the appended claims.

Claims

1. A computer-implemented method, comprising: Use the processor to access the loader library; The processor is used to generate a simulated version of the simulation library, which includes the loader library. The processor is used to containerize the loader library; Unload the loader library using the processor. The processor includes: Dynamically link the dl interceptor module; The stack processing module is communicatively coupled to the dl interceptor module; and A mapping stub module communicatively coupled to the stack processing module; and wherein, The mapping stub module is part of the containerization platform; The simulation library is stored on the dl interceptor module.

2. The computer-implemented method according to claim 1, further comprising sending an unload signal to the loader library.

3. The computer-implemented method of claim 1, wherein, Use the dlclose instruction to instruct the processor to unload the loader library.

4. A computer system comprising a memory communicatively coupled to a processor, wherein, The processor is configured to perform processor operations according to any one of claims 1 to 3.

5. A computer program product for unloading a library, the computer program product comprising a computer-readable program embodied therein, wherein when the computer-readable program is executed on a processor, it causes the processor to perform a processor method according to any one of claims 1 to 3.

Images