CN115033378B - Management method for volatile memory - Google Patents
Management method for volatile memory Download PDFInfo
- Publication number
- CN115033378B CN115033378B CN202210633005.2A CN202210633005A CN115033378B CN 115033378 B CN115033378 B CN 115033378B CN 202210633005 A CN202210633005 A CN 202210633005A CN 115033378 B CN115033378 B CN 115033378B
- Authority
- CN
- China
- Prior art keywords
- space
- memory
- management
- size
- allocation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5022—Mechanisms to release resources
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Memory System (AREA)
Abstract
The application provides a management method for a volatile memory, which is based on a system and a management object and comprises volatile storage and persistent storage, wherein the volatile storage is a linear space with continuous addresses; basic information of the management object is stored in a persistent storage, and actual data is stored in a volatile storage; the method comprises the following steps: initializing a system, clearing a volatile storage space, and making an allocation strategy and a garbage collection strategy; when the memory applied by the management object is larger than a certain threshold value, applying for the large object, and allocating a memory in the allocable space for the large object application according to an allocation strategy; if not, applying for the small object, allocating a memory in the allocable space for the small object according to an allocation strategy, and after the small object is used, determining whether to clear the memory according to the requirement; and if the allocation space is insufficient to cause failure, executing a garbage collection strategy and then allocating the memory. The method can improve the memory allocation efficiency while reducing the memory fragments.
Description
Technical Field
The present application relates to the field of computer storage technologies, and in particular, to a management method for a volatile memory.
Background
In a computer system, storage resources may be divided into two categories by persistence: volatile storage and persistent storage. Volatile memory, such as DDR, which is currently widely used in mainstream devices, or static RAM, must be powered on at all times during use. If power is lost, the stored content is lost. Persistent storage, such as FLASH memory (FLASH), erasable programmable read-only memory (EEPROM), read-only memory (ROM), magnetic storage (hard disk), can still keep the stored information from being lost after a power failure.
Storage management involves allocation and release. In early programming languages, both the allocation and release of storage were managed by programmers. For example, in the libc function library provided by the C programming language, the memory can be allocated using malloc () function, and free () function is used. However, garbage collection is introduced in many modern object-oriented systems, and storage collection is automatically handled by the system without intervention of a programmer.
The biggest problem in storage management is the problem of memory fragmentation. The memory fragmentation problem refers to that after a computer system operates for a period of time, many spare memory fragments are generated in a memory after a plurality of allocations and releases. Then it is possible that when a new memory allocation request arrives, the new memory allocation request fails because of the discontinuity, although the total free space is larger than the request.
First-time adaptation (First-Fit) is one of memory allocation algorithms, the algorithm is organized in an ascending order of the First address of an idle chain, when an allocation demand is provided, an organized blank chain is traversed, and blank allocation block allocation with a First space larger than or equal to the allocation demand is found. And if no blank block meeting the requirement is found in one traversal, the allocation fails. The algorithm tends to preferentially utilize the idle blocks of the low address part and reserve the idle blocks of the high address part, so that the high address part is possible to reserve memory blocks with large capacity, and conditions are created for large-demand operation. But the algorithm is found from the low address each time, so that the low address leaves many unusable external fragments, and the efficiency of subsequent searching is reduced.
Disclosure of Invention
There are many policies for storage management. For different application scenarios, there may be different approaches to make storage management most efficient. The application provides a new management method for volatile storage, which can provide a new method for compressing memory fragments on the basis of First-time adaptation (First-First), and can improve the storage management efficiency in certain application scenarios, such as frequent distribution of low-demand jobs and small quantity of high-demand jobs.
In order to achieve the above object, the present application provides a management method for volatile memory, based on a system and a management object, where the system includes both volatile storage and persistent storage, and the volatile storage is a linear space with continuous addresses; basic information of the management object is stored in a persistent storage, and actual data is stored in a volatile storage; the system can traverse the management object; characterized in that the method comprises:
initializing a volatile storage space, and clearing the volatile storage space; formulating a distribution strategy and a garbage recovery strategy;
judging the size of a management object request storage block, and applying for a large object when the size of the request storage block exceeds a threshold value; otherwise, applying for the small object;
when the size of the distributable space meets the size of the request storage block, allocating a memory to the tail side or the head side of the distributable space for the large object application according to the allocation strategy, and allocating a memory to the other side of the distributable space for the small object application; the allocable space is always located in the middle of the whole storage space;
when the size of the allocable space does not meet the size of the request storage block, the system traverses all the management objects according to a mark-clearing algorithm and marks active management objects, and the data domain occupied by the inactive management objects is regarded as an idle space to carry out garbage collection according to the garbage collection strategy;
when the allocation strategy allocates the memory at the tail side, the garbage collection firstly moves towards the tail gradually and links the active management object data field to the region from the tail of the storage space to the tail of the allocable space, and then moves towards the head gradually and links the active management object data field to the region from the head of the storage space to the head of the allocable space, so as to combine and form a continuous free space; when the allocation strategy allocates the memory at the head side, the sequence is opposite;
when the garbage collection strategy is partial collection, when the continuous free space meets the size of a request storage block, allocating memory to the continuous free space and stopping garbage collection; when the garbage recycling strategy is all recycling, memory is allocated according to the allocation strategy;
and recording the allocated data field address pointer in the basic information of the management object after the memory allocation is finished.
In practical applications, various techniques for memory allocation are well established. There is room for optimization of memory allocation management only for specific scenarios. The method is used for optimizing a simple allocation (first-first) algorithm, the small objects are allocated at one end of the allocable space, the large objects are allocated at the other end of the allocable space, and memory fragmentation can be reduced. In addition, in the process of recycling the memory garbage, when the memory allocation requirement is met, the system can carry out partial recycling without carrying out complete recycling, so that the memory allocation efficiency is improved.
Drawings
In order to more simply explain the technical solution of the embodiment of the present invention, the drawings needed to be used in the description of the embodiment will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a schematic flow diagram of the process of the present application;
FIG. 2 is a schematic flow diagram of the waste recovery process of the present application;
FIG. 3 is a schematic flow chart of the method for recycling the garbage on the head table;
fig. 4 is a schematic flow chart of garbage recycling at the tail table of the method.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present invention clearer and more complete, the technical solutions in the embodiments of the present invention will be described below with reference to the drawings in the embodiments of the present invention, it is obvious that the described embodiments are a part of the embodiments of the present invention, but not all embodiments, and all other embodiments obtained by those skilled in the art without any inventive work belong to the scope of the present invention
In fig. 1, a management method for a volatile memory according to the present invention is based on a system and a management object, where the system includes two types of volatile and persistent storage, and the volatile storage is a linear space with continuous addresses; basic information of the management object is stored in a persistent storage, and actual data is stored in a volatile storage; the system can traverse the management object; the method comprises the following steps:
initializing a volatile storage space, and resetting the volatile storage space; formulating a distribution strategy and a garbage recovery strategy;
judging the size of a management object request storage block, and applying for a large object when the size of the request storage block exceeds a threshold value; otherwise, applying for the small object;
when the size of the allocable space meets the size of the request storage block, applying for allocating the memory to the large object at the tail side or the head side of the allocable space according to an allocation strategy, and applying for allocating the memory to the small object at the other side of the allocable space; the allocable space is always located in the middle of the whole storage space;
when the size of the allocable space does not meet the size of the request storage block, the system traverses all the management objects according to a mark-clearing algorithm and marks active management objects, and a data domain occupied by the inactive management objects is regarded as a free space to carry out garbage collection according to a garbage collection strategy;
and (3) executing garbage recovery: when the memory is distributed on the tail side by the distribution strategy, the memory space is moved gradually to the tail from the tail to the tail area of the distributable space and is linked with the active management object data field, and then the memory space is moved gradually to the head from the head to the head area of the distributable space and is linked with the active management object data field, so that continuous free spaces are formed by combination; when the allocation strategy allocates the memory at the head side, the sequence is opposite;
when the garbage collection strategy is partial collection, when the continuous free space meets the size of the request storage block, allocating memory to the continuous free space and stopping garbage collection; when the garbage collection strategy is all collection, memory is distributed according to the distribution strategy;
and recording the allocated data field address pointer in the basic information of the management object after the memory allocation is finished.
The invention provides a management method for volatile memory, which further comprises the steps of executing system reset when a reset condition is met, and distributing and resetting the volatile memory space; the system is reset to enable the system to traverse all the management objects, and for each active management object, the space required by the object is redistributed by using a distribution strategy according to the type and the size of the active management object;
optionally, the reset condition includes: receiving a system reset instruction, enabling a system memory management module to distribute a memory for a preset number of times, powering on the system again, and switching the system to a new operation mode;
the system reset is premised on: over several runs, the system has created objects whose underlying information is retained on persistent storage, but the information retained in the data fields of the objects is lost and does not need to be recovered.
In one embodiment, the underlying information for the management object includes type, size, security rights, and data field address pointers; a data field address pointer, P, to volatile storage.
In one embodiment, after the requested storage block is used, whether the data domain of the requested storage block is cleared is determined according to special requirements; alternatively, the special requirement is a requirement for data security.
In one embodiment, the volatile memory space base address is represented as base, size; the allocable space has a starting address of head, an ending address of tail, and an allocable space size = tail-head.
In one embodiment, initializing the volatile memory space is represented as: let head = base, tail = base + size.
In one embodiment, the size of the threshold sma110bjSize may be set differently depending on system requirements and application scenarios.
In one embodiment, the allocation strategy allocates from the two ends of the allocable space, and the rest allocable space is always positioned in the middle of the whole storage space;
alternatively, the allocation policy may be specified at the time of the allocation request, randomly by the system, or by system configuration.
In one embodiment, the garbage collection policy includes full and partial reclamation, which requires knowledge of the requested space size len.
In fig. 2, the garbage recycling step includes:
the system accesses and marks all active objects from the root according to a mark-clear algorithm, generates a head table and a tail table, records data field address pointers and sizes of all managed objects, and sorts the data field address pointers from low to high according to addresses; and then traversing the whole memory area once again, and recycling all the objects without active marks.
Wherein, the head table: all data field pointers are smaller than the address pointers and the sizes of the objects of the head pointers; tail table: all data field pointers are not smaller than the address pointers and the sizes of the objects of the tail pointers;
judging whether the whole is recovered or partially recovered;
executing a garbage recycling process, if all the garbage is recycled, firstly processing the garbage recycling of the head table, then performing the garbage recycling of the tail table, and after the garbage recycling is finished, allocating the memory according to an allocation strategy; if it is a partial recycle, it is selected according to whether the object to be allocated is to be at the head or the tail: if the head table is started, processing the garbage collection of the head table, and if the distribution condition is not met, processing the garbage collection of the tail table; if the garbage collection of the tail table is processed from the tail, the garbage collection of the head table is processed if the distribution condition is not met.
In fig. 3, garbage collection of the header table is a process of traversing the header table from beginning to end, and includes the following steps:
setting the traversed processing object as a current object, checking whether a free space exists between the current object and a data field of a subsequent object, if not, setting the subsequent object as the current object, and continuing traversing;
checking whether the size of the free space meets the requirement during partial recovery; if yes, performing memory allocation from the free space and directly finishing garbage collection; this step is skipped at all recoveries;
moving the data field of the subsequent object, continuing to the tail part of the data field of the current object, and rewriting the data field pointer of the subsequent object to point to the new address; setting the subsequent object as the current object;
other objects are arranged between the data field of the current object and the head pointer, and the first step is continued; and if the data field of the current object and the head pointer have no other objects, adjusting the head pointer to be the tail of the data field of the current object, and if the data field is partially recycled and the allocable space represented by the head, tail meets the allocation requirement, performing memory allocation and adjusting the head pointer from the allocable space: head = head + len and directly ends garbage collection.
In fig. 4, garbage collection of the tail table is a process of traversing the tail table from tail to head, and includes the following steps:
setting the traversed processing object as a current object, checking whether a free space exists between the current object and a data field of the preorder object, if not, setting the preorder object as the current object, and continuing traversing;
checking whether the size of the free space meets the requirement during partial recovery; if yes, performing memory allocation from the free space and directly finishing garbage collection; this step is skipped at full recovery;
moving the data field of the preorder object, continuing to the front of the data field of the current object, and rewriting the data field pointer of the preorder object to point to a new address; setting the preorder object as a current object;
other objects are arranged between the data field of the current object and the tail pointer, and the first step is continued; and if the part is partially recycled and the allocable space represented by the head, tail is adjusted to meet the allocation requirement, memory allocation is carried out from the allocable space, and the tail pointer is adjusted: tail = tail-len and ends garbage collection directly.
It should be noted that the methods provided herein are not inherently related to any particular computer, virtual machine, or other apparatus. Various general purpose devices may be used with the teachings herein. The required structure for constructing such a device will be apparent from the description above. In addition, the present invention is not directed to any particular programming language. It is to be appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and that the specific languages, calls for system function blocks, are provided for disclosure as preferred embodiments of the present invention.
In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.
Claims (9)
1. A management method for volatile memory is based on a system and a management object, wherein the system comprises volatile storage and persistent storage, and the volatile storage is a linear space with continuous addresses; basic information of the management object is stored in a persistent storage, and actual data is stored in a volatile storage; the system can traverse the management object; characterized in that the method comprises:
initializing a volatile storage space, and clearing the volatile storage space; formulating an allocation strategy and a garbage recovery strategy;
judging the size of a management object request storage block, and applying for a large object when the size of the request storage block exceeds a threshold value; otherwise, applying for the small object;
when the size of the distributable space meets the size of the request storage block, allocating a memory to the tail side or the head side of the distributable space for the large object application according to the allocation strategy, and allocating a memory to the other side of the distributable space for the small object application; allocable space is always located in the middle of the whole storage space;
when the size of the allocable space does not meet the size of the request storage block, the system traverses all the management objects according to a mark-clearing algorithm and marks active management objects, and the data domain occupied by the inactive management objects is regarded as an idle space to carry out garbage collection according to the garbage collection strategy;
when the allocation strategy allocates the memory at the tail side, the garbage collection firstly moves the region from the tail of the storage space to the tail of the allocable space gradually to the tail and links the active management object data field, and then moves the region from the head of the storage space to the head of the allocable space gradually to the head and links the active management object data field so as to combine to form a continuous free space; when the allocation strategy allocates the memory at the head side, the sequence is opposite;
when the garbage collection strategy is partial collection, when the continuous free space meets the size of a request storage block, allocating memory to the continuous free space and stopping garbage collection; when the garbage collection strategy is all collected, memory is distributed according to the distribution strategy;
and recording the allocated data field address pointer in the basic information of the management object after the memory allocation is finished.
2. The management method according to claim 1, the method further comprising, when the reset condition is satisfied, performing a system reset to perform an allocation reset of the volatile memory space; the system is reset to enable the system to traverse all the management objects, and for each active management object, the allocation strategy is used for reallocating the space required by the object according to the type and the size of the active management object;
optionally, the reset condition includes: receiving a system reset instruction, enabling a system memory management module to distribute a memory for a preset number of times, powering on the system again, and switching the system to a new operation mode;
the system reset is premised on: over several runs, the system has created several objects whose underlying information is retained on persistent storage, but the information retained in the data fields of the objects is lost and does not need to be recovered.
3. The method of claim 1, wherein the basic information of the management object comprises a type, a size, a security authority, and a data field address pointer; the data field address pointer, P, points to volatile storage.
4. The management method according to claim 1, wherein after the request storage block is used, whether the request storage block data domain is cleared is determined according to special requirements; alternatively, the special requirement is a requirement for data privacy security.
5. The management method according to claim 1, wherein the volatile memory space base address is represented as base, and the size is size; the allocable space starting address is denoted head, the ending address is tail, and the allocable space size = tail-head.
6. The method of managing according to claim 5, wherein said initializing volatile memory space is represented by: let head = base, tail = base + size.
7. The method according to claim 1, wherein the size of the threshold sma110bjSize is set differently according to system requirements and application scenarios.
8. The management method according to claim 1, wherein the allocation policy allocates from both ends of the allocable space, and the remaining allocable space is always located in the middle of the entire storage space;
the allocation policy may be specified at the time of the allocation request, randomly by the system, or by system configuration.
9. The management method according to claim 1, characterized in that said garbage collection policy comprises a total collection and a partial collection, said partial collection requiring knowledge of the requested space size len.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210633005.2A CN115033378B (en) | 2022-06-06 | 2022-06-06 | Management method for volatile memory |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210633005.2A CN115033378B (en) | 2022-06-06 | 2022-06-06 | Management method for volatile memory |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115033378A CN115033378A (en) | 2022-09-09 |
CN115033378B true CN115033378B (en) | 2023-01-06 |
Family
ID=83123106
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210633005.2A Active CN115033378B (en) | 2022-06-06 | 2022-06-06 | Management method for volatile memory |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115033378B (en) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101976224A (en) * | 2010-10-13 | 2011-02-16 | 清华大学 | Memory management method of embedded system |
CN102073464A (en) * | 2011-01-14 | 2011-05-25 | 南开大学 | Method for creating allocation-on-demand incremental volume |
CN103838633A (en) * | 2012-11-20 | 2014-06-04 | 国际商业机器公司 | Out-of-memory avoidance in dynamic virtual machine memory adjustment |
CN112084032A (en) * | 2020-09-15 | 2020-12-15 | 电子科技大学 | Write-optimized persistent memory heap management method |
CN114443268A (en) * | 2020-10-31 | 2022-05-06 | 华为终端有限公司 | Memory management method and device, electronic equipment and computer readable storage medium |
-
2022
- 2022-06-06 CN CN202210633005.2A patent/CN115033378B/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101976224A (en) * | 2010-10-13 | 2011-02-16 | 清华大学 | Memory management method of embedded system |
CN102073464A (en) * | 2011-01-14 | 2011-05-25 | 南开大学 | Method for creating allocation-on-demand incremental volume |
CN103838633A (en) * | 2012-11-20 | 2014-06-04 | 国际商业机器公司 | Out-of-memory avoidance in dynamic virtual machine memory adjustment |
CN112084032A (en) * | 2020-09-15 | 2020-12-15 | 电子科技大学 | Write-optimized persistent memory heap management method |
CN114443268A (en) * | 2020-10-31 | 2022-05-06 | 华为终端有限公司 | Memory management method and device, electronic equipment and computer readable storage medium |
Non-Patent Citations (1)
Title |
---|
动态内存分配器研究综述;刘翔等;《计算机学报》;20181031;第41卷(第10期);第2359-2374页 * |
Also Published As
Publication number | Publication date |
---|---|
CN115033378A (en) | 2022-09-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108038002B (en) | Embedded software memory management method | |
US7165255B2 (en) | Method and apparatus for managing surplus memory in multitasking system | |
US7480782B2 (en) | Reference-updating using per-chunk referenced-address ranges in a compacting garbage collector | |
US7412466B1 (en) | Offset-based forward address calculation in a sliding-compaction garbage collector | |
US9037830B2 (en) | Organization of a small object area and a large object area in a Java heap | |
US8612493B2 (en) | Allocation cache premarking for snap-shot-at-the-beginning concurrent mark-and-sweep collector | |
US20110246742A1 (en) | Memory pooling in segmented memory architecture | |
CN1321377C (en) | Method for controlling smart card storage environment | |
US20050149686A1 (en) | Method and apparatus for dynamic incremental defragmentation of memory | |
US8805896B2 (en) | System and method for use with garbage collected languages for enabling the allocated heap memory to be updated at runtime | |
US6219772B1 (en) | Method for efficient memory allocation of small data blocks | |
CN107844372B (en) | Memory allocation method and system | |
US7822938B2 (en) | System and method for performing garbage collection based on unmanaged memory allocations | |
CN101169739A (en) | Method of and apparatus for managing memory | |
CN111984425A (en) | Memory management method, device and equipment for operating system | |
CN114327917A (en) | Memory management method, computing device and readable storage medium | |
US20060236065A1 (en) | Method and system for variable dynamic memory management | |
US6839822B2 (en) | Memory-block coalescing based on run-time demand monitoring | |
CN106294189B (en) | Memory defragmentation method and device | |
CN115033378B (en) | Management method for volatile memory | |
US6842838B2 (en) | Preemptive memory-block splitting | |
CN106469121B (en) | Memory allocation method and device | |
US8595462B2 (en) | Dynamic measurement and adaptation of a copying garbage collector | |
CN102541743B (en) | For the method, apparatus and system of storage administration | |
US9170929B2 (en) | Memory controller |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |