Memory management method and apparatus

Abstract

The application provides a memory management method and device. The method comprises: allocating a virtual address region for an application in off-heap memory, and establishing a mapping relationship between the virtual address region and a physical memory page of physical memory. If resource usage of the off-heap memory meets a resource release condition, a sub-virtual address region and a mapped physical memory page thereof are released, so that the resource release condition is set to limit the occupation amount of the off-heap memory to the physical memory, and the physical memory utilization is improved, especially in a physical memory resource shortage scenario.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a memory management method and apparatus. Background Technology

[0002] In the Java runtime environment, Java's on-heap memory is managed by the garbage collector, while off-heap memory is not. Developers typically need to explicitly manage off-heap memory through Java's Unsafe interface. However, since the allocation and deallocation of off-heap memory are manually managed by the user, failure to properly release unused off-heap memory can lead to memory leaks and other problems, compromising data security. Furthermore, in situations where memory resources are scarce, frequent allocation and deallocation of off-heap memory by users will impact memory allocation efficiency and reduce the overall system's memory access efficiency. Summary of the Invention

[0003] This application provides a memory management method and apparatus. The method manages off-heap memory based on resource release conditions, providing a reasonable and automated off-heap memory management mechanism to improve the overall memory allocation efficiency of the system.

[0004] Firstly, this application provides a memory management method. The method includes: in response to a first memory allocation request from an application, allocating a first virtual address region for the application in off-heap memory; establishing a mapping relationship between the first virtual address region and at least one physical page in physical memory; and releasing at least one first physical memory page mapped to a sub-virtual address region if the resources occupied by the first virtual address region meet a resource release condition, wherein the sub-virtual address region belongs to the first virtual address region and the at least one first physical memory page belongs to the at least one physical memory page. Thus, by setting a resource release condition, this application can limit the amount of virtual memory used, thereby further limiting the amount of physical memory occupied by virtual memory. This avoids excessive occupation of physical memory by off-heap memory when physical memory is scarce, effectively improving the utilization rate of physical memory and preventing frequent swapping of physical pages when physical memory is scarce, thereby improving the overall processing efficiency of memory allocation and access.

[0005] For example, off-heap memory and on-heap memory can be understood as two independent address spaces.

[0006] For example, the virtual address region may optionally be a contiguous segment of virtual addresses.

[0007] For example, a virtual address region may contain one or more virtual memory pages.

[0008] In one possible implementation, releasing at least one first physical memory page mapped to a sub-virtual address region includes: canceling the mapping relationship between the sub-virtual address region and the at least one first physical page. Thus, this application releases off-heap memory by canceling the mapping, ensuring that the released off-heap memory pages no longer occupy physical memory. This avoids excessive physical memory usage by off-heap memory in situations of physical memory scarcity, effectively improving physical memory utilization and preventing frequent page swapping in and out when physical memory is limited. Ultimately, this improves the overall efficiency of memory allocation and access.

[0009] In one possible implementation, after releasing at least one first physical memory page mapped to a sub-virtual address region, the method further includes: obtaining a first access request, the first access request being used to request access to the physical memory corresponding to the first virtual address; if the first virtual address belongs to the sub-virtual address region, establishing a mapping relationship between the first virtual address and a second physical page; and performing a corresponding access operation on the second physical page based on the first access request. Thus, this application, by setting a recovery process, can restore the mapping of a physical page when an application accesses a physical page that has already been released. That is, before access, excess memory resources can be released through a memory resource management mechanism. When access is needed, the recovery process is then executed on the corresponding page. Through the provided recovery process, system crashes caused by illegal access can be avoided. Furthermore, restoring the mapping relationship during access can effectively improve the utilization rate of physical memory.

[0010] In one possible implementation, after obtaining the first access request, the method further includes: performing semantic analysis on the application's access behavior based on the first access request and multiple preceding access requests to determine the access behavior type corresponding to the application's access behavior; if the access behavior type is a random access type, performing a prefetch operation on multiple consecutive virtual memory pages before and / or after the first virtual address; if the access behavior type is a non-random access type, performing a prefetch operation on multiple consecutive virtual memory pages after the first virtual address. In this way, this application can predict the memory pages that need to be prefetched based on application access behavior, execute the prefetch process in advance, and minimize the need to switch to kernel mode during memory access, thereby improving memory access efficiency. Furthermore, predicting the memory pages that need to be prefetched based on application access behavior enables awareness of the memory allocation behavior of upper-layer applications, and implements the prefetch process based on this semantics.

[0011] In one possible implementation, the prefetch operation includes: detecting whether each of the virtual memory pages is mapped to physical memory; if any virtual memory page is not mapped to physical memory, establishing a mapping relationship between the virtual memory page and a third physical memory page. In this way, by establishing the mapping relationship between virtual memory pages and physical memory pages in advance through the prefetch operation, the access process does not require switching to kernel mode, effectively improving memory access efficiency.

[0012] In one possible implementation, the resource release condition is used to indicate that the allocated resources in the off-heap memory are greater than a first value; wherein the resources occupied by the first virtual address region are included in the allocated resources in the off-heap memory. Thus, by setting a resource release condition, this application can limit the amount of virtual memory used, thereby further limiting the amount of physical memory occupied by virtual memory. This avoids excessive occupation of physical memory by off-heap memory when physical memory is scarce, effectively improving the utilization rate of physical memory and preventing frequent page swapping when physical memory is limited, thereby improving the overall processing efficiency of memory allocation and access.

[0013] In one possible implementation, the method further includes: in response to a second memory allocation request from the application, allocating a second virtual address region for the application in heap memory; performing a prefetch operation on at least one virtual memory page contained in the second virtual address region to prefetch physical pages from the disk into physical memory; and establishing a mapping relationship between the second virtual address region and at least one fourth physical memory page, the at least one fourth physical memory page including physical memory pages prefetched into the physical memory through the prefetch operation.

[0014] Secondly, this application provides a memory management device, comprising: a memory allocation and access module, configured to allocate a first virtual address region for the application in off-heap memory in response to a first memory allocation request from an application; an off-heap memory processing module, configured to establish a mapping relationship between the first virtual address region and at least one physical page in physical memory; the off-heap memory processing module is further configured to release at least one first physical memory page mapped to a sub-virtual address region if the resources occupied by the first virtual address region meet the resource release conditions, wherein the sub-virtual address region belongs to the first virtual address region and the at least one first physical memory page belongs to the at least one physical memory page.

[0015] In one possible implementation, the off-heap memory processing module is specifically used to: cancel the mapping relationship between the sub-virtual address region and the at least one first physical page.

[0016] In one possible implementation, the memory allocation and access module is further configured to obtain a first access request, the first access request being used to request access to the physical memory corresponding to the first virtual address; the off-heap memory processing module is further configured to establish a mapping relationship between the first virtual address and the second physical page if the first virtual address belongs to the sub-virtual address region; the off-heap memory processing module is further configured to perform a corresponding access operation on the second physical page based on the first access request.

[0017] In one possible implementation, the off-heap memory processing module is further configured to: perform semantic analysis on the application's access behavior based on the first access request and multiple previous access requests to determine the access behavior type corresponding to the application's access behavior; if the access behavior type is a random access type, perform a prefetch operation on multiple consecutive virtual memory pages before and / or after the first virtual address; if the access behavior type is a non-random access type, perform a prefetch operation on multiple consecutive virtual memory pages after the first virtual address.

[0018] In one possible implementation, the off-heap memory processing module is specifically used to: detect whether each virtual memory page is mapped to physical memory; if any virtual memory page is not mapped to physical memory, establish a mapping relationship between the virtual memory page and a third physical memory page.

[0019] In one possible implementation, the resource release condition is used to indicate that the allocated resources in the off-heap memory are greater than a first value; wherein the resources occupied by the first virtual address region are included in the allocated resources in the off-heap memory.

[0020] In one possible implementation, the memory allocation and access module is further configured to allocate a second virtual address region for the application in the heap memory in response to a second memory allocation request from the application; the heap memory processing module is configured to perform a prefetch operation on at least one virtual memory page contained in the second virtual address region to prefetch physical pages from the disk into physical memory; the heap memory processing module is further configured to establish a mapping relationship between the second virtual address region and at least one fourth physical memory page, wherein the at least one fourth physical memory page includes physical memory pages prefetched into the physical memory through the prefetch operation.

[0021] Thirdly, this application provides a computer-readable medium for storing a computer program including instructions for performing the methods in the first aspect or any possible implementation thereof.

[0022] Fourthly, this application provides a computer program including instructions for performing the method in the first aspect or any possible implementation thereof.

[0023] Fifthly, this application provides a chip including a processing circuit and transceiver pins. The transceiver pins and the processing circuit communicate with each other via an internal connection path. The processing circuit executes the method in the first aspect or any possible implementation of the first aspect to control the receiving pin to receive signals and to control the transmitting pin to transmit signals.

[0024] Sixthly, this application provides a computer device including one or more memories and one or more processors. The memories store a computer program that, when executed by the processor, causes the computer device to perform the methods of the first aspect or any possible implementation thereof. Attached Figure Description

[0025] Figure 1 A schematic diagram illustrating virtual addressing as an example;

[0026] Figure 2 This is a schematic diagram illustrating memory allocation as an example.

[0027] Figure 3 This is a schematic diagram of the structure of a computing device as an example.

[0028] Figure 4 A schematic diagram of the memory management method provided in this application;

[0029] Figure 5 This is an example of a module interaction diagram;

[0030] Figure 6 This is a schematic diagram illustrating the in-heap memory processing flow as an example.

[0031] Figure 7 This is an example of a module interaction diagram;

[0032] Figure 8 This is a schematic diagram illustrating the off-heap memory processing flow as an example.

[0033] Figure 9 This is an example of a module interaction diagram;

[0034] Figure 10 This is an exemplary diagram illustrating off-heap memory management.

[0035] Figure 11 This is a schematic diagram illustrating the off-heap memory processing flow as an example.

[0036] Figure 12This is a schematic diagram illustrating the off-heap memory processing flow as an example.

[0037] Figure 13 This is a schematic diagram of the prefetching process as an example.

[0038] Figure 14 This is a schematic diagram of the device structure as an example. Detailed Implementation

[0039] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0040] The following is a brief explanation of some background technologies and terms involved in the embodiments of this application.

[0041] (1) Physical memory: refers to the actual memory installed in a computer, which is used to store data for the central processing unit (CPU). It is generally Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM) or High Bandwidth Memory (HBM, also known as high bandwidth video memory). The memory mentioned in the embodiments of this application refers to physical memory, which will not be repeated below.

[0042] (2) Physical Address (PA): Also known as real address, it is the memory address used to access a specific storage unit of physical memory.

[0043] (3) Logical Address: The address used by the application. A logical address, also called a virtual address, is the address used in the program code. In memory access scenarios, a logical address is translated into a physical address (PA). In this embodiment, the logical address may include, but is not limited to, virtual addresses (VA) and input / output (IO) virtual addresses. The Memory Management Unit (MMU) can find the corresponding PA based on the VA. The Input / Output Memory Management Unit (IOMMU) can find the corresponding PA based on the IOVA.

[0044] (4) Address space: An ordered set of non-negative integer addresses. A system can have multiple address spaces, each independent. In this embodiment, the address space may include, but is not limited to: physical address space, virtual address space, and input / output virtual address space (i.e., I / O virtual address space). Optionally, the physical address, virtual address, and I / O virtual address involved in this embodiment belong to the physical address space, virtual address space, and I / O virtual address space, respectively.

[0045] (5) Page: Also known as a page, it is a fixed-length contiguous block of virtual memory, described by a single entry in the page table. It is the smallest unit of data used for memory management in operating systems that use virtual memory.

[0046] In this application's embodiments, the pages involved include: virtual pages (also referred to as virtual pages, virtual memory pages, etc.) and physical pages (also referred to as physical pages, etc.). In this application's embodiments, physical pages also include pages in physical memory (e.g., simply referred to as physical memory pages) and / or pages on disk.

[0047] (6) Page table: A page table is a data structure used in the virtual memory system of a computer operating system. It stores the mapping between virtual addresses and physical addresses.

[0048] (7) Memory Mapping: A computing device initializes the contents of a virtual memory region by associating it with an object on disk; this process is called memory mapping. A virtual memory region can be mapped to one of two types of objects:

[0049] 1) Regular files in the Linux file system: A region can be mapped to a contiguous portion of a regular disk file, such as an executable file. Because page scheduling is performed on demand, these virtual pages are not actually swapped into physical memory until the CPU first references the page (i.e., issues a virtual address that falls within the address space of that page).

[0050] 2) Anonymous Files: A region can also be mapped to an anonymous file. Anonymous files are created by the kernel and contain only binary zeros. When the CPU first references a virtual page in such a region, the kernel finds a suitable sacrifice page in physical memory. If the page has been modified, it swaps the page out, overwrites the sacrifice page with binary zeros, updates the page table, and marks the page as residing in memory.

[0051] In either case, once a virtual page is initialized, it is swapped between dedicated swap files maintained by the kernel. These swap files are also called swap space or swap area.

[0052] (8) Memory swapping mechanism: This is an important mechanism for memory management in Linux. It mainly includes two parts: memory swapping in and memory swapping out. Memory swapping out refers to the process where, when the total amount of physical memory used by a process exceeds the memory resource limit, some physical pages that are not currently in use need to be swapped out to the swap partition, so that some physical memory pages can be reused by the application. Memory page swapping in refers to the process where, when a previously swapped-out memory page is accessed again by an application, it needs to be read back from the swap cache or swap partition into physical memory.

[0053] This can be understood as follows: when memory space is scarce, the system temporarily swaps out certain physical pages in memory (also known as cold data) from the disk, and swaps in physical pages corresponding to certain processes on the disk that are ready to run (also known as hot data). In other words, the system improves memory access efficiency by swapping hot data into physical memory, and saves physical memory space occupied by cold data by swapping it out of the disk, thus freeing up enough space for hot data.

[0054] (9) Physical addressing and virtual addressing (also known as logical addressing): Physical addressing is the method of accessing memory using physical addresses. Virtual addressing is the method of accessing memory using physical addresses (or logical addresses).

[0055] Figure 1 For an illustrative diagram of virtual addressing, please refer to... Figure 1 The CPU uses virtual addresses (VA) to access memory, and the MMU is responsible for handling the CPU's memory access requests, implementing functions such as virtual address to physical address translation and access control.

[0056] (10) Shuffle Mechanism: The shuffle mechanism in big data frameworks such as Spark is an operation that aggregates data from different nodes to the current node according to certain rules for computation. The shuffle mechanism mainly includes, but is not limited to, two parts: Shuffle Write and Shuffle Read. The Shuffle Write operation refers to processing the data in memory and storing the final generated data in a temporary intermediate file. The Shuffle Read operation refers to the current node reading data from other nodes for aggregation (reduce).

[0057] (11) JVM (Java Virtual Machine): The JVM stores objects and variables during program execution in virtual memory, and implements memory management and access control.

[0058] Specifically, the JVM maps virtual addresses to actual physical memory and provides functions such as memory manager and garbage collection mechanism to manage the mapping relationship between virtual addresses and physical memory and memory usage.

[0059] (12) JVM Heap Memory: Heap memory provides an independent memory space for applications. This space is virtual and abstract. The heap memory in the JVM is a virtual memory area (also called a virtual memory region or virtual address space region, etc., which are not limited in this application) managed by the Java Garbage Collector. The main function of this virtual memory is to store and manage Java objects.

[0060] (13) JVM Off-Heap Memory: Off-heap memory in the JVM is memory outside of on-heap memory. Off-heap memory also provides an independent memory space for applications; this space is virtual and abstract. Unlike on-heap memory, off-heap memory is not managed by the garbage collector.

[0061] For example, the JVM provides automatic memory management for memory allocation. Specifically, in response to the needs of upper-layer applications or programs, the JVM allocates corresponding memory in Java memory and returns a virtual address to the application or program. Throughout the program's execution, the upper-layer application or program can access the corresponding memory space based on this virtual address. In other words, through virtual addresses, upper-layer applications or programs can perform operations such as memory allocation, release, and access (including reading and writing) without needing to concern themselves with the underlying hardware details and memory management algorithms.

[0062] In this embodiment of the application, the virtual memory provided by Java includes on-heap memory and off-heap memory. As mentioned above, both on-heap memory and off-heap memory are independent and abstract virtual memory.

[0063] For example, as described above, the virtual address space is actually an ordered set of non-negative integer virtual addresses. Heap memory and off-heap memory can also be viewed as two independent ordered sets of virtual addresses. Optionally, heap memory includes, but is not limited to, the on-heap memory virtual address space. Off-heap memory includes, but is not limited to, the off-heap memory virtual address space. During memory allocation, the JVM performs automatic memory allocation and management, and can allocate a contiguous virtual address region (also called a virtual memory address region) for an application or program in either on-heap or off-heap memory.

[0064] Figure 2 For an exemplary memory allocation diagram, please refer to... Figure 2 Taking heap memory as an example, the JVM allocates a virtual memory region from the heap memory in response to the application's needs. That is, it allocates a virtual address region (also called a virtual memory address region, etc., which is not limited to this application) consisting of multiple contiguous virtual addresses from the virtual address space of the heap memory for the application.

[0065] For example, as described above, the smallest unit of data used for memory management is a page, and correspondingly, Figure 2 Memory allocation in JVM can also be understood as the JVM allocating multiple contiguous virtual memory pages for the application. Each virtual memory page corresponds to a starting virtual address.

[0066] During memory allocation, the application's actual requirement is physical memory, and correspondingly, the system, in response to the application's needs, allocates physical memory for the application. As mentioned above, for the application and the JVM, physical memory is presented to the upper layers as virtual addresses. The system can explicitly allocate virtual memory regions for the application based on its needs through memory mapping. During access, memory mapping is used to map the virtual memory regions to the physical memory regions.

[0067] For example, refer to Figure 2After the JVM allocates a virtual address region for the application in the heap memory, it performs a mapping operation to map the virtual address region to physical memory. This can also be understood as mapping virtual memory pages to physical memory pages, or establishing a mapping relationship between the virtual address of the virtual address region and the physical address of physical memory. Specifically, the JVM can call the operating system's memory allocation interface (such as mmap). The operating system can respond to the JVM's call and establish a mapping relationship between virtual addresses and physical addresses, which can also be understood as a mapping relationship between virtual memory pages and physical memory pages. For example, mapping entries can be created in a mapping table. The contents of the entries are used to indicate the mapping relationship between virtual addresses and physical addresses. Specific implementation details can be found in existing technologies and will not be elaborated here.

[0068] For example, as mentioned above, Java's on-heap memory is managed by the garbage collector. Off-heap memory, however, is not managed by the garbage collector. Typically, developers need to explicitly manage off-heap memory through Java's Unsafe interface. However, since the allocation and deallocation of off-heap memory are manually managed by the user, if a user fails to properly release off-heap memory that will no longer be used, it can lead to memory leaks and other problems, affecting data security. Furthermore, in situations where memory resources are scarce, frequent allocation and deallocation of off-heap memory by users will affect memory allocation efficiency and reduce the overall memory access efficiency of the system.

[0069] Figure 3 This is a schematic diagram illustrating the structure of a computing device. The memory management method in this embodiment can be applied to a computing device, also referred to as a computing node, computing unit, etc., and is not limited thereto. The computing device can be a computer, server, etc., and is not limited thereto. Please refer to... Figure 3 The software structure in a computing device, from top to bottom, includes, but is not limited to: the application layer, the JVM layer, and the operating system layer.

[0070] The application layer can contain big data applications or programs, also known as data-intensive applications, characterized by high access volume and frequent access. Examples include, but are not limited to, Spark and Hadoop, and can be configured according to actual needs; this application does not impose any restrictions.

[0071] Optionally, in some instances, the application layer can also be called the big data framework layer. It is used to run data-intensive applications and shields developers from the management details of distributed devices. In other words, developers or operators can interact with the user interface provided by the application within the big data framework layer, issuing execution commands. In response to the received commands, the application or program generates corresponding execution commands and executes the corresponding operations collaboratively through the software and hardware in the computer device.

[0072] Still refer to Figure 3 For example, the modules in the JVM layer involved in this application embodiment include, but are not limited to: JVM memory allocation module, on-heap memory processing module, off-heap memory processing module, JVM Handler, etc. The JVM layer also includes, but is not limited to: on-heap memory and off-heap memory. The concepts of on-heap memory and off-heap memory are as described above and will not be repeated here. It should be noted that... Figure 3 The structure shown is merely an illustrative example; the JVM layer may include more modules, and this application does not limit it.

[0073] For example, the JVM memory allocation and access module provides a calling interface for applications or programs in the application layer, through which the application layer can issue memory allocation commands to the JVM layer. In response to the memory allocation commands (or instructions) from the application or program, the JVM memory allocation and access module calls the on-heap memory processing module or off-heap memory processing module in the JVM layer to allocate a virtual address region (also referred to as a virtual memory region, etc., which is not limited in this application) for the application in on-heap memory or off-heap memory.

[0074] The heap memory processing module is used to process heap memory, including but not limited to: managing heap memory (including allocating and releasing heap memory), accessing heap memory, and performing prefetching operations on heap memory. Optionally, the heap memory processing module may integrate a garbage collector, or the garbage collector may be a separate module; this application does not impose any limitations.

[0075] The off-heap memory management module manages off-heap memory (including its allocation and release), accesses it (including performing access and recovery operations), analyzes application access behavior to off-heap memory, and performs prefetching operations. Optionally, the off-heap memory management module is linked into the JVM as a dynamic link library.

[0076] The JVM processing module can optionally be an existing module of the JVM layer. In this embodiment, an exception handling process can optionally be added to the implementation of the existing module. In this embodiment, the JVM processing module can be used to handle some exception signals to perform a recovery process on the exception page. Specific implementation details are provided below.

[0077] For example, the hardware in the computer device involved in this application embodiment includes, but is not limited to, physical memory and disk. The concept of physical memory is as described above and will not be repeated here. In this application embodiment, the disk can be used to store memory page data swapped out by the off-heap memory processing module (i.e., data in physical memory pages).

[0078] It should be noted that this embodiment only uses the Java language environment as an example for illustration. In other instances, the memory management method in this embodiment can also be applied to Java environments. Figure 3 In other language-based software architectures with similar structures, the primary purpose is to manage on-heap and off-heap memory within layers of the operating system that constitute different language environments. Of course, in some instances, the on-heap and off-heap memory referred to in this application may use different names in layers of other language environments, and this application does not impose any limitations on this.

[0079] Figure 4 Please refer to the schematic diagram of the memory management method provided in this application. Figure 4 Specifically, including but not limited to the following steps:

[0080] S401, a new memory allocation behavior has been detected.

[0081] For example, during JVM runtime, the application performs new memory allocation actions. Each time the application needs to allocate memory, the computing device executes... Figure 4 The process described in this application embodiment is based on only one processing flow as an example, and the cyclic process will not be described one by one.

[0082] Figure 5 The following is a schematic diagram illustrating the module interaction as an example. Please refer to it. Figure 5 Applications send memory allocation instructions (or commands, signals, messages, etc.) to the JVM layer to instruct the JVM to perform memory allocation. Specifically, applications can invoke the JVM layer's memory allocation interface to issue memory allocation instructions to the JVM layer. In one example, the memory allocation interface could be a garbage collector interface. In another example, the memory allocation interface could be an Unsafe interface. If the memory allocation interface is a garbage collector interface, it can be understood that the memory allocation behavior is performed by calling the garbage collector interface, and this memory allocation behavior occurs in heap memory. If the memory allocation interface is an Unsafe interface, that is, the memory allocation behavior is performed by calling the Unsafe interface, and this memory allocation behavior occurs in off-heap memory.

[0083] Specifically, when the JVM memory allocation and access module detects that the application calls the corresponding memory allocation interface, it can determine that a new memory allocation behavior has occurred. In this embodiment of the application, it can also be understood as the JVM memory allocation and access module detecting that the corresponding interface has received a memory allocation instruction issued by the application.

[0084] Optionally, memory allocation instructions are used to indicate the required memory size. In one example, if the memory allocation occurs in heap memory, the memory allocation instructions may include, but are not limited to, objects. As mentioned above, the main function of heap memory is to store and manage Java objects. The required memory size is usually configured based on the size of the objects. In another example, if the memory allocation occurs in off-heap memory, the memory allocation instructions may include, but are not limited to, information about the required memory size (or dimensions). Optionally, in the case of memory allocation in heap memory, it can be understood that the memory allocation behavior is to allocate a memory region for an object, and then write the object into that memory region; that is, after memory allocation, the memory region is accessed. In the case of memory allocation in off-heap memory, the memory allocation behavior may be to allocate a memory region first, and then not access it immediately.

[0085] It should be noted that in this embodiment, the application requires physical memory, meaning it needs a block of physical memory allocated by the computing device for access. However, as mentioned above, the physical memory in the computing device provides virtual memory to the JVM layer and the application. For example, in a single memory allocation, if an application needs 2MB of physical memory, the JVM layer allocates a 2MB virtual memory region and provides the corresponding virtual address. This virtual memory region (e.g., V1) maps to a physical memory region (e.g., P1), and there is a mapping between the virtual address of the virtual memory region and the physical address of the physical memory region. The application writes data to V1, but in the computing device, the data is actually written to P1, which is mapped to V1. During memory access, the application uses the virtual address corresponding to V1. The computing device can find P1 corresponding to V1 based on the mapping relationship. Accordingly, in this embodiment, memory allocation actually refers to the application needing a block of physical memory (or a physical memory region), while in the specific implementation, the system presents virtual memory (or a virtual memory region) to the application.

[0086] S402 determines whether the event occurred within the heap.

[0087] For example, the JVM layer can determine whether the memory allocation occurred in the heap based on the current memory allocation behavior, and based on the determination result, notify the corresponding module to further process the current memory allocation behavior.

[0088] Specifically, please refer to Figure 5The JVM memory allocation and access module can determine whether a memory allocation action occurs within the heap in response to a memory allocation interface called by the application. In one example, if the application calls a garbage collector interface, the memory allocation action is determined to have occurred within the heap. In another example, if the application calls an Unsafe interface, the memory allocation action is determined to have occurred outside the heap. Of course, this embodiment only illustrates the interface call and corresponding judgment method within the Java language environment. In other embodiments, the judgment conditions differ depending on the execution environment, and this application does not impose limitations.

[0089] In this embodiment of the application, after the judgment is performed, subsequent steps can be executed based on the judgment result. In the subsequent process, different modules will execute corresponding steps. In one example, if it is determined that the event occurred inside the heap, then S403 is executed; in another example, if it is determined that the event occurred outside the heap, then S404 is executed.

[0090] S403 notifies the heap memory management module to process the request.

[0091] For example, refer to Figure 5 The JVM memory allocation and access module notifies the heap memory processing module to continue processing the current memory allocation. Specifically, the JVM memory allocation and access module sends a notification to the heap memory processing module, instructing the heap memory processing module to allocate a virtual memory region for the application in the heap memory in response to the application's needs, and to process the virtual memory region. Specific processing operations may include, but are not limited to: managing the virtual memory region (including allocation and deallocation), prefetching the corresponding memory page, and accessing the corresponding memory page.

[0092] Optionally, this embodiment of the application uses the example of memory allocation and access operations being processed in the same module. In other embodiments, the on-heap memory processing module may also be used only for memory allocation, management, and prefetching operations, while the specific access operations may be performed by other modules. This application does not impose any limitations on this, and will not be repeated below.

[0093] S404 notifies the off-heap memory management module to process the request.

[0094] For example, refer to Figure 5The JVM memory allocation and access module notifies the off-heap memory processing module to continue processing the current memory allocation. Specifically, the JVM memory allocation and access module sends a notification to the off-heap memory processing module, instructing the module to allocate a virtual memory region for the application in off-heap memory in response to the application's needs, and to process this virtual memory region. Specific processing operations may include, but are not limited to: managing the virtual memory region (including allocation and deallocation), prefetching the corresponding memory pages, and accessing the corresponding memory pages.

[0095] The following sections provide a detailed explanation of the memory allocation process that occurs in both on-heap and off-heap memory.

[0096] Heap memory processing flow:

[0097] Figure 6 For an illustrative diagram of the on-heap memory processing flow, please refer to... Figure 6 Specifically, including but not limited to the following steps:

[0098] S601, Determine the type of the new object.

[0099] For example, the JVM, as the language virtual machine, manages the memory allocation behavior of upper-layer Java applications. When an upper-layer application creates a new object using keywords such as `new`, it calls the memory allocation interface in the JVM to perform actual memory allocation in the heap memory managed by the JVM itself. During this interaction, the application only needs to provide the type information of the object to be created and the data information of any existing object fields. The JVM determines the size of the memory space required for the newly allocated object based on the object type and fills the data provided by the application into the corresponding location in the heap memory after allocation. As mentioned above, the size of the memory space required by the object in the JVM refers to the required virtual memory space, while in actual storage, it refers to the required physical memory space. This process describes the execution steps at the JVM layer. Therefore, unless otherwise specified, memory, memory pages, and memory space mentioned in this process all refer to virtual memory, virtual memory pages, and virtual memory space, which will not be repeated below.

[0100] In this embodiment of the application, when the JVM starts, the heap memory processing module creates and runs a prefetch thread that polls and waits for new heap memory allocation behavior to occur. This thread can be used to execute the prefetch process that occurs in heap memory as described in the following embodiments. The specific implementation will be described in detail below.

[0101] Figure 7 The following is a schematic diagram illustrating the module interaction as an example. Please refer to it. Figure 7Specifically, the JVM memory allocation and access module receives memory allocation instructions (or memory allocation requests) from the application, indicating the amount of memory required by the application. After determining that the memory allocation occurs in heap memory, the JVM memory allocation and access module sends notification information to the heap memory processing module. This notification information includes, but is not limited to, memory allocation information, which indicates the location and size of the target virtual memory region allocated for the application in heap memory. As mentioned above, allocating virtual memory in heap memory can also be understood as allocating a contiguous virtual address region for the application from the virtual address space corresponding to the heap memory. This virtual address region can correspond to one or more virtual memory pages. Optionally, the memory allocation information includes, but is not limited to, the starting virtual address and length information. The length information indicates the size of the newly allocated object, which can also be understood as the size of the virtual memory region required by the newly allocated object.

[0102] For example, the on-heap memory processing module allocates a corresponding virtual memory region (e.g., for) the new object in the on-heap memory based on memory allocation information. Figure 7 The target virtual memory region shown is for illustrative purposes only and its location and size are not limited in this application. After the heap memory processing module allocates a virtual memory region for the application, it can perform prefetching and access operations on the virtual memory pages contained in the virtual memory region. This prefetching operation establishes a mapping relationship between virtual memory pages and physical memory pages in advance, and writes object data into the virtual memory pages. For the JVM layer, the access operation involves writing data into the virtual memory page; during actual execution, the operating system can write the data into the physical memory page corresponding to the virtual memory page.

[0103] Specifically, the in-heap memory processing module determines the type of the newly allocated object based on memory allocation information. In this embodiment, the object type includes, but is not limited to, large object type and small object type.

[0104] For example, the on-heap memory processing module can pre-set object type conditions (which can be set according to actual needs, and this application does not limit this). In one example, if the size (or dimensions) of the new object meets the object type conditions, then the object is a large object type. In another example, if the size of the new object does not meet the object type conditions, then the object is a small object type.

[0105] Optionally, the object type condition can be a fixed threshold or a variable threshold set based on the current remaining amount of memory in the heap. It can be set according to actual needs, and this application does not limit it.

[0106] In this embodiment, the on-heap memory processing module determines the object type based on the object size, and then performs specific prefetching operations based on the specific object type.

[0107] In one example, if the new object is a large object type, meaning the newly allocated object requires a large amount of memory, then S602 is executed. That is, the on-heap memory handling module attempts to prefetch all the memory pages that this object will use.

[0108] In another example, if the new object is a small object type, meaning the newly allocated object requires less memory, then S603 is executed. That is, the heap memory handling module performs prefetching operations at the granularity of the thread local allocation buffer (TLAB).

[0109] It can be understood that, in the embodiments of this application, different prefetching processes can be executed for different object types to meet the allocation and access requirements of different objects.

[0110] S602, prefetch all virtual memory pages of a large object.

[0111] For example, the on-heap memory processing module performs a prefetch operation on all virtual memory pages of a large object. Specifically, a pre-established prefetch thread will attempt to prefetch all virtual memory pages that the large object will use, based on the memory allocation information corresponding to the object. The virtual memory page corresponding to the starting virtual address in the memory allocation information is the starting virtual memory page. The prefetch thread can start from the starting virtual memory page and prefetch all virtual memory pages according to the length indicated by the length information.

[0112] For example, the prefetch process can be understood as a process of pre-mapping virtual memory pages to physical memory pages. Specifically, during access, if a virtual memory page is not mapped to a physical memory page, the operating system will execute a page fault handling process. The system will switch from user mode to kernel mode to perform post-page fault processing, execute the swap-in / swap-out process between physical memory pages and physical pages on disk, and establish a mapping relationship between the virtual memory page and the new physical memory page. After the mapping relationship is established, the access is re-executed. The prefetch process can be understood as the process of pre-establishing a mapping relationship between all virtual memory pages indicated by the memory allocation information and physical memory pages before access; it can also be understood as the process of mapping the virtual address of a virtual memory page to the physical address of a physical memory page. The specific swap-in / swap-out process and the establishment of the mapping relationship can be found in existing technical embodiments, and this application does not limit it.

[0113] Specifically, the prefetch thread determines the virtual memory pages to be prefetched based on memory allocation information. For example, the prefetch thread can transmit the virtual address corresponding to the virtual memory page to be prefetched to the operating system, which then completes the prefetching process for the physical page corresponding to the virtual memory page.

[0114] It should be noted that the attempted prefetching mentioned above can be understood as follows: some virtual memory pages may already be mapped to physical memory pages; for these virtual memory pages, no further prefetching operations are needed. However, for unmapped virtual memory pages, prefetching operations are required.

[0115] In this way, for large objects, by performing prefetching operations on all virtual memory pages, page fault handling can be avoided during access, which can effectively improve memory access efficiency and the overall system processing efficiency.

[0116] For example, the on-heap memory processing module can start an access thread. The access thread can perform access operations on the virtual memory space based on the object's starting virtual address and length information. For instance, the access thread can write data provided by the application to a virtual memory page in the on-heap memory. Specifically, the access thread obtains the object's starting virtual address and length information in the on-heap memory, as well as the data to be written. The access thread can transmit the starting virtual address, length information, write instructions, and data to the operating system, which, along with the storage, completes the operation of writing the data to the physical memory page corresponding to the virtual memory page. The underlying addressing and access execution logic of the operating system and storage can be found in existing technical embodiments, and this application does not limit it.

[0117] In one possible implementation, the access thread and the prefetch thread execute asynchronously. Optionally, the prefetch thread executes before the access thread. In one example, the access thread performs access operations on the virtual memory pages only after the prefetch thread has finished executing. In another example, the access thread can begin performing access operations at any time after the prefetch thread has started executing.

[0118] S603, check the current TLAB usage status.

[0119] For example, newly allocated small objects, i.e., objects of the small object type, require less memory space; for instance, a small object might require one or two virtual memory pages (this is just an illustrative example). In this embodiment, the heap memory processing module prefetches virtual memory pages for small object types at the TLAB granularity. Specifically, the prefetch thread detects the usage of currently used TLABs. For example, the TLAB in the JVM is a data structure private to each Java thread, maintaining a private memory space for each Java thread. Memory allocation within this space can avoid thread contention, thereby improving application allocation performance.

[0120] For example, the on-heap memory processing module may be configured with usage conditions. The usage conditions may be a threshold or other variable values, which can be set according to actual needs, and this application does not limit them.

[0121] S604, prefetch the virtual memory page of the next TLAB to be used.

[0122] For example, the on-heap memory processing module determines whether the prefetched execution object is the current TLAB or a new TLAB based on TLAB usage.

[0123] In one example, if the usage of the currently used TLAB meets the usage conditions, such as the remaining space being greater than or equal to the threshold set in the usage conditions, then it is possible to attempt to prefetch all virtual memory pages allocated for the small object backward (e.g., one or two, which is not limited in this application). The virtual memory pages prefetched backward may optionally be the starting virtual memory page to which the starting virtual address belongs, or the starting virtual memory page and one or more consecutive virtual memory pages thereafter.

[0124] In another example, if the usage of the currently used TLAB does not meet the usage conditions, such as the remaining space being less than the threshold set in the usage conditions, then a new TLAB needs to be allocated. When the new TLAB is allocated, all virtual memory pages allocated for small objects in the new TLAB are prefetched, such as the first or a series of consecutive virtual memory pages in the new TLAB.

[0125] This can be understood as follows: due to the limited size of the TLAB, there may be insufficient remaining space in the TLAB when allocating a new object. In this case, the JVM will allocate a new TLAB for this thread before performing the memory allocation operation for the new object. Therefore, in order to implement the corresponding heap memory prefetching mechanism, this application needs to perform a prefetch operation on the newly allocated TLAB.

[0126] Optionally, in this embodiment, the threshold for determining the size of an object can be set to a value less than or equal to the size of a virtual memory page. In this way, only one virtual memory page is typically allocated to small object types to meet application requirements. In this scenario, prefetching one virtual memory page allocated to the small object, or prefetching the first virtual memory page in a new TLAB, is sufficient to achieve the desired prefetching effect.

[0127] The details of the prefetch operation can be found in the large object prefetch operation in the above embodiment, and will not be repeated here.

[0128] Off-heap memory processing flow:

[0129] Figure 8 For an illustrative diagram of the off-heap memory processing flow, please refer to... Figure 8 Specifically, including but not limited to the following steps:

[0130] S801 allocates the target virtual memory region for the application in off-heap memory.

[0131] For example, if the application's memory allocation instruction (or request) is sent to the JVM layer through the Unsafe interface, the JVM memory allocation and access module can determine that this memory allocation behavior is handled by the off-heap memory processing module.

[0132] Figure 9 The following is a schematic diagram illustrating the module interaction as an example. Please refer to it. Figure 9 For example, in response to an application's memory allocation instruction, the JVM memory allocation and access module sends a notification message to the off-heap memory processing module. This notification message instructs the off-heap memory processing module to allocate a virtual memory region for the application in off-heap memory in response to the application's request. The notification message includes, but is not limited to, memory allocation information, which indicates the location and size of the target virtual memory region allocated to the application in off-heap memory. As described above, allocating virtual memory in off-heap memory can also be understood as allocating a contiguous virtual address region for the application from the virtual address space corresponding to the off-heap memory. This virtual address region may correspond to one or more virtual memory pages. Optionally, the memory allocation information includes, but is not limited to, a starting virtual address and length information. The length information indicates the size (or dimensions) of the target virtual memory region.

[0133] The off-heap memory processing module responds to memory allocation information and allocates a target virtual memory region for the application in off-heap memory. This can also be understood as allocating a contiguous virtual address region for the application in the virtual address space of off-heap memory.

[0134] Specifically, the off-heap memory processing module allocates the target virtual memory region to the application based on memory allocation information, establishing a mapping relationship between virtual memory pages in the target virtual memory region and physical memory pages. This can also be understood as establishing a mapping relationship between the virtual addresses of the target virtual memory region (i.e., the starting virtual address of each virtual memory page) and the physical addresses in physical memory (i.e., the starting physical address of each physical page). A description of the mapping relationship can be found in [reference needed]. Figure 1 and Figure 2 The relevant content will not be repeated here.

[0135] Optionally, in this embodiment, the memory allocation and access behavior of off-heap memory can be independent. This differs from on-heap memory, where memory allocation immediately writes the corresponding data to memory. Off-heap memory allocation and access can exist independently; that is, the off-heap memory processing module allocates memory for the application in response to its needs. When the application needs to access this virtual memory region, it issues an access command to access one or more virtual memory pages contained within the virtual memory region.

[0136] S802, determine whether the resource release conditions are met.

[0137] For example, the off-heap memory processing module is configured with resource release conditions. In this embodiment, the resource release condition is used to indicate that the allocated resources in off-heap memory exceed a resource threshold, and to release the excess portion of the virtual memory region. The allocated resources in off-heap memory may optionally be virtual memory resources (i.e., virtual address regions) that have been mapped to physical memory, including virtual memory pages previously allocated to applications (which may be the same application or different applications) and which still maintain a mapping relationship. Figure 7 The target virtual memory region has just been allocated to the application. It should be noted that, in this embodiment, the virtual memory resources already allocated to the application may be released, i.e., the mapping between them and physical memory may be canceled. Therefore, the allocated resources mentioned above refer to virtual memory resources (i.e., virtual address regions) that have been allocated to the application and still maintain a mapping relationship, excluding those whose mapping has been canceled.

[0138] Optionally, the resource threshold can be understood as limiting the current usage of physical memory by off-heap memory. For example, the resource threshold can be set to 80% of off-heap memory, meaning that if the allocated off-heap memory usage exceeds 80% of the total, S803 can be executed. Thus, by setting a threshold, the usage of physical memory by off-heap memory is reduced, saving physical memory resources when they are scarce. This can be understood as follows: in the system, the number of virtual memory pages in off-heap memory is greater than the number of physical memory pages in physical memory, providing sufficient virtual memory resources to the application and JVM layer, while physical memory resources can meet the mapping requirements of virtual memory resources through swapping in and out. In this embodiment, by setting a resource threshold for off-heap virtual memory resources, unnecessary resource waste can be reduced when physical memory resources are scarce. Specifically, the resource threshold in this embodiment can be set based on the usage of physical memory resources. Although it is used to limit the use of virtual memory resources in off-heap memory, it is essentially to reduce the waste of physical memory resources. Its specific value can be set according to actual needs, and this application does not limit it.

[0139] In one example, if the allocated resources in off-heap memory meet the resource release conditions, such as being greater than a resource threshold, then S803 is executed.

[0140] In another example, if the allocated resources in off-heap memory do not meet the resource release conditions, such as being less than or equal to the resource threshold, then the allocation process ends.

[0141] In one possible implementation, virtual memory region management is a dynamic management approach. Specifically, the JVM layer and operating system typically swap physical pages corresponding to hot data (i.e., frequently accessed or soon-to-be-accessed data) into physical memory and swap physical pages corresponding to cold data (i.e., infrequently accessed data) out of disk, updating the mapping between virtual memory pages and physical memory pages. Therefore, virtual addresses in off-heap memory can be dynamically released or mapped; specific implementations can refer to existing technologies, and this application does not limit this. Based on this dynamic management approach, the size and location of the allocated virtual memory region may change with the dynamic management. For example, if the target virtual memory region allocated in this instance causes the size of the allocated virtual memory region to exceed the resource threshold, some virtual memory pages in the allocated virtual memory region may have already been released before the next allocation of off-heap memory, meaning they are no longer mapped to physical memory pages. Correspondingly, when S802 is executed after the next allocation of off-heap memory, the resource release conditions may not be met, meaning there is no need to release off-heap memory resources.

[0142] S803 cancels the mapping relationship of virtual memory sub-regions.

[0143] For example, if the off-heap memory processing module detects that the allocated resources meet the resource release conditions, it will release the excess virtual memory region and its mapped physical memory region.

[0144] Specifically, after JVM initialization, the off-heap memory processing module records the maximum amount of off-heap memory currently allowed by the system (e.g., the resource threshold in this embodiment). When information about a new off-heap memory block is passed to the off-heap memory processing module, the module checks whether the remaining amount of off-heap memory meets the requirements of the newly allocated memory block. If not, meaning the currently used virtual memory resources (including the newly allocated virtual memory resources in S801) exceed the system's maximum limit, the off-heap memory processing module uses the munmap interface provided by the operating system to unmap the portion exceeding the limit. The operating system can, based on the instructions of the off-heap memory processing module, cancel the mapping between a specified virtual memory page and physical memory. In this way, the unmapped virtual memory pages will not actually occupy physical memory, thereby ensuring that the total amount of off-heap memory used by the system never exceeds the given limit, ultimately achieving the beneficial effect of limiting application memory usage in scenarios where memory resources are scarce. The operating system's unmapping operation can be operations such as deleting entries indicating the mapping relationship between virtual memory pages and physical memory pages; specific implementations can refer to existing technologies, which will not be elaborated upon here.

[0145] For example, the off-heap memory processing module can record the state of each virtual memory page (or virtual address region), including but not limited to: allocated, unallocated, and freed. Allocated can optionally be a virtual memory page that has been allocated to an application and has a mapping relationship with a physical memory page. Unallocated can optionally be a virtual memory page that has not been allocated to any application, meaning that the virtual memory page can be allocated to other applications. Freed can optionally be a virtual memory page that is freed after execution based on S803.

[0146] For example, the off-heap memory processing module feeds back memory allocation information to the JVM memory allocation and access module. This memory allocation information includes, but is not limited to, the target virtual address region allocated to the application, and may also include released virtual address sub-regions. The JVM memory allocation and access module can then feed back the target virtual address region to the application, enabling the application to access the virtual memory page corresponding to any virtual address within the target virtual address region.

[0147] Figure 10 For an illustrative diagram of off-heap memory management, please refer to... Figure 10 Specifically, the off-heap memory processing module detects that the allocated virtual memory region exceeds the resource threshold. As mentioned above, the allocated virtual memory region includes the target virtual memory region allocated to the application. Figure 10 The size and location of the allocated virtual memory region shown are merely illustrative examples and are not intended to be limiting.

[0148] Still refer to Figure 10The off-heap memory processing module releases the portion of the target virtual memory region that exceeds the resource threshold (which can be referred to as a virtual memory sub-region in this embodiment). In this embodiment, releasing virtual memory resources means canceling the mapping between virtual memory pages and physical memory pages. As mentioned above, a mapping relationship between virtual memory pages and physical memory pages has been established during memory allocation. The off-heap memory processing module can release virtual memory pages and their corresponding physical memory pages by canceling the mapping relationship between the virtual memory pages corresponding to the virtual memory sub-regions and the corresponding physical memory pages. It can be understood that releasing virtual memory pages and their physical memory as described in this embodiment means canceling the mapping relationship, so that the released physical memory pages can be mapped to other virtual memory pages in the next memory allocation. The virtual memory pages are still occupied, that is, the virtual address regions already allocated to applications will not be allocated to other applications. During the application access process, it can use the virtual address allocated to it to access the corresponding virtual memory pages. During the access process, the off-heap memory processing module executes the virtual memory page recovery and prefetching process in the following embodiment to enable the application to access the unmapped virtual memory pages.

[0149] This can be understood as follows: when physical memory resources are scarce, new memory allocations may cause physical pages in physical memory to be swapped out. Frequent swapping in and out will reduce the memory allocation rate and affect the overall memory allocation and access efficiency of the system. This application limits the amount of off-heap memory used and releases the portion exceeding the threshold to reduce the unnecessary occupation of physical memory by off-heap memory, thereby reducing the impact of additional memory swapping on system performance in scenarios where physical memory resources are scarce.

[0150] For example, off-heap memory allocates a target virtual memory region for a first application and releases a portion of the target virtual memory region's virtual memory sub-regions, such as canceling the mapping relationship between the first virtual memory page and the first physical memory page, i.e., releasing the first virtual memory page and its first physical memory page. Before the first application accesses the target virtual memory region, a second application requests access to a target virtual memory page (possibly one or more). If the target virtual memory page requested by the second application is not mapped to physical memory, during the off-heap memory processing module's access to the target virtual memory page, the operating system can establish a mapping relationship between the target virtual memory page and the first physical memory page, allowing the application and the JVM layer to access the first physical memory page based on the target virtual memory page. Thus, since a usable first physical memory page exists, there is no need to perform swapping in and out of physical memory, effectively improving the efficiency of memory allocation and access under conditions of scarce physical memory resources.

[0151] For example, as described above, the allocation and access of off-heap memory can be independent. At any time after memory allocation, the application can access the virtual memory page containing the corresponding virtual address based on the virtual address allocated to it in off-heap memory. For virtual memory pages that have been unmapped, this application provides an access method that can combine a prefetching mechanism during the access process to reduce the impact of additional SIGSEGV exceptions on application performance and improve system processing performance.

[0152] Specifically, in existing technologies, the unmapping of off-heap memory is usually handled manually by the user. If an application accesses an off-heap virtual memory page that has been manually unmapped, a SIGSEGV exception will be triggered, indicating that the application and JVM have executed an invalid memory reference, which may lead to system crashes. The off-heap memory processing module in this application provides a recovery access process for SIGSEGV exceptions triggered by applications accessing released virtual memory sub-regions, enabling applications and the JVM layer to access the memory normally. Figure 8 The virtual memory sub-regions that are released during the process.

[0153] Figure 11 For an illustrative diagram of the off-heap memory processing flow, please refer to... Figure 11 Specifically, the application sends a memory access request to the JVM layer, which includes, but is not limited to, accessing an address. Optionally, the access address can be the starting address of a virtual memory page in off-heap memory that the application wants to access.

[0154] Specifically, the JVM memory allocation and access module responds to memory access requests by checking the validity of the access address. As mentioned above, if the access address is unmapped, it is considered an invalid access address, and the application's access behavior can be interpreted as an invalid access behavior, which will trigger a SIGSEGV exception. For example, as described above, Figure 8 After the process in the middle is completed, the JVM memory allocation and access module can obtain the freed virtual address region, which can also be understood as obtaining the freed virtual addresses, or even the freed virtual memory pages. Based on the recorded freed virtual address region, the JVM memory allocation and access module can check whether the access address is within that range.

[0155] In one example, if the accessed address is not within the freed virtual address range, for example, if the accessed address is in... Figure 11Within the gray shaded area of ​​the target virtual memory region, the JVM memory allocation and access module can notify the off-heap memory processing module to access the virtual memory page to which the access address belongs. The off-heap memory processing module, responding to the instruction from the JVM memory allocation and access module, performs the access operation on the virtual memory page to which the access address belongs. Specific access operations can refer to existing technologies, and this application does not limit them.

[0156] In another example, if the JVM memory allocation and access module detects that the access address is not within the recorded freed virtual address range, for example, the access address is in... Figure 11 Within the shaded area of ​​the target virtual memory region, the JVM memory allocation and access module notifies the JVM processing module to execute the SIGSEGV exception handling process. Specifically, the JVM memory allocation and access module sends a SIGSEGV exception request (or signal) to the JVM processing module. This request includes, but is not limited to, the accessed address and a freeing indication. The freeing indication information indicates that the virtual memory page to which the accessed address belongs is being executed. Figure 8 The virtual memory pages released during the process described herein. In response to a SIGSEGV exception request, the JVM processing module sends a recovery request to the off-heap memory processing module. This request includes, but is not limited to, the accessed address and recovery instruction information. The recovery instruction information instructs the off-heap memory processing module to restore the mapping relationship of the virtual memory page belonging to that accessed address. Of course, in some instances, if the SIGSEGV exception is triggered by a user manually canceling the mapping relationship, or for other reasons, the JVM processing module will still handle it according to existing technical procedures, which may still lead to system crashes; this application does not impose limitations on this.

[0157] Figure 12 For an illustrative diagram of the off-heap memory processing flow, please refer to... Figure 12 Specifically, including but not limited to the following steps:

[0158] S1201 checks whether the allocated resources in off-heap memory are about to meet the resource release conditions.

[0159] For example, before accessing virtual memory, it is necessary to remap the released virtual memory pages to physical memory pages. Before this, off-heap memory checks whether the allocated resources will meet the resource release conditions. Although the virtual memory page to be accessed (i.e., the virtual memory page to which the access address belongs) is not yet mapped to physical memory, it is still considered in this step to check whether the allocated resources in off-heap memory will meet the resource release conditions after the virtual memory page is mapped to another virtual memory page (i.e., the released virtual memory page is updated to an allocated virtual memory page). The determination method is the same as described above and will not be repeated here.

[0160] In one example, if the resource release condition is met, which can be understood as the amount of physical memory used by off-heap memory has reached the system's upper limit, then S1202 is executed.

[0161] In another instance, if the resource release condition is not met, i.e., the amount of physical memory used by off-heap memory has not reached the system's upper limit, then S1204 is executed.

[0162] S1202, Select a physical memory page that is currently in a mapped state.

[0163] For example, the off-heap memory processing module can select a virtual memory page (denoted as the virtual memory page to be swapped) from the virtual memory pages currently in the allocated state. The selection method can be in ascending order of starting address or random selection; this application does not limit the selection. The off-heap memory processing module can call the operating system interface to instruct the operating system to swap out the physical memory page corresponding to the virtual memory page to be swapped, that is, the physical memory page currently mapped to the virtual memory page to be swapped, to the disk.

[0164] S1203 swaps the selected physical memory page to disk and cancels the mapping relationship between the physical memory page and the virtual memory page.

[0165] For example, in response to an instruction from the off-heap memory processing module, the operating system swaps out the physical memory page to be swapped to the disk and cancels the mapping relationship between the physical memory page to be swapped and the virtual memory page to be swapped, thereby controlling the total amount of off-heap memory usage to remain within the range limited by the resource release conditions.

[0166] S1204 determines whether the physical memory page to be accessed has been swapped out to disk.

[0167] For example, the operating system can determine whether the physical memory page to be accessed has been swapped out to disk.

[0168] In one example, if swapped out to disk, S1205 is executed.

[0169] In another example, if it is not swapped out to disk, then S1206 is executed.

[0170] S1205 remaps data swapped out to disk via file mapping.

[0171] S1206, recovery is performed via anonymous mapping.

[0172] Specifically, the purpose of S1205 and S1206 is to swap physical pages from the disk into physical memory, providing a new physical memory page in physical memory and establishing a mapping between this physical memory page and the virtual memory page to be accessed. Thus, through the recovery process in this application, the mapping relationship between the released virtual memory page and the physical memory page in physical memory can be re-established. The physical memory page in the new mapping relationship may be the same as or a different physical memory page from the physical memory page released in S803; this application does not impose any limitations on this.

[0173] For example, the methods of file mapping and anonymous mapping can be referred to the description in the memory mapping section above, and the specific implementation can be referred to the existing technical embodiments. This application does not limit them.

[0174] S1207, re-execute the memory access request.

[0175] For example, the operating system re-establishes the mapping relationship between virtual memory pages and physical memory pages. This can also be understood as establishing a mapping relationship between the access address and the physical address in physical memory. Afterward, the JVM memory allocation and access module can re-execute access operations on the access address based on the access request. Since the access address already has a mapping relationship—that is, the virtual memory page to which the access address belongs is mapped to a physical memory page in physical memory—it can be processed according to the normal access process. This means that the SIGSEGV exception handling process will no longer be triggered. For details on the access process, please refer to [reference needed]. Figure 11 The relevant descriptions in the document will not be repeated here.

[0176] In one possible implementation, the off-heap memory handling module can start access and recovery threads for execution. Figure 12 The process allows for both access to normally mapped virtual memory pages and restoration of released virtual memory pages.

[0177] In the embodiments of this application, such as Figure 11 As shown, the off-heap memory processing module can also perform a prefetching process on off-heap memory. Specifically, the off-heap memory processing module can pre-create a prefetching thread to analyze memory access behavior and perform prefetching operations based on the analysis results.

[0178] Figure 13 For an illustrative example of the prefetching process, please refer to... Figure 13 Specifically, including but not limited to the following steps:

[0179] S1301, Perform semantic analysis on the access behavior and obtain the semantic analysis results.

[0180] For example, the off-heap memory processing module starts a prefetch thread, which can perform semantic analysis on the access operations (also known as memory access behavior) performed by the access thread to obtain semantic analysis results.

[0181] Specifically, the prefetch thread and the access and recovery thread are two asynchronously executed threads. During the access and recovery thread's access process, the prefetch thread can perform semantic analysis based on the access behavior of the access thread. In this embodiment, the prefetch thread can periodically (which can be denoted as the sampling period) acquire the memory access behavior of the access thread; for example, the prefetch thread executes once for every 10 access behaviors performed by the access and recovery thread. Figure 13 The process is shown. The execution conditions (i.e., the sampling period) can be set according to actual needs, and this application does not impose any restrictions.

[0182] The semantic analysis of memory access behavior by the prefetch thread can be achieved by detecting whether the virtual memory pages accessed by the application are contiguous within the sampling period. In one example, if the virtual memory pages are contiguous, it can be determined that the application's access to off-heap memory is non-random. In another example, if the virtual memory pages are non-contiguous, it can be determined that the application's access to off-heap memory is random.

[0183] S1302, Based on the semantic analysis results, determine the virtual memory pages to be prefetched.

[0184] For example, the off-heap memory module can determine the virtual memory pages to be prefetched based on the semantic analysis results of the application's memory access behavior.

[0185] In one example, if the semantic analysis results indicate that the application's memory access behavior is a non-random access type, the off-heap memory processing module (specifically, the prefetch thread) can determine that the virtual memory pages that need to be prefetched (i.e., the virtual memory pages to be prefetched) can be one or more consecutive virtual memory pages following the virtual memory page most recently accessed by the application.

[0186] In another example, if the semantic analysis results indicate that the application's memory access behavior is of the random access type, the off-heap memory processing module may determine that the virtual memory pages to be prefetched are optionally: one or more consecutive virtual memory pages before and / or after the most recently accessed virtual memory page. Alternatively, they may also be one or more consecutive virtual memory pages before and / or after each accessed virtual memory page within the sampling period.

[0187] S1303 performs a prefetch operation on the virtual memory pages to be fetched.

[0188] For example, the prefetch thread can perform a prefetch operation on the virtual memory pages to be prefetched. For details on the prefetch operation, please refer to the above text, which will not be repeated here.

[0189] Figure 14 A schematic block diagram of a memory management device 1400 according to an embodiment of this application is shown. The memory management device 1400 may include a processor 1401 and a transceiver / transceiver pin 1402, and optionally, a memory 1403. The processor 1401 can be used to execute the steps performed by the computing node in the methods of the foregoing embodiments, and control the receive pin to receive signals, and control the transmit pin to transmit signals.

[0190] The various components of the memory management device 1400 are coupled together via a bus 1404, which includes a data bus, a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus system 1404 in the figure.

[0191] Optionally, the memory 1403 can be used for storage instructions in the foregoing method embodiments.

[0192] It should be understood that the memory management device 1400 according to the embodiments of this application may correspond to the computing nodes in the methods of the foregoing embodiments, and the above and other management operations and / or functions of each element in the memory management device 1400 are respectively for implementing the corresponding steps of the foregoing methods. For the sake of brevity, they will not be described in detail here.

[0193] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0194] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a memory management device to control the memory management device to implement the above-described method embodiments.

[0195] Based on the same technical concept, this application also provides a computer program, which, when executed by a memory management device, is used to implement the above-described method embodiments.

[0196] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0197] Based on the same technical concept, this application also provides a processor for implementing the above-described method embodiments. The processor can be a chip.

[0198] The steps of the methods or algorithms described in conjunction with the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor.

[0199] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0200] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0201] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0202] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0203] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0204] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A memory management method, characterized in that, include: In response to the application's first memory allocation request, a first virtual address region is allocated for the application in off-heap memory; Establish a mapping relationship between the first virtual address region and at least one physical page in physical memory; If the resources occupied by the first virtual address region meet the resource release conditions, at least one first physical memory page mapped to the sub-virtual address region is released. The sub-virtual address region belongs to the first virtual address region, and the at least one first physical memory page belongs to the at least one physical memory page.

2. The method according to claim 1, characterized in that, The release of at least one first physical memory page mapped to a sub-virtual address region includes: Cancel the mapping relationship between the sub-virtual address region and the at least one first physical page.

3. The method according to claim 1, characterized in that, After releasing at least one first physical memory page mapped to a sub-virtual address region, the method further includes: Obtain a first access request, wherein the first access request is used to request access to the physical memory corresponding to the first virtual address; If the first virtual address belongs to the sub-virtual address region, establish a mapping relationship between the first virtual address and the second physical page; Based on the first access request, the corresponding access operation is performed on the second physical page.

4. The method according to claim 3, characterized in that, After obtaining the first access request, the method further includes: Based on the first access request and multiple previous access requests, semantic analysis is performed on the access behavior of the application to determine the access behavior type corresponding to the access behavior of the application. If the access behavior type is random access, perform a prefetch operation on multiple consecutive virtual memory pages before and / or after the first virtual address; If the access behavior type is a non-random access type, a prefetch operation is performed on multiple consecutive virtual memory pages following the first virtual address.

5. The method according to claim 4, characterized in that, The prefetch operation includes: Detect whether each of the virtual memory pages is mapped to physical memory; If any virtual memory page is not mapped to physical memory, establish a mapping relationship between the virtual memory page and the third physical memory page.

6. The method according to claim 1, characterized in that, The resource release condition is used to indicate that the allocated resources in the off-heap memory are greater than a first value; wherein, the resources occupied by the first virtual address region are included in the allocated resources in the off-heap memory.

7. The method according to claim 1, characterized in that, The method further includes: In response to the application's second memory allocation request, a second virtual address region is allocated for the application in the heap memory; Perform a prefetch operation on at least one virtual memory page contained in the second virtual address region to prefetch physical pages from the disk into physical memory; Establish a mapping relationship between the second virtual address region and at least one fourth physical memory page, wherein the at least one fourth physical memory page includes a physical memory page that has been prefetched into the physical memory through the prefetch operation.

8. A memory management device, characterized in that, include: The memory allocation and access module is used to allocate a first virtual address region for the application in off-heap memory in response to the application's first memory allocation request; An off-heap memory processing module is used to establish a mapping relationship between the first virtual address region and at least one physical page in physical memory; The off-heap memory processing module is further configured to release at least one first physical memory page mapped to a sub-virtual address region if the resources occupied by the first virtual address region meet the resource release conditions, wherein the sub-virtual address region belongs to the first virtual address region and the at least one first physical memory page belongs to the at least one physical memory page.

9. The apparatus according to claim 8, characterized in that, The off-heap memory processing module is specifically used for: Cancel the mapping relationship between the sub-virtual address region and the at least one first physical page.

10. The apparatus according to claim 8, characterized in that, The memory allocation and access module is further configured to obtain a first access request, wherein the first access request is used to request access to the physical memory corresponding to the first virtual address; The off-heap memory processing module is further configured to establish a mapping relationship between the first virtual address and the second physical page if the first virtual address belongs to the sub-virtual address region; The off-heap memory processing module is further configured to perform corresponding access operations on the second physical page based on the first access request.

11. The apparatus according to claim 10, characterized in that, The off-heap memory processing module is also used for: Based on the first access request and multiple previous access requests, semantic analysis is performed on the access behavior of the application to determine the access behavior type corresponding to the access behavior of the application. If the access behavior type is random access, perform a prefetch operation on multiple consecutive virtual memory pages before and / or after the first virtual address; If the access behavior type is a non-random access type, a prefetch operation is performed on multiple consecutive virtual memory pages following the first virtual address.

12. The apparatus according to claim 11, characterized in that, The off-heap memory processing module is specifically used for: Detect whether each of the virtual memory pages is mapped to physical memory; If any virtual memory page is not mapped to physical memory, establish a mapping relationship between the virtual memory page and the third physical memory page.

13. The apparatus according to claim 8, characterized in that, The resource release condition is used to indicate that the allocated resources in the off-heap memory are greater than a first value; wherein, the resources occupied by the first virtual address region are included in the allocated resources in the off-heap memory.

14. The apparatus according to claim 1, characterized in that, The memory allocation and access module is also used to allocate a second virtual address region for the application in the heap memory in response to the application's second memory allocation request; The on-heap memory processing module is used to perform a prefetch operation on at least one virtual memory page contained in the second virtual address region to prefetch physical pages from the disk into physical memory; The on-heap memory processing module is further configured to establish a mapping relationship between the second virtual address region and at least one fourth physical memory page, wherein the at least one fourth physical memory page includes a physical memory page that has been prefetched into the physical memory through the prefetch operation.

15. A computer storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-7.

16. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-7.

Images