A method and corresponding device for managing dynamic library

Abstract

This application discloses a method for managing dynamic libraries, applicable to a computer system. The method includes: requesting at least one huge page memory for an application program marked as in huge page mode; mapping the dynamic libraries that the application program relies on to the virtual address space corresponding to the at least one huge page memory; and loading the dynamic libraries into the at least one huge page memory when the application program is running. The solution provided in an embodiment of the application, using huge page memory to load dynamic libraries, can improve the hit rate of TLB queries.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and corresponding device for dynamic library management. Background Art

[0002] With the advancement of software technology, software architecture in the communications technology (CT) field is also shifting towards service-oriented development. Core competitiveness in the CT field lies in performance. To facilitate software development and deployment, many applications are based on dynamic libraries, enabling dynamic orchestration capabilities.

[0003] Dynamic libraries are typically provided by third parties and stored in a dynamic library resource pool. When compiling application software, the required dynamic libraries are loaded from the dynamic library resource pool to complete the application's software development. When developing application software, dynamic libraries are typically not compiled into the application's target code; instead, they are simply marked. Only after the application software is started and running are the corresponding dynamic libraries loaded into the application's memory.

[0004] After loading, dynamic libraries are stored in multiple 4K physical pages of memory. When a computer system calls a dynamic library, it needs to query the page table entry of the physical page where the dynamic library is located, and then access the corresponding physical page. The page table entry of the physical page is stored in the page table, but the page table entry of the most recently accessed physical page is also cached in the translation lookaside buffer (TLB). Because the page table query overhead is very high, the computer system will first query the TLB. If the query hits, that is, the TLB includes the queried page table entry, the computer system can directly access the corresponding physical page based on the queried page table entry and call the dynamic library to be called. If the query misses (TLB miss), the page table needs to be queried, which will incur a large query overhead and affect memory access performance. Summary of the Invention

[0005] The present application provides a method for managing a dynamic library to improve the hit rate of a translation lookaside buffer (TLB). The present application also provides a corresponding apparatus, computer equipment, computer-readable storage medium, and computer program product.

[0006] In a first aspect, the present application provides a method for managing dynamic libraries, which is applied to a computer system, such as a server, a terminal device, a virtual machine (VM), or a container. The method comprises: applying for at least one huge page memory for an application marked as in huge page mode; mapping the dynamic libraries that the application depends on to the virtual address space corresponding to the at least one huge page memory; and loading the dynamic libraries into the at least one huge page memory when running the application.

[0007] In this application, a dynamic library is also called a dynamic link library (DLL). A DLL is a library containing code and data that can be used simultaneously by multiple programs. A dynamic library can also be understood as a file or function in the Executable and Linkable Format (ELF). The suffix of a dynamic library in Windows is .dll, and the suffix of a dynamic library in Linux is .so.

[0008] In this application, an application program refers to executable code configured to implement an application or implement a service.

[0009] In this application, a huge page, also known as a huge page memory, refers to a physical page that is multiple times larger than 4K, such as a 2M page or a 1G page. The huge page mode can be an indication that the application needs to use huge page memory.

[0010] In this application, the dynamic library that an application depends on refers to the dynamic library that the application will use when running.

[0011] In this application, the virtual address space refers to the range of virtual addresses corresponding to at least one large page memory.

[0012] In the present application, loading a dynamic library into at least one large page memory refers to loading / copying the code and data of the dynamic library into at least one large page memory.

[0013] In the first aspect, large page memory is used to store dynamic libraries. In this way, the number of large pages occupied by dynamic libraries of the same size is much smaller than the number of 4K physical pages occupied. When the page table entries of the large pages are cached in the TLB, they will not be quickly deleted due to too many page table entries in the TLB. When the application or other applications call the dynamic library, the page table entries of the dynamic library can be queried in the TLB, thereby improving the hit rate of the TLB query.

[0014] In the present application, the TLB includes an instruction translation lookaside buffer (iTLB) and a data translation lookaside buffer (dTLB), and the dynamic library includes a code segment and a data segment. The page table entries of the code segment can be cached in the iTLB. Using large page memory to store the code segment can improve the hit rate of querying the iTLB. Similarly, the page table entries of the data segment can be cached in the dTLB. Using large page memory to store the code segment can improve the hit rate of querying the dTLB.

[0015] In a possible implementation of the first aspect, when there are at least two dynamic libraries that the application depends on, the above-mentioned step of: mapping the dynamic libraries that the application depends on to the virtual address space corresponding to at least one large page memory includes: mapping the at least two dynamic libraries that the application depends on to the virtual address space corresponding to at least one large page memory in sequence, wherein the end address of the first dynamic library in the virtual address space is continuous with the starting address of the second dynamic library in the virtual address space or is located in two consecutive 4K virtual pages of the virtual address space, and the first dynamic library and the second dynamic library are two dynamic libraries among the at least two dynamic libraries that are continuously mapped to the virtual address space.

[0016] The above-mentioned step of: loading a dynamic library into at least one huge page memory when running an application includes: loading at least two dynamic libraries into at least one huge page memory in sequence when running the application, wherein the end address of the first dynamic library in the at least one huge page memory is continuous with the start address of the second dynamic library in the at least one huge page memory or is located in two consecutive 4K physical pages of the at least one huge page memory.

[0017] In this possible implementation, when there are at least two dynamic libraries that an application depends on, at least two dynamic libraries will be mapped to the virtual address space first in the order in which the dynamic libraries are called when the application is running. The addresses of the two adjacent dynamic libraries in the virtual address space in the mapping order can be continuous, or the end address of the first dynamic library in the virtual address space and the start address of the second dynamic library in the virtual address space can be located in two consecutive 4K virtual pages. This application realizes the splicing of at least two dynamic libraries in the huge page memory by mapping the addresses continuously or located in two consecutive 4K virtual pages, thereby improving the utilization rate of the huge page memory.

[0018] In a possible implementation of the first aspect, each of the at least two dynamic libraries includes a code segment and a data segment, and the step of sequentially loading the at least two dynamic libraries into at least one large page memory includes:

[0019] When the code segment and the data segment of each dynamic library are loaded into the at least one large page memory, the code segment of each dynamic library is continuously stored in the at least one large page memory, and the data segment of each dynamic library is continuously stored in the at least one large page memory.

[0020] In this possible implementation, each dynamic library may include a code segment (.text), a data segment (.data), and a BSS segment (.bss). The code segment (.text) is a collection of executable instructions; the data segment (.data) and the BSS segment (.bss) are collections of data, wherein the data segment (.data) represents initialized data, and the BSS segment (.bss) represents uninitialized data. From the perspective of the executable program, if a piece of data is not initialized, there is no need to allocate space for it, so the difference between .data and .bss is that .bss does not occupy the size of the executable file, but only records how much space is needed to store these uninitialized data without allocating actual space.

[0021] In this application, the data segment includes the data segment (.data) and the BSS segment (.bss).

[0022] In the present application, the code segment of each dynamic library is stored continuously in at least one huge page memory, and the data segment of each dynamic library is stored continuously in at least one huge page memory. In this way, when the code segment in a certain huge page is loaded into the cache, the probability of loading the continuous code segments into the instruction cache at the same time is increased.

[0023] In a possible implementation of the first aspect, the method further includes: modifying an original address of a call initiation location of a calling function calling the first dynamic library according to a function address of the first dynamic library, the first dynamic library being one of the dynamic libraries on which the application depends, and the calling function being contained in the application or in other dynamic libraries on which the application depends; when calling the first dynamic library by running the calling function, the first dynamic library is called according to the function address of the first dynamic library at the call initiation location.

[0024] In this possible implementation, the function of the call function is to initiate a call to the first dynamic library, and the call initiation position refers to the position in the call function that initiates the call to the first dynamic library. In the prior art, the original address of the call initiation position of the call function is usually the address of the procedure link table (PLT). Then, it will jump to the PLT through the address of the PLT, and then jump to the global offset table (GOT) through the PLT, and call the corresponding dynamic library through the GOT. This two jumps affect the processor's execution efficiency of instructions. In the present application, the function address of the first dynamic library is directly modified to the call initiation position of the call function to replace the original address of the call initiation position. In this way, when the call function calls the first dynamic library, it can directly call the first dynamic library according to the function address of the first dynamic library at the call initiation position, which is equivalent to achieving a direct pass from the call function to the first dynamic library function without having to jump twice through the PLT and GOT, thereby improving the processor's execution efficiency of instructions.

[0025] In a possible implementation manner of the first aspect, the method further includes: using a relocation table to determine a call initiation location of the calling function to the first dynamic library, the relocation table including a call initiation location of the calling function to the first dynamic library.

[0026] In this possible implementation, the relocation table records the call initiation locations of all calling functions in the application or the corresponding dynamic library to each dynamic library. Therefore, the relocation table can be used to quickly determine the call initiation location.

[0027] In a possible implementation of the first aspect, the method further includes:

[0028] When the calling function is compiled, the calling initiation position of the calling function calling the first dynamic library is saved in the relocation table.

[0029] In this possible implementation, during the application compilation stage or the dynamic library compilation stage, when a calling function is compiled therein, the calling initiation position of the calling function is saved in the relocation table.

[0030] In a possible implementation of the first aspect, the method further includes: when running the calling function, pushing the location information of the next instruction of the calling function's first call to the first dynamic library into a stack; determining the call initiation location of the calling function's call to the first dynamic library based on the location information of the next instruction in the stack; and saving the call initiation location of the calling function's call to the first dynamic library in a relocation table.

[0031] In this possible implementation, the application may also be called an application process during the running phase. During the application running phase, when the calling function is reached, the location information of the next instruction of the calling function will be pushed into the stack. In this way, the call initiation position of the calling function to the first dynamic library can be determined based on the location information of the next instruction in the stack, thereby saving the call initiation position of the calling function to the first dynamic library into the relocation table.

[0032] In a possible implementation of the first aspect, the method further includes: when loading the calling function, scanning the code segment of the calling function to obtain the call initiation location of the calling function calling the first dynamic library; and saving the call initiation location of the calling function to the first dynamic library in a relocation table.

[0033] In this possible implementation, the call initiation location of the calling function calling the first dynamic library is determined by scanning the code segment of the calling function, thereby obtaining a relocation table containing the call initiation location of the calling function calling the first dynamic library.

[0034] In a possible implementation of the first aspect, the method further includes: unloading a second dynamic library in the dynamic library on which the application depends; clearing multiple 4K virtual pages corresponding to the second dynamic library on a bitmap, and the bitmap records the mapping position of the dynamic library on which the application depends in the virtual address space with 4K virtual pages as the granularity.

[0035] In this possible implementation, dynamic libraries are frequently unloaded and loaded during the application's runtime. To facilitate the management of the dynamic library's use of virtual address space and large page memory, this application uses a bitmap based on 4K virtual pages to manage dynamic libraries. The bitmap records the virtual addresses occupied by dynamic libraries at a 4K granularity. After the second dynamic library is unloaded, the bitmap clears the information about the second dynamic library on the 4K virtual page corresponding to the second dynamic library.

[0036] In a possible implementation of the first aspect, the method further includes: mapping a third dynamic library in a virtual address space vacated by uninstalling the second dynamic library; and recording a mapping relationship between the third dynamic library and the corresponding virtual address space on a bitmap.

[0037] In this possible implementation, after the second dynamic library is unloaded, a blank virtual address space will be vacated. When loading a new third dynamic library, the third dynamic library can be mapped to the virtual address space vacated due to the unloading of the second dynamic library. In this way, the utilization rate of the virtual address space can be improved.

[0038] In a possible implementation manner of the first aspect, the method further includes: when all virtual address spaces corresponding to any large page memory in the at least one large page memory are in an idle state, releasing any large page memory.

[0039] In this possible implementation, when the virtual address spaces corresponding to one or more huge page memories are all in an idle state, the one or more huge page memories can be released, thereby improving the utilization of the huge page memories.

[0040] In a second aspect, the present application provides a device for managing a dynamic library, which has the function of implementing the method of the first aspect or any possible implementation of the first aspect. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above-mentioned functions, for example: a first processing unit, a second processing unit, a third processing unit, and a fourth processing unit. These four processing units can be implemented by one processing unit or multiple processing units.

[0041] In a third aspect, the present application provides a computer device comprising at least one processor, a memory, an input / output (I / O) interface, and computer-executable instructions stored in the memory and executable by the processor. When the computer-executable instructions are executed by the processor, the processor executes the method according to the first aspect or any possible implementation of the first aspect.

[0042] The fourth aspect of the present application provides a computer-readable storage medium storing one or more computer-executable instructions. When the computer-executable instructions are executed by a processor, one or more processors execute the method as described in the first aspect or any possible implementation of the first aspect.

[0043] The fifth aspect of the present application provides a computer program product that stores one or more computer-executable instructions. When the computer-executable instructions are executed by one or more processors, the one or more processors execute the method as described in the first aspect or any possible implementation of the first aspect.

[0044] A sixth aspect of the present application provides a chip system, comprising at least one processor, the at least one processor being configured to support a device for managing a dynamic library in implementing the functions described in the first aspect or any one of the possible implementations of the first aspect. In one possible design, the chip system may further include a memory for storing program instructions and data necessary for the device for managing the dynamic library. The chip system may be comprised of a chip or may include a chip and other discrete components. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1is a schematic diagram of an embodiment of a computer system provided in an embodiment of the present application;

[0046] Figure 2 1 is a schematic diagram of an embodiment of a method for managing a dynamic library provided in an embodiment of the present application;

[0047] Figure 3 This is a schematic diagram of a scenario of a method for managing a dynamic library provided in an embodiment of the present application;

[0048] Figure 4A This is a schematic diagram of an example of a method for managing a dynamic library provided in an embodiment of the present application;

[0049] Figure 4B This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0050] Figure 5 This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0051] Figure 6A This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0052] Figure 6B This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0053] Figure 7A This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0054] Figure 7B This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0055] Figure 8 This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0056] Figure 9 This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0057] Figure 10 This is another example schematic diagram of the method for managing dynamic libraries provided in an embodiment of the present application;

[0058] Figure 11 1 is a schematic diagram of a structure of a device for managing a dynamic library provided in an embodiment of the present application;

[0059] Figure 12 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present application, rather than all the embodiments. Those skilled in the art will appreciate that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0061] The terms "first," "second," and the like in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," as well as any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to these processes, methods, products, or apparatus.

[0062] The present application provides a method for managing dynamic libraries to improve the hit rate of a translation lookaside buffer (TLB). The present application also provides corresponding apparatus, computer equipment, computer-readable storage media, and computer program products. These are described in detail below.

[0063] The method for managing dynamic libraries provided in an embodiment of the present application is applied to a computer system, which may be a server, a terminal device, a virtual machine (VM), or a container.

[0064] A terminal device (also known as user equipment (UE)) is a device with wireless transceiver capabilities that can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; on water (such as ships); or in the air (for example, on airplanes, balloons, and satellites). The terminal can be a mobile phone, a tablet computer, a computer with wireless transceiver capabilities, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal used in industrial control, a wireless terminal used in self-driving cars, a wireless terminal used in remote medical care, a wireless terminal used in smart grids, a wireless terminal used in transportation safety, a wireless terminal used in smart cities, or a wireless terminal used in smart homes.

[0065] The architecture of the computer system can be found in Figure 1 Understand. Figure 1 A schematic diagram of the architecture of a computer system.

[0066] like Figure 1 As shown, the architecture of the computer system includes a user layer 10 , an operating system 20 and a hardware layer 30 .

[0067] The user layer 10 includes multiple applications (APPs), each of which can include one or more business microservices. Each business microservice can correspond to an operation. For example, an application involving a user login scenario includes two microservices. The first business microservice can be used to process user login and change the user's status to the logged-in status. The second business microservice can be a business microservice that records traffic and records the traffic used to modify the user status.

[0068] The operating system (OS) 20 is used to load and run each application. The OS 20 consists of user mode and kernel mode. When loading an application, the OS 20 allocates memory for the application in kernel mode, loads the application's executable and linkable format (ELF) file, and then switches to user mode to execute the dynamic library interpreter to load the dynamic library. The dynamic library interpreter first maps the dynamic library to the virtual address space and then loads the dynamic library into physical memory when the application is running.

[0069] A dynamic library, also known as a dynamic link library (DLL), is a library containing code and data that can be used simultaneously by multiple programs. A dynamic library can also be understood as a file or function in the Executable and Linkable Format (ELF). The suffix for a dynamic library in Windows is .dll, while in Linux it's .so.

[0070] The hardware layer 30 includes a communication interface, a processor, physical memory, a memory management unit (MMU), and a bus. The communication interface, processor, physical memory, and MMU are connected via a bus. The processor may include any type of general-purpose computing circuit or dedicated logic circuit, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). It may also be one or more processors coupled to one or more semiconductor substrates, such as a central processing unit (CPU). The physical memory can be configured as multiple memory spaces.

[0071] The MMU is a piece of computer hardware responsible for processing memory access requests from the central processing unit (CPU). Its functions include translating virtual addresses into physical addresses, protecting memory, and controlling the CPU cache.

[0072] Based on the above computer system, the embodiment of the present application provides a method for managing dynamic libraries. Figure 2 As shown, an embodiment of the method for managing a dynamic library provided by an embodiment of the present application includes:

[0073] 101. The computer system requests at least one large page of memory for an application program marked as in large page mode.

[0074] In the embodiments of the present application, an application program refers to an executable code configured to implement an application or implement a service.

[0075] In the embodiment of the present application, a huge page, also known as a huge page memory, refers to a physical page that is multiple times larger than 4K, such as a 2M page or a 1G page. The huge page mode can be an indication information indicating that the application needs to use huge page memory.

[0076] 102. The computer system maps the dynamic library that the application depends on to the virtual address space corresponding to at least one large page memory.

[0077] In the embodiment of the present application, the dynamic library that the application depends on refers to the dynamic library to be used by the application when running.

[0078] In the embodiment of the present application, the virtual address space refers to the range of virtual addresses corresponding to at least one large page memory.

[0079] 103. When a computer system runs an application, it loads the dynamic library into at least one large page memory.

[0080] The process of steps 101 to 103 can also be found in Figure 3 The example scenario shown is for understanding. Figure 3 As shown, a computer system is about to load application A and recognizes that the application is marked for hugepage mode. This marking can be a hugepage mode identifier set in a specified location within the application, such as a "Hugepage" tag, or another tag indicating hugepages. In kernel mode, the computer system requests hugepage memory from the MMU for application A. The MMU reserves multiple 2M physical pages in physical memory for application A. The computer system then maps the dynamic libraries that the application depends on to the virtual address space corresponding to these multiple 2M physical pages. When the application is run, the dynamic libraries are loaded into one or more 2M physical pages.

[0081] In an embodiment of the present application, large page memory is used to store dynamic libraries. In this way, the number of large pages occupied by dynamic libraries of the same size is much smaller than the number of 4K physical pages occupied. After the page table entries of the large pages are cached in the TLB, they will not be quickly deleted due to too many page table entries in the TLB. When the application or other applications call the dynamic library, the page table entries of the dynamic library can be queried in the TLB, thereby improving the hit rate of the TLB query.

[0082] In the present application, the TLB includes an instruction translation lookaside buffer (iTLB) and a data translation lookaside buffer (dTLB), and the dynamic library includes a code segment and a data segment. The page table entries of the code segment can be cached in the iTLB. Using large page memory to store the code segment can improve the hit rate of querying the iTLB. Similarly, the page table entries of the data segment can be cached in the dTLB. Using large page memory to store the code segment can improve the hit rate of querying the dTLB.

[0083] Optionally, when the application depends on at least two dynamic libraries, the solution of the embodiment of the present application includes:

[0084] At least two dynamic libraries that the application depends on are mapped in sequence to the virtual address space corresponding to at least one large page memory, wherein the end address of the first dynamic library in the virtual address space is continuous with the starting address of the second dynamic library in the virtual address space or are located in two consecutive 4K virtual pages of the virtual address space, and the first dynamic library and the second dynamic library are two dynamic libraries among the at least two dynamic libraries that are continuously mapped to the virtual address space.

[0085] When running an application, at least two dynamic libraries are loaded into at least one huge page memory in sequence, wherein the end address of the first dynamic library in the at least one huge page memory is continuous with the start address of the second dynamic library in the at least one huge page memory or is located in two consecutive 4K physical pages of the at least one huge page memory.

[0086] The process of mapping at least two dynamic libraries into the virtual address space can be two adjacent dynamic libraries mapped continuously, such as Figure 4A As shown, after the first dynamic library is mapped to multiple 4K virtual pages of multiple virtual address spaces, the end address of the first dynamic library is in the middle of the 4K virtual page 40, and the start address of the second dynamic library can be mapped from an address that is continuous with the middle of the 4K virtual page 40. This continuous mapping method can improve the utilization of the virtual address space.

[0087] The process of mapping at least two dynamic libraries to the virtual address space may be such that the end addresses and the start addresses of the two adjacent dynamic libraries are located in two adjacent 4K virtual pages, such as Figure 4B As shown, after the first dynamic library is mapped to multiple 4K virtual pages of multiple virtual address spaces, the end address of the first dynamic library is in 4K virtual page 40. The second dynamic library can be mapped starting from 4K virtual page 50 adjacent to 4K virtual page 40, that is, the start address of the second dynamic library is in 4K virtual page 50. This method of mapping dynamic libraries according to integer multiples of 4K virtual pages is conducive to improving the convenience of virtual address space management.

[0088] When there are multiple dynamic libraries, you can use Figure 4A or Figure 4B Any of the mapping methods shown can also be a combination of the two methods to map multiple dynamic libraries.

[0089] When running an application, the process of loading at least two dynamic libraries into at least one large page memory can be found in Figure 5 Understand. Figure 5As shown, the first dynamic library is loaded into the 2M physical page. The first dynamic library occupies the 2M physical page 1 and a part of the 2M physical page 2. When loading the second dynamic library, for example, Figure 4A and Figure 4B In any of the above methods, loading starts from 2M physical page 2. This application realizes the splicing of at least two dynamic libraries in the huge page memory by mapping the addresses continuously or located in two consecutive 4K physical pages, thereby improving the utilization of the huge page memory.

[0090] Optionally, each of the at least two dynamic libraries includes a code segment and a data segment. In an embodiment of the present application, the code segment (.text) is a collection of executable instructions, and the data segment is a collection of data. In an embodiment of the present application, the data segment includes a data segment (.data) and a BSS segment (.bss), wherein the data segment (.data) represents initialized data, and the BSS segment (.bss) represents uninitialized data. From the perspective of the executable program, if a piece of data is not initialized, there is no need to allocate space for it, so the difference between .data and .bss is that .bss does not occupy the size of the executable file, but only records how much space is needed to store these uninitialized data without allocating actual space.

[0091] In the embodiment of the present application, when the code segment and data segment of each dynamic library are loaded into at least one large page memory, the code segment and data segment of each dynamic library can be loaded in the order in which the dynamic library is loaded. The process can be referred to in Figure 6A The examples shown are as follows: Figure 6A As shown, when dynamic library 1 and dynamic library 2 are loaded in at least one large page memory, the code segment of dynamic library 1, i.e. dynamic library 1.text, is loaded in sequence, and then the data segment of dynamic library 1, i.e. dynamic library 1.data, is loaded. Then, when dynamic library 2 is loaded, the code segment of dynamic library 2, i.e. dynamic library 2.text, is loaded in sequence, and then the data segment of dynamic library 2, i.e. dynamic library 2.data, is loaded. If other dynamic libraries are loaded subsequently, the order of recording the code segment and the data segment is the same as that of loading dynamic library 1 and dynamic library 2. It should be noted that in at least one large page memory, the memory areas where dynamic libraries are not loaded do not occupy the actual physical space of these memory areas.

[0092] Optionally, when loading the code segment and data segment of each dynamic library into at least one huge page memory, the code segment of each dynamic library is stored continuously in the at least one huge page memory, and the data segment of each dynamic library is stored continuously in the at least one huge page memory. Figure 6B The examples shown are as follows: Figure 6BAs shown, when dynamic library 1 and dynamic library 2 are loaded in at least one large page memory, the code segment of dynamic library 1, i.e. dynamic library 1.text, is loaded in order, and then the code segment of dynamic library 2, i.e. dynamic library 2.text, is loaded. Then, the data segment of dynamic library 1, i.e. dynamic library 1.data, is loaded, and then the data segment of dynamic library 2, i.e. dynamic library 2.data, is loaded. If other dynamic libraries are subsequently loaded, the order of recording the code segment and the data segment is based on the manner of loading dynamic library 1 and dynamic library 2, and so on. The method of continuously storing the code segments of multiple dynamic libraries in the embodiment of the present application, when the code segments in a certain large page are loaded into the cache, will increase the probability of continuous code segments being loaded into the instruction cache at the same time.

[0093] In an embodiment of the present application, when a computer system runs an application, it can call a dynamic library through a call function in the application. In addition, a dynamic library loaded into the application can also call other dynamic libraries through its own call function.

[0094] In the embodiment of the present application, the function of the call function is to initiate a call to the first dynamic library, and the call initiation position refers to the position in the call function where the call to the first dynamic library is initiated.

[0095] In the prior art, the process of calling a function to call a dynamic library is as follows: the original address of the calling location of the called function is usually the address of the procedure link table (PLT). Then, it will jump to the PLT through the address of the PLT, and then jump to the global offset table (GOT) through the PLT. The corresponding dynamic library is called through the GOT. These two jumps affect the efficiency of the processor's execution of instructions.

[0096] In the embodiment of the present application, the original address of the call initiation location of the calling function calling the first dynamic library is modified based on the function address of the first dynamic library. The first dynamic library is one of the dynamic libraries that the application depends on, and the calling function is contained in the application or in other dynamic libraries that the application depends on. When the calling function calls the first dynamic library by running, the first dynamic library is called based on the function address of the first dynamic library at the call initiation location. In the embodiment of the present application, when the calling function calls the first dynamic library, the first dynamic library can be directly called based on the function address of the first dynamic library at the call initiation location, which is equivalent to achieving a direct pass from the calling function to the first dynamic library function without the need for two jumps through the PLT and GOT, thereby improving the processor's execution efficiency of instructions.

[0097] The above process of prior art can be found in Figure 7AUnderstand. Figure 7A As shown, the executable file of the application includes a calling function call, and the starting address of the calling function is: printf@plt. When the calling function is executed, it will first jump to the PLT according to printf@plt. In the PLT, jmp*printf@got is found through printf@plt, and then it jumps to the GOT according to printf@got. In the GOT, the function address of the dynamic library is found through printf@got: 0Xf7e835f0, and then the corresponding dynamic library is called according to the function address of the dynamic library: 0Xf7e835f0.

[0098] and Figure 7A Compared to the process shown in Figure 7B As shown, in this application, the starting address of the call initiation position of the calling function is the function address of the dynamic library: 0Xf7e835f0, then the PLT and GOT can be directly passed to directly call the corresponding dynamic library.

[0099] In the embodiment of the present application, the original address of the call initiation location of the called function is modified to the function address of the dynamic library, thereby realizing direct calling of the dynamic library without going through the PLT and GOT. This can also eliminate the PLT and GOT and reduce the performance overhead caused by maintaining the PLT and GOT.

[0100] In the embodiment of the present application, before modifying the original address of the call initiation location to the function address of the dynamic library, it is necessary to use a relocation table to determine the call initiation location of the calling function to the first dynamic library. The relocation table includes the call initiation location of the calling function calling the first dynamic library. Typically, the relocation table records the call initiation locations of all calling functions in the application or the corresponding dynamic library to each dynamic library. Therefore, the relocation table can be used to quickly determine the call initiation location.

[0101] There are three ways to generate a relocation table in the embodiment of the present application, which are introduced below respectively.

[0102] The first one: Generate a relocation table during the compilation phase.

[0103] When compiling an application or compiling each dynamic library, when compiling into a calling function therein, the calling function's call initiation position to the dynamic library is saved in the relocation table. When the calling function calls the first dynamic library, the calling function's call initiation position to the first dynamic library is saved in the relocation table.

[0104] In this way, the dynamic library interpreter can use the relocation table to modify the original address in the calling function to the function address of the first dynamic library, so that when the calling function calls the first dynamic library, the PLT and GOT can be skipped to directly call the first dynamic library.

[0105] The second method: Generate a relocation table during the runtime phase.

[0106] When the calling function is running, the position information of the next instruction of the calling function for the first time calling the first dynamic library is pushed into the stack; the call initiation position of the calling function calling the first dynamic library is determined based on the position information of the next instruction in the stack; and the call initiation position of the calling function to the first dynamic library is saved in the relocation table.

[0107] In this way, the dynamic library interpreter can use the relocation table to modify the original address in the calling function to the function address of the first dynamic library, so that when the calling function calls the first dynamic library, the PLT and GOT can be skipped to directly call the first dynamic library.

[0108] The third method: Generate a relocation table by scanning the code segment.

[0109] When the dynamic library interpreter loads the calling function, it scans the code segment of the calling function to obtain the calling initiation position of the calling function calling the first dynamic library; and saves the calling initiation position of the calling function to the first dynamic library in the relocation table.

[0110] In this way, the dynamic library interpreter can use the relocation table to modify the original address in the calling function to the function address of the first dynamic library, so that when the calling function calls the first dynamic library, the PLT and GOT can be skipped to directly call the first dynamic library.

[0111] Because dynamic libraries may be frequently loaded or unloaded during application execution, in order to facilitate virtual address space management, in an embodiment of the present application, a bitmap is used to manage the virtual address space during dynamic library loading or unloading. The bitmap records the mapping locations of the dynamic libraries that the application depends on in the virtual address space at a 4K virtual page granularity.

[0112] In the embodiment of the present application, the bitmap can be understood by referring to FIG8 . Figure 8 As shown, the address length of a 4K virtual page is identified by 0 or 1, where 0 indicates that this virtual address space is in a free state and 1 indicates that this virtual address space is occupied.

[0113] Optionally, during the process of unloading the dynamic library, the embodiment of the present application further includes: unloading a second dynamic library in the dynamic library on which the application depends; and clearing multiple 4K virtual pages corresponding to the second dynamic library on the bitmap.

[0114] In the embodiment of this application, the process can be referred to Figure 9 To understand, such as Figure 9 As shown, when the second dynamic library is not uninstalled, the identifiers of the virtual address space corresponding to the second dynamic library on the bitmap are all represented by 1. After the second dynamic library is uninstalled, the identifiers on the bitmap are all modified to 0.

[0115] Optionally, during the process of loading a dynamic library, an embodiment of the present application further includes: mapping a third dynamic library in the virtual address space vacated by unloading the second dynamic library; and recording a mapping relationship between the third dynamic library and the corresponding virtual address space on a bitmap.

[0116] In the embodiment of this application, the process can be referred to Figure 10 To understand, such as Figure 10 As shown, when the third dynamic library is not loaded, the identifiers of the virtual address space vacated by the unloading of the second dynamic library on the bitmap are all represented by 0. After the third dynamic library is loaded, the corresponding identifiers on the bitmap are all modified to 1.

[0117] The solution provided by the embodiment of the present application is that after the second dynamic library is unloaded, a blank virtual address space will be vacated. When a new third dynamic library is loaded, the third dynamic library can be mapped to the virtual address space vacated due to the unloading of the second air-conditioning library. In this way, the utilization rate of the virtual address space can be improved.

[0118] Optionally, the embodiment of the present application further includes: when all virtual address spaces corresponding to any large page memory in at least one large page memory are in an idle state, releasing any large page memory.

[0119] The solution provided by the embodiment of the present application is that when the virtual address space corresponding to one or several large page memories is in an idle state, this or these large page memories can be released, thereby improving the utilization rate of the large page memories.

[0120] The above describes a method for managing a dynamic library. The following describes an apparatus for managing a dynamic library provided in an embodiment of the present application in conjunction with the accompanying drawings.

[0121] like Figure 11 As shown, an embodiment of the device 70 for managing a dynamic library provided in an embodiment of the present application includes:

[0122] The first processing unit 701 is configured to apply for at least one large page memory for an application program marked as in large page mode. The first processing unit 701 may execute step 101 of the above method embodiment.

[0123] The second processing unit 702 is configured to map the dynamic library that the application depends on to the virtual address space corresponding to the at least one large page memory applied for by the first processing unit 701. The second processing unit 702 may execute step 102 of the above method embodiment.

[0124] The third processing unit 703 is configured to load the dynamic library into at least one large page memory requested by the first processing unit 701 when running the application program. The third processing unit 703 may execute step 103 of the above method embodiment.

[0125] In an embodiment of the present application, large page memory is used to store dynamic libraries. In this way, the number of large pages occupied by dynamic libraries of the same size is much smaller than the number of 4K physical pages occupied. After the page table entries of the large pages are cached in the TLB, they will not be quickly deleted due to too many page table entries in the TLB. When the application or other applications call the dynamic library, the page table entries of the dynamic library can be queried in the TLB, thereby improving the hit rate of the TLB query.

[0126] Optionally, the second processing unit 702 is used to, when there are at least two dynamic libraries that the application depends on, map the at least two dynamic libraries that the application depends on in sequence to the virtual address space corresponding to at least one large page memory, wherein the end address of the first dynamic library in the virtual address space is continuous with the starting address of the second dynamic library in the virtual address space or are located in two consecutive 4K virtual pages of the virtual address space, and the first dynamic library and the second dynamic library are two dynamic libraries among the at least two dynamic libraries that are continuously mapped to the virtual address space.

[0127] The third processing unit 703 is used to load at least two dynamic libraries into at least one large page memory in sequence when running the application, wherein the end address of the first dynamic library in the at least one large page memory is continuous with the starting address of the second dynamic library in the at least one large page memory or is located in two consecutive 4K physical pages of the at least one large page memory.

[0128] Optionally, each of the at least two dynamic libraries includes a code segment and a data segment, and the third processing unit 703 is used to continuously store the code segment of each dynamic library in the at least one large page memory and continuously store the data segment of each dynamic library in the at least one large page memory when loading the code segment and data segment of each dynamic library into the at least one large page memory.

[0129] Optionally, the device 70 also includes a fourth processing unit 704, which is used to: modify the original address of the call initiation location of the calling function calling the first dynamic library according to the function address of the first dynamic library, the first dynamic library is one of the dynamic libraries that the application depends on, and the calling function is contained in the application or in other dynamic libraries that the application depends on; when calling the first dynamic library by running the calling function, the first dynamic library is called according to the function address of the first dynamic library at the call initiation location.

[0130] Optionally, the fourth processing unit 704 is further configured to use a relocation table to determine a call initiation location of the calling function to the first dynamic library, where the relocation table includes a call initiation location of the calling function to the first dynamic library.

[0131] Optionally, the fourth processing unit 704 is further configured to save the call initiation location of the calling function calling the first dynamic library into the relocation table when compiling the calling function.

[0132] Optionally, the fourth processing unit 704 is further used to push the location information of the next instruction of the calling function's first call to the first dynamic library into the stack when running the calling function; determine the call initiation position of the calling function's call to the first dynamic library based on the location information of the next instruction in the stack; and save the call initiation position of the calling function to the first dynamic library into the relocation table.

[0133] Optionally, the fourth processing unit 704 is further configured to scan the code segment of the calling function when loading the calling function to obtain the call initiation location of the calling function calling the first dynamic library; and save the call initiation location of the calling function to the first dynamic library in the relocation table.

[0134] Optionally, the third processing unit 703 is further configured to uninstall a second dynamic library in the dynamic libraries that the application depends on.

[0135] The second processing unit 702 is further configured to clear multiple 4K virtual pages corresponding to the second dynamic library on the bitmap. The bitmap records the mapping locations of the dynamic libraries that the application depends on in the virtual address space at a granularity of 4K virtual pages.

[0136] Optionally, the second processing unit 702 is further configured to map a third dynamic library to the virtual address space freed by uninstalling the second dynamic library; and record a mapping relationship between the third dynamic library and the corresponding virtual address space in a bitmap.

[0137] Optionally, the third processing unit 703 is further configured to release any huge page memory in the at least one huge page memory when all virtual address spaces corresponding to any huge page memory are in an idle state.

[0138] The above-described apparatus for managing a dynamic library can be understood by referring to the corresponding contents of the above-described method for managing a dynamic library, and will not be repeated here.

[0139] Figure 12 FIG. 8 is a diagram showing a possible logical structure of a computer device 80 according to an embodiment of the present application. The computer device 80 includes a processor 801, a memory management unit 802, a physical memory 803, and a bus 804. The processor 801, the memory management unit 802, and the physical memory 803 are interconnected via the bus 804. In the embodiment of the present application, the processor 801 is used to control and manage the actions of the computer device 80. For example, the processor 801 is used to execute Figures 1 to 7B The steps in the method embodiment. The memory management unit 802 is used to manage physical memory. The physical memory 803 is used to store program code and data of dynamic libraries. Of course, the computer device 80 provided in the embodiment of the present application also includes other devices, such as: communication interface, disk, etc. Figure 12 Not shown one by one.

[0140] Among them, the processor 801 can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It can implement or execute the various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. The processor 801 can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and so on. The bus 804 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 12 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0141] In another embodiment of the present application, a computer-readable storage medium is further provided. The computer-readable storage medium stores computer-executable instructions. When the processor of the device executes the computer-executable instructions, the device executes the above-mentioned Figures 1 to 10 The steps performed by a computer system in a program.

[0142] In another embodiment of the present application, a computer program product is further provided. The computer program product includes computer-executable instructions stored in a computer-readable storage medium. When the processor of the device executes the computer-executable instructions, the device executes the above-mentioned Figures 1 to 10 The steps performed by a computer system in a program.

[0143] In another embodiment of the present application, a chip system is further provided, the chip system including a processor, the processor being used to support the memory management device to implement the above Figures 1 to 10 The steps performed by the computer system in the chip. In one possible design, the chip system may also include a memory for storing the program instructions and data necessary for the data writing device. The chip system may be composed of a chip or may include a chip and other discrete devices.

[0144] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of this application.

[0145] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0146] In the several embodiments provided in the embodiments of the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0147] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0148] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0149] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0150] The above is only a specific implementation of the embodiment of the present application, but the protection scope of the embodiment of the present application is not limited to this.

Claims

1. A method for managing dynamic libraries, applied to a computer system, characterized in that: The method comprises: Request at least one huge page of memory for an application marked as in huge page mode; Mapping a dynamic library that the application depends on to a virtual address space corresponding to the at least one large page memory, wherein the dynamic library is a dynamic library under Linux and includes a code segment and a data segment; When the application is run, the dynamic library is loaded into the at least one large page memory, and the dynamic library is called by calling a function, and the original address of the call initiation position of the called function is the function address of the dynamic library.

2. The method according to claim 1, characterized in that When there are at least two dynamic libraries that the application depends on, mapping the dynamic libraries that the application depends on to a virtual address space corresponding to the at least one large page memory includes: Mapping at least two dynamic libraries that the application depends on sequentially to a virtual address space corresponding to the at least one large page memory, wherein an end address of a first dynamic library in the virtual address space is continuous with a start address of a second dynamic library in the virtual address space or is located in two consecutive 4K virtual pages of the virtual address space, and the first dynamic library and the second dynamic library are two dynamic libraries among the at least two dynamic libraries that are consecutively mapped to the virtual address space; The step of loading the dynamic library into the at least one large page memory when running the application program comprises: When running the application, the at least two dynamic libraries are loaded into the at least one large page memory in sequence, wherein the end address of the first dynamic library in the at least one large page memory is continuous with the start address of the second dynamic library in the at least one large page memory or is located in two consecutive 4K physical pages of the at least one large page memory.

3. The method according to claim 2, characterized in that The step of sequentially loading the at least two dynamic libraries into the at least one large page memory includes: When the code segment and the data segment of each dynamic library of the at least two dynamic libraries are loaded into the at least one large page memory, the code segment of each dynamic library is continuously stored in the at least one large page memory, and the data segment of each dynamic library is continuously stored in the at least one large page memory.

4. The method according to claim 2, characterized in that The method further comprises: modifying, according to the function address of the first dynamic library, an original address of a location where a calling function calls the first dynamic library, where the first dynamic library is one of the dynamic libraries on which the application depends, and the calling function is included in the application or in another dynamic library on which the application depends; When the first dynamic library is called by running the calling function, the first dynamic library is called according to the function address of the first dynamic library at the calling initiation location.

5. The method according to claim 4, characterized in that The method further comprises: A relocation table is used to determine a call initiation position of the calling function to the first dynamic library, wherein the relocation table includes a call initiation position of the calling function to the first dynamic library.

6. The method according to claim 5, characterized in that The method further comprises: When compiling the calling function, the calling initiation position of the calling function calling the first dynamic library is saved in the relocation table.

7. The method according to claim 5, characterized in that The method further comprises: When the calling function is executed, the position information of the next instruction of the first dynamic library called by the calling function for the first time is pushed into the stack; Determine, based on the position information of the next instruction in the stack, a call initiation position of the calling function calling the first dynamic library; The calling initiation location of the calling function to the first dynamic library is saved in the relocation table.

8. The method according to claim 5, characterized in that The method further comprises: When loading the calling function, scanning the code segment of the calling function to obtain a call initiation position of the calling function calling the first dynamic library; The calling initiation location of the calling function to the first dynamic library is saved in the relocation table.

9. The method according to claim 2, characterized in that The method further comprises: Uninstalling the second dynamic library in the dynamic libraries that the application depends on; A plurality of 4K virtual pages corresponding to the second dynamic library are cleared on a bitmap, wherein the bitmap records the mapping positions of the dynamic libraries on which the application depends in the virtual address space with 4K virtual pages as the granularity.

10. The method according to claim 9, characterized in that The method further comprises: Mapping a third dynamic library to the virtual address space freed by uninstalling the second dynamic library; A mapping relationship between the third dynamic library and the corresponding virtual address space is recorded on the bitmap.

11. The method according to claim 9, characterized in that The method further comprises: When all virtual address spaces corresponding to any one of the at least one large page memory are in an idle state, the any one of the large page memory is released.

12. A device for managing a dynamic library, characterized in that: include: A first processing unit is configured to apply for at least one huge page memory for an application program marked as in huge page mode; A second processing unit is configured to map a dynamic library on which the application depends to a virtual address space corresponding to at least one large page memory applied for by the first processing unit, wherein the dynamic library is a dynamic library under Linux and includes a code segment and a data segment; The third processing unit is used to load the dynamic library into at least one large page memory applied for by the first processing unit when running the application program. The dynamic library is called by calling a function, and the original address of the call initiation position of the called function is the function address of the dynamic library.

13. The device according to claim 12, characterized in that The second processing unit is configured to, when there are at least two dynamic libraries that the application depends on, sequentially map the at least two dynamic libraries that the application depends on to a virtual address space corresponding to the at least one large page memory, wherein an end address of a first dynamic library in the virtual address space is continuous with a start address of a second dynamic library in the virtual address space or is located in two consecutive 4K virtual pages of the virtual address space, and the first dynamic library and the second dynamic library are two dynamic libraries among the at least two dynamic libraries that are continuously mapped to the virtual address space; The third processing unit is used to load the at least two dynamic libraries into the at least one large page memory in sequence when running the application, wherein the end address of the first dynamic library in the at least one large page memory is continuous with the starting address of the second dynamic library in the at least one large page memory or is located in two consecutive 4K physical pages of the at least one large page memory.

14. The device according to claim 13, characterized in that The third processing unit is configured to, when loading the code segment and the data segment of each dynamic library in the at least two dynamic libraries into the at least one large page memory, continuously store the code segment of each dynamic library in the at least one large page memory, and continuously store the data segment of each dynamic library in the at least one large page memory.

15. The device according to claim 13, characterized in that The device further comprises a fourth processing unit, The fourth processing unit is configured to: modifying, according to the function address of the first dynamic library, an original address of a location where a calling function calls the first dynamic library, where the first dynamic library is one of the dynamic libraries on which the application depends, and the calling function is included in the application or in another dynamic library on which the application depends; When the first dynamic library is called by running the calling function, the first dynamic library is called according to the function address of the first dynamic library at the calling initiation location.

16. The device according to claim 15, characterized in that The fourth processing unit is further configured to use a relocation table to determine a call initiation location of the calling function to the first dynamic library, wherein the relocation table includes a call initiation location of the calling function to the first dynamic library.

17. The device according to claim 16, characterized in that The fourth processing unit is further configured to save, when compiling the calling function, a call initiation location where the calling function calls the first dynamic library into the relocation table.

18. The device according to claim 16, characterized in that The fourth processing unit is further configured to: When the calling function is executed, the position information of the next instruction of the first dynamic library called by the calling function for the first time is pushed into the stack; Determine, based on the position information of the next instruction in the stack, a call initiation position of the calling function calling the first dynamic library; The calling initiation location of the calling function to the first dynamic library is saved in the relocation table.

19. The device according to claim 16, characterized in that The fourth processing unit is further configured to: When loading the calling function, scanning the code segment of the calling function to obtain a call initiation position of the calling function calling the first dynamic library; The calling initiation location of the calling function to the first dynamic library is saved in the relocation table.

20. The device according to claim 13, wherein The third processing unit is further configured to unload the second dynamic library in the dynamic library that the application depends on; The second processing unit is further used to clear multiple 4K virtual pages corresponding to the second dynamic library on the bitmap, and the bitmap records the mapping position of the dynamic library dependent on the application in the virtual address space with 4K virtual page as the granularity.

21. The device according to claim 20, characterized in that The second processing unit is further configured to map a third dynamic library to the virtual address space freed by uninstalling the second dynamic library; and record a mapping relationship between the third dynamic library and the corresponding virtual address space on the bitmap.

22. The device according to claim 20, characterized in that The third processing unit is further configured to release any large page memory in the at least one large page memory when all virtual address spaces corresponding to the large page memory are in an idle state.

23. A computing device, characterized in that comprising one or more processors and a computer-readable storage medium storing a computer program; When the computer program is executed by the one or more processors, the method according to any one of claims 1 to 11 is implemented.

24. A chip system, characterized in that: The method comprises one or more processors, wherein the one or more processors are called to execute the method according to any one of claims 1 to 11.

25. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by one or more processors, the method according to any one of claims 1 to 11 is implemented.

26. A computer program product, characterized in that The invention comprises a computer program for implementing the method according to any one of claims 1 to 11 when the computer program is executed by one or more processors.

Images