Unloading Interdependent Shared Libraries

Abstract

Unloading a shared resource is described. A shared library correlation table (SLCT) is generated with mock resources. During a close function, an entry in the SLCT is selected to decrease the reference count of the selected entry in the SLCT, and the status of the selected entry based on the reference count is verified. If the status of the selected entry indicates that the associated container is not a shared resource, the associated container of the selected entry is deleted from memory, thereby avoiding a segmentation fault.

Description

[Background technology]

[0001] The present invention relates generally to accessing, utilizing, and unloading various computer program resources (e.g., resources, libraries, binaries, functions, etc.) More specifically, the present invention relates to cleanly unloading runtime resources, thereby avoiding segmentation faults, when unloading interdependent shared libraries in a containerized environment using a shared library correlation table.

[0002] Many types of computer programs and programming languages ​​include options for dynamic loading (DL), a mechanism that allows a computer program to load a library (or other similar resource) into memory, obtain the addresses of associated functions and variables (i.e., objects) contained in the library, execute those functions or access those variables, and then unload the library from memory. In some examples, these libraries or resources may include shared objects, where the shared object is called by another library or resource at runtime. Fetching, extracting, and loading these shared object resources can cause segmentation faults at runtime if the resources are not released or closed in order. Providing a mechanism that allows the DL of these shared objects without causing a segmentation fault remains a challenge. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 shows a block diagram illustrating a system according to one embodiment.

[0004] [Figure 2] FIG. 1 illustrates a system flow block diagram illustrating a system with a shared library correlation table according to one embodiment.

[0005] [Figure 3] FIG. 1 illustrates a system flow block diagram for calling functions using a shared library correlation table according to one embodiment.

[0006] [Figure 4] FIG. 1 illustrates a system flow block diagram for closing functions using a shared library correlation table according to one embodiment.

[0007] [Figure 5A] FIG. 1 illustrates a method for a shared library correlation table according to one embodiment. [Figure 5B] FIG. 1 illustrates a method for a shared library correlation table according to one embodiment.

[0008] [Figure 6] FIG. 1 illustrates details of a computing environment according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] As described above, a computer program may utilize various resources when it runs or executes. These resources may also be referred to as microservices. Microservices are a type of software architecture that divides the functionality of a software application into smaller pieces, making the application more fault-tolerant and scalable. The smaller pieces are called "services." Each service is modularized, focuses on a single function of the application, and is isolated from other services, making each of them independent. Modularization allows development teams to work on different services separately without requiring more complex design-related orchestration between teams.

[0010] Different microservices may communicate with each other through APIs or web services to perform the overall functionality of an application. For example, microservices may communicate with each other and with other software applications using the Remote Procedure Call (RPC) protocol or other communication mechanisms. RPC is a protocol that one program can use to request a service from a program located on another computer on a network without having to understand the details of the network. In some examples, the RPC protocol uses a client-server model, where the requesting program is the client and the serving program is the server.

[0011] In some examples, application programs utilize the compilation of resources or libraries accessed via RPC to improve the efficiency of both the development and execution of application programs. In the embodiments described herein, a library is a collection of non-volatile resources used by a computer program. In some examples, a library may include configuration data, documentation, help data, message templates, pre-written code, pre-written subroutines, and other similar resources for use in program development and execution. For example, a programmer writing more advanced computer programs can use a library to make system calls within the program instead of implementing those system calls multiple times during program development.

[0012] While code that is part of a program under development is typically designed to be used only within that single program, library code is designed to be utilized by multiple programs that are not connected to one another. For example, a library may be designed to be reused by independent programs or subprograms, where users need only know how to access or invoke the library program's external interface and not the library's internal details. This may facilitate reuse of program elements standardized within the library. For example, when a program under development invokes the library, it can obtain the operations implemented within the library without having to implement those operations itself. Each of the described aspects enables libraries to facilitate code sharing in a modular manner and facilitate code distribution.

[0013] As described above, DL is a mechanism by which a computer program, at run time, can load libraries (or other binaries / resources) into memory using RPC; obtain the addresses of functions and variables contained in the library; execute those functions or access those variables; and unload the library from memory. Many modern, open-source, high-performance RPC frameworks exist that can run in any computing environment (e.g., run on any hardware type or software platform). However, RPC frameworks often do not support cross-process invocation, and correspondingly, corresponding libraries cannot be unloaded when invoked or called by several different programs. This inability to unload resources can cause segmentation faults and errors in the program's functions and the general computing environment.

[0014] Various developments have addressed some of the segmentation fault issues in DL. Some computer systems, computer-implemented methods, and computer program products avoid the segmentation faults that occur when known RPC frameworks attempt to unload shared libraries by utilizing containers to clean runtime resources when the shared library is unloaded. The containers enable the ability to safely unload shared libraries and clean the execution environment. However, for multiple dependent or interdependent libraries, the problem still exists where, during the library unload process, a dependent library remains activated while the activated library is unloaded.

[0015] The systems and methods herein enable improved resource unloading in containerized environments that use multiple dependent or interdependent resources. The systems and methods utilize a Shared Library Correlation Table (SLCT) to track the status of invoked or loaded resources, thereby providing additional avoidance of segmentation faults that can occur when multiple dependent or interdependent resources / libraries are loaded / unloaded into memory or a container.

[0016] FIG. 1 illustrates a block diagram of a system 100 according to one embodiment. For ease of explanation and discussion, the embodiments and examples described herein are described with reference to standard open-source computer programs and languages; however, it should be understood that the systems and methods may be utilized with any suitable computer program. For example, the open-source programs “libld.so” and “ld-linux.so” are standard programs that may be implemented or written into a computer program. In some examples, the libld.so program locates and loads shared objects (shared libraries) required by a program, prepares the loaded objects for execution, and executes the loaded objects. Thus, the libld.so program is a dynamic linker / loader that provides DL, as described above. In some examples, libld.so includes various built-in functions, including dlopen() / dlsym() / dlclose(), for loading, calling, and unloading other shared libraries, as described in more detail herein.

[0017] For illustrative purposes, various embodiments described herein use a containerized libld.so (i.e., a containerized dynamic linker / loader) and a target shared library (i.e., a shared library to be loaded / unloaded). In the examples herein, the shared library / resource has the suffix “.so.” For example, the program instructions / functions “libtarget_go.so,” “libgrpc.so,” and “libld.so” are shared libraries (these are example names; shared libraries can have any name). However, “libld.so” (or ld.so) is a special shared library in that it is a dynamic linker / loader that provides dlopen() / dlsym() / dlclose() for loading / unloading other shared libraries within a container environment, as described herein.

[0018] Referring back to FIG. 1 , system 100 includes a host 110 that communicates with containerization platforms 150 and 170 via stack processing module 140. Host 110 includes a set of software instructions (or computer code) 111 and a DL interceptor module 120. Computer code 111 includes a plurality of instructions, including open instructions 112 including a dlopen() command to load a resource, function instructions 113 including a dlsym() command to extract content from the resource, and close instructions 114 including a dlclose() command to unload the resource. In some examples, computer code 111 is a program / application that loads a shared library, such as “libtarget_go.so” or resource 155. The program instructions dlopen() / dlsym() / dlclose() in computer code 111 are three functions provided by libld.so 152 to load a shared library, such as resource 155. Computer code 111 illustrates the process of loading / unloading the shared library libtarget_go.so by utilizing mocked dlopen() / dlsym() / dlclose() provided by a mocked dynamic linker / loader (i.e., libld.so) in DL interceptor module 120.

[0019] In some examples, DL interceptor module 120 manages the container lifecycle for containerized shared libraries. DL interceptor module 120 includes session lifecycle management module 122 and container handling module 121. Container handling module 121 creates / destroys containers (such as containerization platforms 150 and 170) and delivers data and function requests from host 110 to the containers. Session lifecycle management module 122 manages the session lifecycle, which includes creating / destroying sessions for the containers, where the session and its associated data (e.g., session ID) are used to communicate with the container when a DL function is received.

[0020] System 100 also includes stack processing module 140, which converts between stacks and protocol buffers 143. In some examples, protocol buffers are a language-neutral, platform-neutral, and extensible mechanism for serializing structured data. A user of system 100 can define how data is structured once using stack processing module 140 and then use the generated source code to easily write and read the structured data to and from various data streams using various programming languages. System 100 also includes containerization platform 150 and containerization platform 170, which are initiated by DL interceptor module 120. Containerization platform 150 and containerization platform 170 each include associated mapping stub modules 151 and 171, which are described in more detail herein.

[0021] In some examples, DL interceptor module 120 and mapping stub modules 151 and 171 communicate with each other through stack processing module 140, which converts and distributes data to various modules. In some examples, mapping stub modules 151 and 171 load target shared libraries into memory address spaces by utilizing libdl.so 152 and 172 in their respective containers. Mapping stub modules 151 and 171 record a mapping between the session ID and data handler of each container. Thus, when a DL function is received by DL interceptor module 120, data is routed to the target library. Furthermore, when a dlclose() request is received by DL interceptor module 120, DL interceptor module 120 destroys the associated container and invalidates the session ID.

[0022] In some examples, computer code 111 calls or invokes libld.so, such as when an SLCT is not utilized. However, libld.so cannot clean up the entire environment when unloading dependent libraries invoked during various function calls to libld.so. For example, libld.so 152 may cause errors, such as segmentation fault errors, during unloading that affect computer code 111 if invoked dependent libraries are still loaded. To prevent these errors, DL interceptor module 120 includes mocked libld.so 130 with an SLCT, which is described in more detail in conjunction with FIGS. 2-5. In some examples, computer code 111 is intercepted by mocked libld.so 130 instead of the real libld.so to provide an SLCT and prevent segmentation faults, as described herein.

[0023] In some examples, DL interceptor module 120 is configured to manage the container lifecycle and deliver data and function requests from computer code 111 to containerization platforms 150 and 170. DL interceptor module 120 also manages session lifecycles. For example, DL interceptor module 120 unloads shared libraries by destroying the containers that have the shared libraries therein. Therefore, any unexpected errors that occur in the containers do not affect the applications / programs located on the hosts.

[0024] The mocked libld.so 130 receives requests from the computer code 111, which are handled and delivered to the real "libld.so" (e.g., libld.so 152) upon creation of the respective container environment by the DL interceptor module 120. For example, the DL interceptor module 120 also includes session lifecycle management modules 122 and 121 configured and arranged as shown. The session lifecycle management module 122 creates a session structure corresponding to the unique session structure of one program / application. The session structure includes a "session ID," which is a "target shared library name." When the customized container starts up, the "target shared library name" is loaded by the dynamic linker / loader (libld.so) within the container.

[0025] For the container handling module 121, DL means "dynamic link," and "dynamic link library" has the same meaning as "shared library." Therefore, "DL name" is the dynamic link library name, which is the shared library name. Therefore, the container handling module 121 provides functions to manage containers. For example, the container handling module 121 provides the Init() and Destroy() functions. Init (session ID, DL name) creates a container and passes the DL name (shared library name) to the container. This allows the dynamic linker / loader (libld.so) to know which shared library needs to be loaded within the container. Destroy() destroys the created container.

[0026] As discussed above, the container and DL interceptor module 120 communicate through stack processing module 140. Stack processing module 140 includes analysis and transition module 141, which is communicatively coupled to call stack 142 and protocol buffer 143. Generally, a call stack is a stack data structure that stores information about active subroutines of a computer program. While call stack maintenance is critical for the correct functioning of most software, the details are typically hidden and performed automatically in high-level programming languages. Many computer instruction sets provide special instructions for manipulating stacks. While call stacks are used for several related purposes, the primary reason for having a stack is to keep track of the point to which control should be returned when each active subroutine finishes execution. An active subroutine is one that has been called but has not yet completed execution, after which control should be returned to the point of the call. Such subroutine activations can be nested to any level (recursion being a special case).

[0027] In some examples, the parsing and migration module 141 of the stack processing module 140 is responsible for performing the main work of the stack processing module 140. For example, parameters of computer code in "stack" format are difficult to transfer, while parameters in protocol buffer format are easy to transfer. In some examples, the parsing and migration module 141 provides two parameter manipulation methods, namely, Pack() and UnPack(), to perform the conversion. The stack processing module 140 reads parameters from the call stack 142 of the executing computer code and then converts the parameters to protocol buffer format (i.e., protocol buffers 143). The stack processing module 140 may also convert parameters from the protocol buffer format and then write the parameters back to the call stack 142 of the computer code. It should be noted that, via the parsing and migration module 141, the stack processing module 140 provides two parameter manipulation methods, namely, Pack() and UnPack(). The Pack() method reads parameters from the call stack 142 of the executing computer code and then converts the parameters into protocol buffer format (i.e., protocol buffer 143). The UnPack() method converts the parameters from protocol buffer format and then writes the parameters to the call stack 142 of the computer code.

[0028] Containerization platforms 150 and 170 include mapping stub modules 151 and 171, a libld.so set of commands / functions (libld.so 152 and libld.so 172), and a libtarget_go.so set of commands / functions (commands 152a-n and 172a-n). Generally, containerization platforms 150 and 170 may be open-source containerization platforms configured and arranged for building, deploying, and managing containerized applications. Open-source containerization platforms enable developers to package applications into containers. A container is a standardized executable component that combines an application's source code and the operating system (OS) libraries and dependencies necessary to run that code in any environment.

[0029] In some instances, containers and containerization platforms simplify the delivery of distributed applications and are becoming increasingly popular as organizations move toward cloud-native development and hybrid multicloud environments. Open-source containerization platforms serve as toolkits that enable developers to build, deploy, run, update, and stop containers using simple commands and low-effort automation through a single API. Containers are made possible by process isolation and virtualization features built into the Linux kernel. These features, such as control groups (Cgroups) for allocating resources among processes and namespaces for restricting process access or visibility to other resources or areas of the system, allow multiple application components to share the resources of a single instance of a host operating system.

[0030] More specifically, referring to containerized platforms 150 and 170, containerized platform 150 is a container that includes mapping stub module 151, dynamic linker / loader 152 (i.e., libdl.so), and other shared or target libraries, such as libtarget_go.so, and resources 155. When computer code 111 invokes close instruction 114, system 100 uses DL interceptor module 120 to destroy the entire containerized platform 150. Therefore, all functions within the container are destroyed. Any failures (e.g., segmentation faults) that occur within the container do not affect the language environment of system 100. However, if a function, such as function 155c in resources 155, calls a shared resource, such as function 175a in resources 175, a segmentation fault may occur if the associated memory space is not released (e.g., container 170 is not destroyed).

[0031] In some examples, mapping stub module 151 loads the real libld.so, i.e., dynamic linker / loader 152, into the memory address space of containerized platform 150. Mapping stub module 171 loads the real libld.so, i.e., resource 172, into the memory address space of containerized platform 170. libld.so 152 loads libtarget_go.so into the memory address space of containerized platform 150. A map between session IDs and handlers is then recorded by mapping stub module 151. When a DL function comes in, the data and dlsym() request are routed to the target library. The "libld.so function adapt" module receives protocol buffer data from the host. Mapping stub module 151 maintains a map of session IDs and handlers so that when a dlsym() request comes in, mapping stub module 151 knows the target location to which the request should be routed.

[0032] "libtarget.go.so" is a shared library that contains several functions, such as functions 155a-155n (e.g., "func1()", "func2()", "func3()", etc.). However, function 155c contains a call to another function in a different / dependent library, function 175a, which requires a SLCT, which is described in more detail herein in connection with Figures 2-5.

[0033] The operation of system 100 is illustrated in FIGS. 2, 3, and 4 and will be described with reference to various operational stages illustrated in FIGS. 2, 3, and 4, respectively, and the stages of method 500 illustrated in FIG. 5A. Because FIGS. 2 and 3 provide additional details of some of the components of system 100 illustrated in FIG. 1, these additional details will be introduced before describing the methodology illustrated in FIGS. 2, 3, and 4. As illustrated in FIG. 2, the "mocked-dlsym," "mocked-dlclose," and "mocked-dlopen" functions are contained within mocked libld.so 130. The existing "libld.so" includes "dlsym()," "dlclose()," and "dlopen()." By using the methodology illustrated in FIGS. 2-4, when computer code 111 invokes "dlsym()," "dlclose()," or "dlopen()," it actually invokes "mocked-dlsym," "mocked-dlclose," and "mocked-dlopen" within mocked libld.so 130. The mocked libld.so 130 routes function requests to the real libld.so in the containerized platforms 150 and 170.

[0034] 2, which illustrates a system flow block diagram of a system having a shared library correlation table according to one embodiment. As shown in flow 200 of FIG. 2, when computer code 111 invokes a dlopen function, such as open instruction 112, DL interceptor module 120 intercepts open instruction 112 in step 201 as a mocked dlopen 203 in a mocked libdl.so shared library in module 130. Upon receiving the mocked dlopen 203, session lifecycle management module 122 creates a session structure. In some examples, upon receiving the mocked dlopen 203, session lifecycle management module 122 creates a unique session structure for each piece of computer code (e.g., computer code 111). The session structure, which includes a unique session ID, includes a dynamic link library name, and invokes various container operations, such as Init() to initialize a container, destroy() to destroy a container, and invoke() to invoke real functions within the container.

[0035] In some examples, the container handling module 121 implements container operations to initialize the containerized platforms 150 and 170, destroy the containerized platforms 150 and 170, and deliver any dlsym() requests to the containerized platforms 150 / 170.

[0036] Referring to FIG. 3, a system flow block diagram is shown for a call function using a shared library correlation table in containerized platform 150, "libtarget_go.so." "libtarget_go.so" is an exemplary name for the shared library. The example described herein allows the shared library "libtarget_go.so" to be completely unloaded without causing a segmentation fault in the system.

[0037] Returning to Figure 2, in the case of dlopening, when an end user invokes the dlopen function, a "mocked" dlopen in the libdl.so shared library is actually invoked. In the next step, the mocked dlopen communicates with the session lifecycle management module 122. The session lifecycle management module 122 creates a session structure that includes a new UUID as the session ID; a new DL name that is the target shared library to be loaded; a registered container operation provided by the container handling module 121; and a registered parameter operation provided by the stack processing module 140. In the next step, the mocked dlopen creates a new container using the Init() method.

[0038] In some examples, mocked libld.so 130 intercepts open instruction 112 in step 202 and initiates SLCT 250 in mocked libdld.so 130. For example, module 130 generates a shared library correlation table (SLCT), such as SLCT 250, for mock resources in DL interceptor module 120, including reference counts for multiple resources, including at least one executable resource and at least one shared resource. For example, in SLCT 250, index[1] in index number field 251 points to executable resource libtarget_go.so, and index[2] points to shared resource libssl.so. Index[1] and index[2] each include a reference count associated with reference count field 254. SLCT 250 also includes running status or state field 252, containerized value field 253, dependent index field 255, and container ID field 256. In some examples, mocked libld.so 130 also updates and modifies SLCT 250 upon receiving shared object information in executable information 260 and target information 265, as described in more detail in connection with FIG. 5.

[0039] Referring back to dlsym shown in FIG. 3 , when the containerization platform 150 invokes the dlsym function in step 310 of flow 300, the stack processing module 140 sends the function to the DL interceptor module 120 in step 315, which invokes the mocked dlsym 210 and mocked dlclose 220 in the libdl.so shared library. The DL interceptor module 120 uses the SLCT 250 to determine the various invoked resources (including the invoked library and shared / dependent libraries). In step 320, the mocked dlsym is provided to the session lifecycle management module 122, which utilizes the Pack() method registered by the stack processing module 140 to convert parameters from the stack to a protocol buffer 143. In step 325, the mocked dlsym utilizes the invoke() method registered by the container handling module 121. As shown in Figure 1, the mocked dlsym takes the results and parameters and then utilizes the UnPack() method to convert them from the protocol buffer 143 to the stack.

[0040] If the libraries are interdependent, mocked libld.so 130 receives a call package to an executable resource within the interceptor module, where the call package is provided to the interceptor module by the stack processing module. The mocked libld.so 130 determines the number of dependent resources for the target resource from the dependency value, compares the containerized value with the target resource, and selects a container identification from the SLCT for the target resource. The mocked libld.so 130 provides the call package and container identification to the session management module for invoking the call package.

[0041] In some examples, the Init() method creates a container and uses the host image as the base image. System directories, especially library directories, are mapped to the container on the host, and the mapping stub module 151 is initialized. The mapping stub module 151 loads libld.so into the address space. In the next step, protocol buffer data is passed to the container, including the session ID, target library name, and function name. dlopen() is used by libld.so to load the target library into the address space. dlopen() returns a handler, which is used by dlsym() and dlclose(). In the next step, the session ID is mapped to the handler created in the previous step. In the next step, the destroy() method destroys the created container.

[0042] In another example, the invoke() method passes protocol buffer data to the mapping stub module 151, including the session ID, function name, and function parameters. In the next step, the mapping stub module 151 obtains the handler by the session ID. In the next step, the mapping stub module 151 invokes the target function by utilizing libld.so with the handler, function name, and function parameters. In the next step, libld.so invokes the actual function.

[0043] 4, in the next step, when an end user invokes the dlclose function, the dlclose call actually invokes a mocked dlclose in the libdl.so shared library. During the close function, the mocked libld.so 130 selects an entry in the SLCT 250, decrements the reference count of the selected entry in the SLCT, verifies the status of the selected entry based on the reference count, and, if the status of the selected entry indicates that the associated container is not a shared resource, deletes the associated container of the selected entry from memory. In some examples, the mocked dlclose invalidates the session ID in the session structure, destroys the container using the destroy() method, and releases the session structure.

[0044] 5A and 5B illustrate methods 500 and 550, respectively, for a shared library correlation table. Method 500 begins at block 502, where mocked libld.so 130 receives an open function call for an executable resource in an interceptor module before generating an SLCT. For example, mocked libld.so 130 receives an open instruction 112, as shown in FIG. 2.

[0045] At block 504, mocked libld.so 130 generates an SLCT including reference counts for multiple resources in the mock resource at the interceptor module. The resources include at least one executable resource and at least one shared resource. For each of the multiple resources, the mocked libld.so 130 starts a status in the SLCT at block 506. For example, referring to FIG. 2 , in response to receiving the open instruction 112, mocked libld.so 130 starts an SLCT 250 including reference counts for multiple resources including at least one executable resource and at least one shared resource. In some examples, the SLCT 250 includes, in index number field 251, index[1], which points to the executable resource libtarget_go.so, and index[2], which points to the shared resource libssl.so. Each of index[1] and index[2] includes an associated reference count in reference count field 254. The SLCT 250 also includes a running status or state field 252, a containerized value field 253, a dependent index field 255, and a container ID field 256. In some examples, the mocked libld.so 130 also updates and modifies the SLCT 250 upon receiving shared object information and target information 265 in the executable information 260.

[0046] At block 508, mocked libld.so 130 determines the number of dependent resources for the target resource from the dependency values ​​and determines a first set of dependent required resources for the resource's executable level in the SLCT at block 510. At block 512, mocked libld.so 130 determines a second set of dependent required resources based on the first set of dependent required resources. For example, mocked libld.so 130 determines various shared and interrelated resources for libtarget_go.so and libssl.so using the DT_needed function. In some examples, mocked libld.so 130 continues determining dependent required resources until all resources (including called and related resources) have been identified in the SLCT 250.

[0047] At block 514, mocked libld.so 130 increments an associated reference count for each of the multiple resources for each associated dependent required resource. For example, mocked libld.so 130 increments the associated count in column 254 based on the number of resources depending on the index [ ] row. At block 516, mocked libld.so 130 determines a status from the associated reference count in the SLCT. For example, in the SLCT 250, if the associated reference count in column 254 is greater than 0, each of the multiple resources is in a loaded state, and if the associated reference count is 0, each of the multiple resources is in an unloaded state. In some examples, the status is listed in status column 252 of the SLCT 250.

[0048] At block 518, mocked libld.so 130 identifies a containerized value and a containerized identification for each resource of the plurality of resources. For example, mocked libld.so 130 identifies and populates fields 252 and 256 with a nominal identification (e.g., a value) in value field 253 and a container identification in container ID field 256. Once the various fields of SLCT 250 have been populated, method 500 proceeds to block 520.

[0049] At block 520, mocked libld.so 130 determines whether a close function call has been received. In one example where a close function call has not been received, mocked libld.so 130 utilizes the SLCT during performance of the various processes described with respect to method 550 of FIG. 5B.

[0050] For example, at block 552 of method 550 of FIG. 5B, mocked libld.so 130 receives a call function package to a target resource of multiple resources in the interceptor module from the stack processing module. In some examples, the call function may originate from containerization platforms 150 and 170 or through host 110, as shown in FIG. 3. At block 554, mocked libld.so 130 determines the number of dependent resources for the target resource from the dependency value, compares the containerized value to the target resource, and selects a container identification from the SLCT for the target resource at block 556. At block 558, mocked libld.so 130 provides the call function package and container identification to the session management module for invocation of the call function package.

[0051] 5A , if mocked libld.so 130 determines that a close function call has been received, method 500 proceeds to block 522. For example, mocked libld.so 130 receives a close instruction 414 from either the container environment or the host 110 to close a given resource. During the mocked close function, at block 522, mocked libld.so 130 selects an entry in an SLCT, such as SLCT 250, based on the close instruction 114 and, at block 524, decrements the reference count of the selected entry in the SLCT. For example, mocked libld.so 130 selects index [1] to close and decrements the reference count in field 254 from 1 to 0. In some examples, mocked libld.so 130 then proceeds to the dependent index shown in dependent index for close field 255.

[0052] At block 526, mocked libld.so 130 verifies the status of the selected entry based on the reference count, and at block 528, if the status of the selected entry indicates that the associated container is not a shared resource, causes the selected entry's associated container to be removed from memory. For example, as shown in FIG. 4, index [1] indicates that libtarget_go.so has a reference count of “0,” indicating an unloaded state, and session lifecycle management module 122 causes the container associated with the container ID in container ID column 256 to be removed from memory.

[0053] In some examples, at block 527, if the current state of the selected entry indicates that the selected entry is loaded, such as the libc.so.1 resource at index [4] in FIG. 4, mocked libld.so 130 causes the selected entry's associated container to remain in memory. In both examples, at blocks 528 and 527, mocked libld.so 130 selects the next remaining entry in SLCT 250 to unload by returning to block 522 until SLCT 250 indicates all resources / indexes associated with close instruction 414 have been unloaded. Use of the SLCT allows shared resources to be unloaded without causing segmentation associated with the shared resource and associated processes.

[0054] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). With respect to any flowchart, depending on the technology involved, it is possible to perform operations in an order different from that shown in the particular flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in the reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0055] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") collectively included in a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as punch cards or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data typically moves at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not qualify the storage device as transient, as data is not transient while it is stored.

[0056] 6 illustrates details of a computing environment 600 according to one embodiment. The computing environment 600 includes an example environment for executing at least a portion of the computer code involved in performing the methods of the present invention, such as the SLCT 250 and DL interceptor module 120 in block 700. In addition to block 700, the computing environment 600 includes, for example, a computer 601, a wide area network (WAN) 602, an end user device (EUD) 603, a remote server 604, a public cloud 605, and a private cloud 606. In this embodiment, the computer 601 includes a processor set 610 (including processing circuitry 620 and cache 621), a communications fabric 611, volatile memory 612, persistent storage 613 (including an operating system 622 and block 700, as described above), a peripheral device set 614 (including a user interface (UI) device set 623, storage 624, and an Internet of Things (IoT) sensor set 625), and a network module 615. The remote server 604 includes a remote database 630. The public cloud 605 includes a gateway 640, a cloud orchestration module 641, a set of host physical machines 642, a set of virtual machines 643, and a set of containers 644.

[0057] Computer 601 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 630. As is well understood in the art of computer technology, and in accordance with such technology, execution of a computer-implemented method may be distributed among multiple computers and / or among multiple locations. While, in this description of computing environment 600, to keep the description as concise as possible, the detailed discussion focuses on a single computer, and in particular computer 601. Computer 601 may be located in a cloud, even though it is not depicted in the cloud in FIG. 1 . However, it is not required that computer 601 be in a cloud, except where expressly indicated at all.

[0058] Processor set 610 includes one or more computer processors of any type now known or later developed. Processing circuitry 620 may be distributed across multiple packages, e.g., multiple integrated circuit chips linked together. Processing circuitry 620 may implement multiple processor threads and / or multiple processor cores. Cache 621 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores running on processor set 610. Cache memory is typically divided into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located "off-chip." In some computing environments, processor set 610 may be designed to operate with qubits and perform quantum computing.

[0059] Computer-readable program instructions are typically loaded onto computer 601 and cause processor set 610 of computer 601 to perform a series of operational steps, thereby implementing a computer-implemented method. As a result, the instructions so executed instantiate the method set forth in the flowcharts and / or descriptions of the computer-implemented method (collectively, the "methods of the present invention") contained herein. These computer-readable program instructions are stored on various types of computer-readable storage media, such as cache 621 and other storage media described below. The program instructions and associated data are accessed by processor set 610 to control and direct the execution of the methods of the present invention. In computing environment 600, at least a portion of the instructions for executing the methods of the present invention may be stored in block 700 of persistent storage 613.

[0060] Communications fabric 611 is the signal-conducting pathway that allows various components of computer 601 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may also be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0061] Volatile memory 612 may be any type of volatile memory now known or later developed. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory 612 is characterized by random access, although this is not required unless expressly indicated. In computer 601, volatile memory 612 is located in a single package and is internal to computer 601; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 601.

[0062] Persistent storage 613 is any form of non-volatile storage for a computer, now known or later developed. The term non-volatile storage means that stored data remains regardless of whether power is supplied to computer 601 and / or to persistent storage 613 directly. Persistent storage 613 may be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be erased, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 622 may take several forms, such as various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that employ a kernel. The code contained in block 700 typically includes at least a portion of the computer code involved in performing the methods of the present invention.

[0063] Peripheral device set 614 includes a set of peripheral devices of computer 601. Data communication connections between peripheral devices and other components of computer 601 may be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cable (such as a universal serial bus (USB)-type cable), insertion-type connections (e.g., a secure digital (SD) card), connections made over a local area communication network, and even connections made over a wide area network such as the Internet. In various embodiments, UI device set 623 may include multiple components, such as a display screen, speakers, a microphone, wearable devices (such as goggles and a smartwatch), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. Storage 624 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 624 may be persistent and / or volatile. In some embodiments, storage 624 may take the form of a quantum computing storage device that stores data in the form of qubits. In embodiments where computer 601 needs to have large amounts of storage (e.g., computer 601 stores and manages large databases locally), this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 625 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0064] The network module 615 is a collection of computer software, hardware, and firmware that enables the computer 601 to communicate with other computers over the WAN 602. The network module 615 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or de-packetizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of the network module 615 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of the network module 615 are performed on physically separate devices, whereby the control function manages multiple different network hardware devices. Computer-readable program instructions for carrying out the methods of the present invention may be downloaded to the computer 601, typically from an external computer or external storage device, through a network adapter card or network interface included in the network module 615.

[0065] WAN 602 is any now known or later developed wide area network (e.g., the Internet) capable of communicating computer data between remote locations using any technology for communicating computer data. In some embodiments, WAN 602 may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0066] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 601) and may take any of the forms described above with respect to computer 601. EUD 603 typically receives useful and useful data from the operation of computer 601. For example, in a hypothetical case in which computer 601 is designed to provide advice to the end user, this advice would typically be communicated from network module 615 of computer 601 over WAN 602 to EUD 603. In this manner, EUD 603 can display or otherwise present this advice to the end user. In some embodiments, EUD 603 may be a client device such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0067] Remote server 604 is any computer system that provides at least some data and / or functionality to computer 601. Remote server 604 may be controlled and used by the same entity that operates computer 601. Remote server 604 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 601. For example, in the hypothetical case where computer 601 is designed and programmed to provide advice based on historical data, this historical data may be provided to computer 601 from remote database 630 of remote server 604.

[0068] A public cloud 605 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing capacity, without requiring direct, active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct, active management of the computing resources of the public cloud 605 is performed by computer hardware and / or software in a cloud orchestration module 641. The computing resources provided by the public cloud 605 are typically realized by virtual computing environments running on various computers comprising a host physical machine set 642, which is the entire set of physical computers included in and / or available to the public cloud 605. Virtual computing environments (VCEs) typically take the form of virtual machines in a virtual machine set 643 and / or containers in a container set 644. It is understood that these VCEs may be stored as images and may be transferred between various physical machine hosts either as images or after instantiation of the VCEs. The cloud orchestration module 641 manages the transfer and storage of images, deploys newly instantiated VCEs, and manages active instances of VCE deployments. The gateway 640 is a collection of computer software, hardware, and firmware that enables the public cloud 605 to communicate over the WAN 602.

[0069] Here, we provide some further explanation of virtual computing environments (VCEs). A VCE can be stored as an "image." From this image, a new, active instance of the VCE can be instantiated. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system where the kernel allows the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave as actual computers from the perspective of the programs running within them. A computer program running on a typical operating system can use all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to the container; this feature is known as containerization.

[0070] Private cloud 606 is similar to public cloud 605, except that the computing resources are available only for use by a single enterprise. While private cloud 606 is shown as interacting with WAN 602, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate, isolated entity, but is joined together in a larger hybrid cloud architecture by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both public cloud 605 and private cloud 606 are part of a larger hybrid cloud.

Claims

1. generating a shared library correlation table (SLCT) having reference counts of a plurality of resources, including at least one of executable resources and shared resources, in the mock resources in the interceptor module; initiating a status in the SLCT for each of a plurality of resources; selecting an entry in the SLCT during a close function; decrementing the reference count of the selected entry in the SLCT; verifying the status of the selected entry based on the reference count; and if the status of the selected entry indicates that the associated container is not a shared resource, causing the associated container of the selected entry to be deleted from memory. A method for providing the above.

2. The SLCT further includes an index number and a dependency index number for each resource of the plurality of resources, wherein generating the SLCT includes: determining a number of associated dependent required resources for the plurality of resources; and for each resource of the plurality of resources, incrementing a reference count associated with each of its associated dependent required resources; Contains The method of claim 1.

3. The SLCT further includes a containerized value, a dependency value, and a container identification for each resource in the SLCT, and initiating the status for each of the plurality of resources in the SLCT includes: determining the status from the associated reference count, wherein each resource of the plurality of resources is in a loaded state if the associated reference count is greater than zero, and each resource of the plurality of resources is in an unloaded state if the associated reference count is zero; and determining a containerized value and a containerized identification for each resource of the plurality of resources; The method of claim 2 further comprising:

4. receiving a call package to the executable resource at the interceptor module, the call package being provided to the interceptor module by a stack processing module; determining a number of dependent resources for the target resource from the dependency values; comparing the containerized value with the target resource to select a container identification from the SLCT for the target resource; and providing the call package, the container identification to a session management module for invocation of the call package; The method of claim 3 further comprising:

5. receiving an open function call for a target resource at the interceptor module, the open function call being provided to the interceptor module by a stack processing module; The method of claim 1 further comprising:

6. The method of claim 5 , wherein the interceptor module is in communication with a mapping stub module communicatively coupled to the stack processing module.

7. The method of claim 6 , wherein the mock resource is stored in the interceptor module.

8. 1. A system comprising: a memory communicatively coupled to a processor, the processor comprising: generating a shared library correlation table (SLCT) having reference counts of a plurality of resources, including at least one executable resource and at least one shared resource, in the mock resource in the interceptor module; for each of a plurality of resources, initiating a status in the SLCT; During the close function, selecting an entry in the SLCT; decrementing the reference count of the selected entry in the SLCT; verifying the status of the selected entry based on the reference count; and causing the associated container of the selected entry to be deleted from memory if the status of the selected entry indicates that the associated container is not a shared resource.

1. A system configured to perform operations including:

9. The SLCT further includes an index number and a dependency index number for each resource of the plurality of resources, wherein the procedure for generating the SLCT includes: determining a number of associated dependent required resources for the plurality of resources; and for each resource of said plurality of resources, incrementing a reference count associated with each of its associated dependent required resources; Contains The system of claim 8.

10. The SLCT further includes a containerized value, a dependency value, and a container identification for each resource in the SLCT, and the step of initiating the status for each of the plurality of resources in the SLCT includes: determining the status from the associated reference count, where each resource of the plurality of resources is in a loaded state if the associated reference count is greater than zero, and each resource of the plurality of resources is in an unloaded state if the associated reference count is zero; and determining a containerized value and a containerized identification for each resource of said plurality of resources; The system of claim 9 further comprising:

11. The operation is receiving a call package to the executable resource at the interceptor module, the call package being provided to the interceptor module by a stack processing module; determining the number of dependent resources for the target resource from the dependency values; comparing the containerized value with the target resource to select a container identification from the SLCT for the target resource; and providing the call package, the container identification to a session management module for invocation of the call package; The system of claim 10 further comprising:

12. The operation is receiving an open function call for a target resource at the interceptor module, the open function call being provided to the interceptor module by a stack processing module; The system of claim 8 further comprising:

13. The system of claim 12 , wherein the interceptor module is in communication with a mapping stub module communicatively coupled to the stack processing module.

14. The system of claim 13 , wherein the mock resource is stored in the interceptor module.

15. 1. A computer program product comprising a computer readable program stored on a computer readable storage medium, the computer readable program being such that when executed on a processor: generating a shared library correlation table (SLCT) having reference counts of a plurality of resources, including at least one executable resource and at least one shared resource, in the mock resource in the interceptor module; for each of a plurality of resources, initiating a status in the SLCT; During the close function, selecting an entry in the SLCT; decrementing the reference count of the selected entry in the SLCT; verifying the status of the selected entry based on the reference count; and causing the associated container of the selected entry to be deleted from memory if the status of the selected entry indicates that the associated container is not a shared resource. a computer program product for causing the processor to perform operations including:

16. The SLCT further includes an index number and a dependency index number for each resource of the plurality of resources, wherein the procedure for generating the SLCT includes: determining a number of associated dependent required resources for the plurality of resources; and for each resource of said plurality of resources, incrementing a reference count associated with each of its associated dependent required resources; Contains 16. A computer program product according to claim 15.

17. The SLCT further includes a containerized value, a dependency value, and a container identification for each resource in the SLCT, and the step of initiating the status for each of the plurality of resources in the SLCT includes: determining the status from the associated reference count, where each resource of the plurality of resources is in a loaded state if the associated reference count is greater than zero, and each resource of the plurality of resources is in an unloaded state if the associated reference count is zero; and determining a containerized value and a containerized identification for each resource of said plurality of resources; 17. The computer program product of claim 16, further comprising:

18. The operation is receiving a call package to the executable resource at the interceptor module, the call package being provided to the interceptor module by a stack processing module; determining a number of dependent resources for the target resource from the dependency values; comparing the containerized value with the target resource to select a container identification from the SLCT for the target resource; and providing the call package, the container identification to a session management module for invocation of the call package; 20. The computer program product of claim 17, further comprising:

19. The operation is receiving an open function call for a target resource at the interceptor module, the open function call being provided to the interceptor module by a stack processing module; 16. The computer program product of claim 15, further comprising:

20. the interceptor module in communication with a mapping stub module communicatively coupled to the stack processing module; and The mock resource is stored in the interceptor module.

20. The computer program product of claim 19.

Images