Coroutine-based memory management method and apparatus

Abstract

Provided are a coroutine-based memory management method and apparatus, relating to the technical field of memory management. A specific embodiment of the method comprises: starting at least one coroutine scheduling thread (201); configuring at least one memory allocation area for each coroutine scheduling thread (202); and starting a coroutine, and when submitting the coroutine to one coroutine scheduling thread among the at least one coroutine scheduling thread, on the basis of a preset load balancing algorithm, binding the coroutine with a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted (203).

Description

Coroutine-based memory management method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to the Chinese patent application filed on July 28, 2023, with application number 202310942821.6 and invention name “Memory management method and device based on coroutine”, the full text of which is incorporated by reference into this application. Technical Field

[0003] The present disclosure relates to the field of computer technology, specifically to the field of memory management technology, and more particularly to a memory management method and device based on coroutines. Background Art

[0004] To support concurrency, most memory allocators employ a so-called "arena" mechanism to distribute the load of concurrent memory requests from multiple threads. By "binding" different threads to the same arena and enabling multiple arenas within a single process, memory allocators reduce lock conflicts and address concurrent performance issues. Furthermore, most memory allocators provide thread-local caching mechanisms.

[0005] However, when the number of application threads reaches a certain scale, or when memory allocation / deallocation (i.e., malloc / free library function calls) in concurrent tasks becomes too frequent, the performance loss caused by lock conflicts remains significant. Furthermore, to optimize performance, most memory allocators have introduced thread-local caches. When a system has a large number of threads, each with its own local cache, the overall memory usage increases significantly.

[0006] Summary of the Invention

[0007] Embodiments of the present disclosure provide a memory management method, apparatus, device, and storage medium based on a coroutine.

[0008] In one or more embodiments, the present disclosure provides a coroutine-based memory management method, the method comprising: starting at least one coroutine scheduling thread; configuring at least one memory allocation area for each coroutine scheduling thread; starting a coroutine, and when submitting the coroutine to one of the at least one coroutine scheduling threads, binding the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm, wherein the coroutines bound to the same memory allocation area constitute a coroutine group.

[0009] In one or more embodiments, the present disclosure provides a coroutine-based memory management device, which includes: a startup module, configured to start at least one coroutine scheduling thread; a configuration module, configured to configure at least one memory allocation area for each coroutine scheduling thread; a binding module, configured to start a coroutine and, when submitting the coroutine to one of the at least one coroutine scheduling threads, bind the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm, wherein the coroutines bound to the same memory allocation area constitute a coroutine group.

[0010] In one or more embodiments, the present disclosure provides an electronic device comprising one or more processors; a storage device on which one or more computer instructions are stored, and when the one or more computer instructions are executed by the one or more processors, the one or more processors implement a coroutine-based memory management method as in any embodiment of the first aspect.

[0011] In one or more embodiments, the present disclosure provides a non-transitory computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the coroutine-based memory management method in the above method embodiment.

[0012] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG1 is a diagram of an exemplary system architecture in which the present disclosure may be applied;

[0014] FIG2 is a flowchart of an embodiment of a memory management method based on a coroutine according to the present disclosure;

[0015] FIG3 is an architectural diagram of an embodiment of a memory management method based on coroutines according to the present disclosure;

[0016] FIG4A is a flowchart of an embodiment of a memory management method based on coroutines according to the present disclosure;

[0017] FIG4B is a flow chart of an application scenario of the coroutine-based memory management method according to the present disclosure;

[0018] FIG4C is a flowchart of another application scenario of the coroutine-based memory management method according to the present disclosure;

[0019] FIG5 is a flow chart of an embodiment of a memory management apparatus based on coroutines according to the present disclosure;

[0020] FIG6 is a schematic diagram of the structure of a computer system suitable for implementing a server according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0021] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0022] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure can be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0023] FIG1 shows an exemplary system architecture 100 to which an embodiment of the coroutine-based memory management method of the present disclosure may be applied.

[0024] As shown in Figure 1, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 is a medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0025] The terminal devices 101, 102, 103 interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications, such as storage applications and communication applications, may be installed on the terminal devices 101, 102, 103.

[0026] The terminal devices 101, 102, and 103 may be hardware. When the terminal devices 101, 102, and 103 are hardware, they may be various electronic devices with display screens, including but not limited to mobile phones and laptop computers.

[0027] The server 105 may include a memory allocator that provides the following functions, for example, starting at least one coroutine scheduling thread; configuring at least one memory allocation area for each coroutine scheduling thread; starting a coroutine, and when submitting the coroutine to one of the at least one coroutine scheduling threads, binding the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm.

[0028] It should be noted that when the server 105 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or it can be implemented as a single server.

[0029] It should be noted that the coroutine-based memory management method provided by the embodiments of the present disclosure can be executed by the memory allocator in the server 105, or by the memory allocator in the terminal devices 101, 102, and 103. Accordingly, the various parts (such as various units, sub-units, modules, and sub-modules) included in the coroutine-based memory management device can be all set in the server 105, or all set in the terminal devices 101, 102, and 103.

[0030] It should be understood that the number of terminal devices, networks, and servers in Figure 1 is merely illustrative and any number of terminal devices, networks, and servers may be provided as required.

[0031] Figure 2 shows a process 200 of an embodiment of a memory management method based on a coroutine that can be applied to the present disclosure. In this embodiment, the memory management method based on a coroutine includes the following steps:

[0032] Step 201: Start at least one coroutine scheduling thread.

[0033] In this embodiment, current operating systems all provide system calls for memory allocation / release to meet the memory usage requirements of applications. Taking Linux as an example, it provides the sbrk / brk system calls for allocating memory in the heap area and the mmap system call for allocating memory in the mapped area (generally, sbrk / brk are used to allocate small memory blocks, while mmap is often used to allocate large memory blocks; in addition to Linux, other operating systems also have similar system calls).

[0034] However, if system calls are used for every memory allocation and release, application performance will be significantly impacted. Therefore, various operating system distributions provide user-mode memory allocators to improve performance. For example, GNU Linux's default allocator ptmalloc, FreeBSD's jemalloc, and Google's open source memory allocator tcmalloc are examples.

[0035] To support concurrency, most memory allocators employ a so-called "arena" mechanism to distribute the load of concurrent memory requests from multiple threads. An "arena" is a memory allocation area. Although existing memory allocators employ multiple memory allocation areas (arenas) to reduce concurrency conflicts, the performance loss caused by these lock conflicts can still be significant when the number of application threads reaches a certain scale or when memory allocation / deallocation (i.e., malloc / free library function calls) within concurrent tasks becomes too frequent.

[0036] To overcome the above problems, the execution entity (such as the server 105 or the memory allocator in the terminal devices 101, 102, 103 shown in Figure 1) first starts at least one, for example, 5, 10, etc., coroutine scheduling threads

[0037] Among them, the coroutine scheduling thread is used to schedule at least one coroutine. The operation of the coroutine is dependent on the coroutine scheduling thread to which it belongs. After the coroutine gives up through yield, the coroutine scheduling thread can schedule other coroutines to run, that is, the time slices of the coroutine scheduling thread are reused between coroutines. Therefore, although the coroutines on the same coroutine scheduling thread are nominally executed "in parallel", its time-sharing multiplexing mechanism ensures that any two of these coroutines will not actually run at the same time (that is, the running time slices will not overlap). Based on this premise, as long as the coroutine's access to the cache is guaranteed to be "atomic" (that is, the yield operation will not be performed when the cache operation is not completed), shared cache between coroutines can be achieved.

[0038] Step 202: configure at least one memory allocation area for each coroutine scheduling thread.

[0039] In this embodiment, the execution entity may configure one or more memory allocation areas for each coroutine scheduling thread.

[0040] Each memory allocation area in the at least one memory allocation area corresponds to a thread local cache area, and the thread local cache areas corresponding to the memory allocation areas are different.

[0041] Here, the thread-local cache, or tcache, belongs to the memory allocation area, or arena, and they have a one-to-one correspondence. In other words, the cache in tcache is part of the memory in the arena. Generally speaking, the memory allocated by programs is relatively small, so tcache can be considered a small-scale cache. In most cases, memory allocation requests can be satisfied by tcache. Only when requesting large-scale memory space is it necessary to apply to the arena; in addition, when there is no memory space of the appropriate size in tcache, a large block is first requested from the arena, and then it is cut into smaller blocks for use. Therefore, tcache is an acceleration mechanism for small-scale memory allocation and reuse within an arena.

[0042] Step 203 , starting the coroutine, and when submitting the coroutine to a coroutine scheduling thread in at least one coroutine scheduling thread, binding the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm.

[0043] In this embodiment, the execution entity can start one or more coroutines. For each coroutine, when submitting the coroutine to the target coroutine scheduling thread in at least one coroutine scheduling thread, the coroutine is bound to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm.

[0044] When the number of coroutines bound to the memory allocation area is greater than 1, a group of coroutines is naturally generated, namely the "coroutine group".

[0045] After the above binding relationship is determined, memory allocation and memory merging and return can be performed based on the coroutine's memory application and memory release requests.

[0046] In addition, it should be pointed out that in order to avoid the target coroutine being executed from other coroutine scheduling threads other than the coroutine scheduling thread to which it belongs, and the target coroutine accessing the memory allocation area bound to the other coroutine scheduling thread, resulting in concurrent access, the execution subject can configure to prohibit cross-thread scheduling of the coroutine, or implement optimistic locking, for example, version number mechanism, CAS algorithm, etc., to solve the problem of cross-thread access to memory allocation area.

[0047] Furthermore, in some optional approaches, steps 201, 202, and 203 of the present disclosure can be executed via callback interfaces provided by hooks for library functions in a specified coroutine library, such as malloc, free, calloc, realloc, memalign, and valloc. This approach enables "transparent" replacement of the memory allocator, meaning that the memory allocator is replaced without the application's awareness, improving memory management performance and further enhancing overall concurrent throughput based on the high-performance concurrent scheduling capabilities provided by the coroutine library.

[0048] For coroutine libraries without callback interfaces, such as libco and libgo, an override of library functions related to coroutine-based memory management operations can be added, and a coroutine-based memory manager can be implemented based on steps 201, 202, and 203.

[0049] In some optional embodiments, the method further includes: in response to obtaining a first request for memory from a first coroutine, searching for a target memory space corresponding to the first request in a thread-local cache area corresponding to a memory allocation area bound to a coroutine group to which the first coroutine is located; in response to a successful search, allocating the target memory space; in response to a failed search, searching for and allocating the target memory space corresponding to the first request in a memory allocation area bound to the coroutine group to which the first coroutine is located.

[0050] In this implementation, since when the application calls the library function free to release memory space, the released memory is not directly released back to the memory allocation area, but is placed in the thread local cache area corresponding to the memory allocation area. In response to obtaining the first request for memory from the first coroutine, the execution subject can first search for the target memory space corresponding to the first request in the thread local cache area corresponding to the memory allocation area bound to the coroutine group where the first coroutine is located, that is, the memory space suitable for the size of this request. If the search is successful, the target memory space is allocated in the thread local cache area corresponding to the memory allocation area bound to the coroutine group where the first coroutine is located; if the search fails, the target memory space corresponding to the first request is further searched in the memory allocation area bound to the coroutine group where the first coroutine is located and allocated.

[0051] This implementation method realizes memory allocation for the request for memory application of the coroutine by, in response to obtaining the first request for memory application by the first coroutine, searching for the target memory space corresponding to the first request in the thread local cache area corresponding to the memory allocation area bound to the coroutine group where the first coroutine is located; in response to a successful search, allocating the target memory space; in response to a failed search, searching for the target memory space corresponding to the first request in the memory allocation area bound to the coroutine group where the first coroutine is located and allocating it.

[0052] In some optional embodiments, the method further includes: in response to obtaining a second request from the second coroutine to release memory, merging the free memory space in the thread local cache area corresponding to the memory allocation area bound to the coroutine group where the second coroutine is located to obtain a first memory space; in response to determining that the first memory space meets the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, returning the first memory space to the memory allocation area and merging the free memory space of the memory allocation area to obtain a second memory space; in response to determining that the second memory space meets the second preset condition for returning it to the operating system, returning the second memory space to the operating system.

[0053] In this implementation, in response to obtaining the second request from the second coroutine to release memory, the execution body may first merge the free memory space in the thread local cache area corresponding to the memory allocation area bound to the coroutine group where the second coroutine is located to obtain a first memory space, and determine whether the first memory space meets the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located; in response to determining that the first memory space meets the first preset condition for returning the memory allocation area, the first memory space is returned to the memory allocation area, and the free memory space of the memory allocation area is merged to obtain a second memory space; in response to determining that the second memory space meets the second preset condition for returning to the operating system, the second memory space is returned to the operating system, and in response to not meeting the condition, the return operation is terminated.

[0054] Here, the first preset condition and the second preset condition may be the same or different. The first preset condition and the second preset condition may be set based on experience and actual needs. For example, the size of continuous memory with continuous addresses and aligned starting addresses is greater than or equal to a preset size threshold, the residence time in the storage area (cache area or memory allocation area) is greater than or equal to a preset time threshold, etc. This disclosure does not limit this.

[0055] This implementation method obtains a first memory space by, in response to obtaining a second request from the second coroutine to release memory, merging the free memory space in the thread-local cache area corresponding to the memory allocation area bound to the coroutine group where the second coroutine is located; in response to determining that the first memory space meets the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, returning the first memory space to the memory allocation area and merging the free memory space of the memory allocation area to obtain a second memory space; in response to determining that the second memory space meets the second preset condition for returning it to the operating system, returning the second memory space to the operating system, thereby realizing the return of memory space for the coroutine's memory release request.

[0056] In some optional embodiments, the method further includes: in response to determining that the first memory space does not meet the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located or the second memory space does not meet the second preset condition for returning it to the operating system, ending the operation.

[0057] In this implementation, the execution entity can determine whether the first memory space meets the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, and terminate the operation in response to the first memory space not meeting the first preset condition or the second memory space not meeting the second preset condition for returning to the operating system.

[0058] This implementation method ends the operation in response to determining that the first memory space does not meet the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, or the second memory space does not meet the second preset condition for returning it to the operating system, thereby achieving the return of memory space for the coroutine to release memory request.

[0059] In some optional methods, the configuration prohibits cross-thread scheduling of coroutines.

[0060] In this implementation, in order to avoid the situation where the target coroutine is executed from a coroutine scheduling thread other than the coroutine scheduling thread to which it belongs, and the target coroutine accesses the memory allocation area bound to the other coroutine scheduling thread, resulting in concurrent access, the execution entity can be configured to prohibit cross-thread scheduling of coroutines.

[0061] This implementation effectively avoids concurrent access and ensures memory allocation / recycling performance by disabling cross-thread scheduling of coroutines.

[0062] Continuing to refer to FIG3 , FIG3 is an architecture diagram of an application scenario of the coroutine-based memory management method according to this embodiment.

[0063] In the application scenario of Figure 3, the execution entity can start at least one coroutine scheduling thread; configure at least one memory allocation area for each coroutine scheduling thread, such as arena0, arena1, arena2...arenaN, wherein each memory allocation area in the at least one memory allocation area corresponds to a thread local cache area; start the coroutine, and when submitting the coroutine to the coroutine scheduling thread in at least one coroutine scheduling thread, bind the coroutine to a memory allocation area corresponding to the coroutine scheduling thread submitted by the coroutine according to a preset load balancing algorithm, wherein the coroutines bound to the same memory allocation area constitute a coroutine group, for example, coroutine group 0 is bound to arena0, tcache0 corresponds to (belongs to) arena0; coroutine group 1 is bound to arena1, tcache1 corresponds to (belongs to) arena1...Coroutine group N is bound to arenaN, tcacheN corresponds to (belongs to) arenaN.

[0064] The present disclosure starts at least one coroutine scheduling thread; configures at least one memory allocation area for each coroutine scheduling thread; starts a coroutine, and when submitting the coroutine to one of the at least one coroutine scheduling threads, binds the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm. This fully utilizes the time-sharing and multiplexing characteristics of coroutine scheduling threads in coroutine multi-tasking scheduling. When coroutines belonging to the same coroutine scheduling thread share a memory allocation area (arena), no locking is required during memory application / release, thereby minimizing the possibility of lock conflicts caused by memory management. At the same time, multiple coroutines share a thread-local cache area, namely, tcache. Memory released to the tcache by the previous coroutine can be reused when allocating memory when the next coroutine is scheduled. Compared with the existing solution in which each thread has its own independent thread-local cache area, this tcache cannot be shared with other threads, effectively reducing the overall memory usage of the system and improving the concurrency performance of the system.

[0065] FIG4A shows a process 400 of another embodiment of a memory management method based on a coroutine that can be applied to the present disclosure. In this embodiment, the memory management method based on a coroutine includes the following steps:

[0066] Step 401: Start at least one coroutine scheduling thread.

[0067] In this embodiment, the implementation details and technical effects of step 401 can be found in the description of step 201 and will not be repeated here.

[0068] Step 402: configure at least one memory allocation area for each coroutine scheduling thread.

[0069] In this embodiment, the implementation details and technical effects of step 402 can be found in the description of step 202 and will not be repeated here.

[0070] Step 403: Start the coroutine, and when submitting the coroutine to a coroutine scheduling thread in at least one coroutine scheduling thread, bind the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm.

[0071] In this embodiment, the implementation details and technical effects of step 403 can be found in the description of step 203 and will not be repeated here.

[0072] Step 404 , under the condition that cross-thread scheduling of coroutines is allowed, before performing a memory allocation operation based on a coroutine memory request, or before performing a memory merge and return operation based on a coroutine memory release request, mark the atomic variable.

[0073] In this embodiment, to prevent the target coroutine from being executed from a coroutine scheduling thread other than its own coroutine scheduling thread, and the target coroutine accessing the memory allocation area bound to the other coroutine scheduling thread, thereby generating concurrent access, under the condition that the cross-thread scheduling of coroutines is configured, the execution subject can configure an atomic variable based on the CAS (Compare And Swap) operation. Before performing a memory allocation operation based on a coroutine application request, or before performing a memory merge and return operation based on a coroutine release request, the atomic variable is marked.

[0074] CAS is a hardware synchronization primitive provided by concurrently supported processors (CPUs). A CAS operation consists of three operands: a memory location (V), an expected old value (A), and a new value (B), written as CAS(V,A,B). If the value at the memory location matches the expected old value, the processor automatically updates the location to the new value. Otherwise, the processor does nothing.

[0075] Step 405 : In response to determining that the memory allocation operation is completed or the memory merging and returning operation is completed, the atomic variable is cleared.

[0076] In this embodiment, the execution subject clears the atomic variable in response to determining that the memory allocation operation is completed or the memory merge and return operation is completed.

[0077] Specifically, as shown in Figure 4B, the execution subject can configure atomic variables based on the CAS operation, and mark the atomic variables before executing the memory allocation operation, that is, set the atomic variables. The memory allocation operation may include: searching for the memory space corresponding to the first request in the thread local cache area, that is, the memory space suitable for the size of this request. If the search is successful, the target memory space corresponding to the first request is directly allocated; if the search fails, the target memory space corresponding to the first request is further searched in the memory allocation area. If the search is successful, the target memory space corresponding to the first request is directly allocated.

[0078] In response to the memory allocation operation completing, the atomic variable is cleared to zero.

[0079] As shown in FIG4C , the execution subject may configure atomic variables based on CAS operations and mark atomic variables before performing memory merging and returning operations. The memory merging and returning operations may include: merging the free memory space in the thread local cache to obtain a first memory space, and determining whether the first memory space meets the first preset condition for returning the memory allocation area; terminating the merging and returning operation in response to the first memory space not meeting the first preset condition. In response to the first memory space meeting the first preset condition for returning the memory allocation area, returning the first memory space to the memory allocation area and merging the free memory space of the memory allocation area to obtain a second memory space; in response to the second memory space meeting the second preset condition for returning to the operating system, returning the second memory space to the operating system; in response to not meeting the first preset condition, terminating the operation.

[0080] In response to determining that the memory merge and return operation is complete, the atomic variable is cleared.

[0081] Furthermore, if marking an atomic variable fails and the number of failures is greater than or equal to a preset threshold, the busy loop is no longer executed. Instead, the coroutine is suspended to delay the operation, swapped out once, swapped in again, and then the CAS operation is retried. This is a "yield & resume" approach, where the variable is swapped out first and then the subsequent operation is continued when it is swapped in again.

[0082] As can be seen from Figure 4, compared with the embodiment corresponding to Figure 2, the process 400 of the coroutine-based memory management method in this embodiment reflects that under the condition that the configuration allows cross-thread scheduling of coroutines, before executing the memory allocation operation based on the coroutine memory request, or before executing the memory merging and returning operation based on the coroutine memory release request, the atomic variable is marked; in response to determining that the memory allocation operation is completed or the memory merging and returning operation is completed, the atomic variable is cleared (that is, load balancing is supported, such as when a large number of coroutines on certain coroutine scheduling threads end and cause uneven load, the coroutines on other coroutine scheduling threads with heavier loads can be scheduled to scheduling threads with relatively lighter loads) while avoiding concurrent access.

[0083] With further reference to FIG5 , as an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of a memory management device based on coroutines. The embodiment of the device corresponds to the embodiment of the method shown in FIG2 , and the device can be specifically applied to various electronic devices.

[0084] As shown in FIG5 , the coroutine-based memory management device 500 of this embodiment includes: a startup module 501 , a configuration module 502 and a binding module 503 .

[0085] The starting module 501 may be configured to start at least one coroutine scheduling thread.

[0086] The configuration module 502 may be configured to configure at least one memory allocation area for each coroutine scheduling thread.

[0087] The binding module 503 may be configured to start a coroutine and, when submitting the coroutine to one of the at least one coroutine scheduling threads, bind the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine was submitted, according to a preset load balancing algorithm. Coroutines bound to the same memory allocation area constitute a coroutine group.

[0088] In some optional embodiments of this embodiment, the device also includes a marking module, which is configured to mark the atomic variable before performing a memory allocation operation based on a coroutine memory request, or before performing a memory merge and return operation based on a coroutine memory release request, under the condition that the configuration allows cross-thread scheduling of coroutines; and clear the atomic variable to zero in response to determining that the memory allocation is completed or the memory merge and return are completed.

[0089] In some optional embodiments of this embodiment, the device also includes an allocation module, which is configured to, in response to obtaining a first request for memory from a first coroutine, search for a target memory space corresponding to the first request in a thread-local cache area corresponding to a memory allocation area bound to a coroutine group where the first coroutine is located; in response to a successful search, allocate the target memory space; in response to a failed search, search for and allocate the target memory space corresponding to the first request in a memory allocation area bound to a coroutine group where the first coroutine is located.

[0090] In some optional embodiments of this embodiment, the device also includes a release module, which is configured to, in response to obtaining a second request from the second coroutine to release memory, merge the free memory space in the thread local cache area corresponding to the memory allocation area bound to the coroutine group where the second coroutine is located, to obtain a first memory space; in response to determining that the first memory space meets the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, return the first memory space to the memory allocation area, and merge the free memory space of the memory allocation area to obtain a second memory space; in response to determining that the second memory space meets the second preset condition for returning it to the operating system, return the second memory space to the operating system.

[0091] In some optional embodiments of this embodiment, the device also includes a return module, which is configured to terminate the operation in response to determining that the first memory space does not meet the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, or the second memory space does not meet the second preset condition for returning it to the operating system.

[0092] In some optional aspects of this embodiment, the device further includes: a configuration module configured to prohibit cross-thread scheduling of coroutines.

[0093] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device and a readable storage medium.

[0094] As shown in FIG6 , it is a block diagram of an electronic device according to the memory management method based on coroutines according to an embodiment of the present disclosure.

[0095] 600 is a block diagram of an electronic device according to a memory management method based on coroutines according to an embodiment of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0096] As shown in Figure 6, the electronic device includes: one or more processors 601, a memory 602, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In other embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). In Figure 6, a processor 601 is taken as an example.

[0097] Memory 602 is a non-transitory computer-readable storage medium provided by the present disclosure. The memory stores instructions executable by at least one processor to cause the at least one processor to perform the coroutine-based memory management method provided by the present disclosure. The non-transitory computer-readable storage medium of the present disclosure stores computer instructions for causing a computer to perform the coroutine-based memory management method provided by the present disclosure.

[0098] The memory 602, as a non-transient computer-readable storage medium, can be used to store non-transient software programs, non-transient computer executable programs, and modules, such as the program instructions / modules corresponding to the coroutine-based memory management method in the embodiments of the present disclosure (for example, the startup module 501, the configuration module 502, and the binding module 503 shown in FIG5). The processor 601 executes the various functional applications and data processing of the server by running the non-transient software programs, instructions, and modules stored in the memory 602, thereby implementing the coroutine-based memory management method in the above method embodiment.

[0099] The memory 602 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store data created by the use of the electronic device based on coroutine memory management, etc. In addition, the memory 602 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 602 may optionally include a memory remotely located relative to the processor 601, and these remote memories may be connected to the electronic device based on coroutine memory management via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0100] The electronic device of the memory management method based on coroutine may further include: an input device 603 and an output device 604. The processor 601, the memory 602, the input device 603 and the output device 604 may be connected via a bus or other means, and FIG6 takes the bus connection as an example.

[0101] The input device 603 can receive input digital or character information, such as an input device such as a touch screen, a keypad, a mouse, a trackpad, a touch pad, a pointer, one or more mouse buttons, a trackball, a joystick, etc. The output device 604 can include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor). The display device can include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some embodiments, the display device can be a touch screen.

[0102] Various implementations of the systems and techniques described herein can be realized in digital electronic circuit systems, integrated circuit systems, dedicated ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0103] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and / or device (e.g., a magnetic disk, an optical disk, a memory, a programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0104] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0105] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0106] Computer systems may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The client and server relationship arises through computer programs running on the respective computers and having a client-server relationship to each other.

[0107] According to the technical solution of the embodiment of the present disclosure, the memory usage rate is reduced while the system concurrency performance is effectively improved.

[0108] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this application can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved. This is not a limitation herein.

[0109] The above specific embodiments do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure shall be included within the scope of protection of this disclosure.

Claims

1. A memory management method based on coroutine, the method comprising: Start at least one coroutine scheduling thread; Configure at least one memory allocation area for each coroutine scheduling thread, wherein each memory allocation area in the at least one memory allocation area corresponds to a thread local cache area; Start a coroutine, and when submitting the coroutine to a coroutine scheduling thread among the at least one coroutine scheduling threads, bind the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm, wherein the coroutines bound to the same memory allocation area constitute a coroutine group.

2. The method according to claim 1, wherein: The method further comprises: Under the condition that cross-thread scheduling of coroutines is allowed, atomic variables are marked before performing memory allocation operations based on coroutine memory requests, or before performing memory merging and returning operations based on coroutine memory release requests; In response to determining that the memory allocation operation is completed or the memory merge and return operation is completed, the atomic variable is cleared.

3. The method according to claim 1, wherein: The method further comprises: In response to obtaining a first request from a first coroutine for applying for memory, searching for a target memory space corresponding to the first request in a thread local cache area corresponding to a memory allocation area bound to a coroutine group to which the first coroutine is located; In response to the search being successful, allocating the target memory space; In response to a search failure, a target memory space corresponding to the first request is searched for and allocated in a memory allocation area bound to the coroutine group where the first coroutine is located.

4. The method according to claim 1, wherein: The method further comprises: In response to obtaining a second request from the second coroutine to release memory, merging free memory spaces in a thread local cache area corresponding to a memory allocation area bound to a coroutine group to which the second coroutine is located to obtain a first memory space; In response to determining that the first memory space meets a first preset condition for returning the memory allocation area bound to the coroutine group in which the second coroutine is located, returning the first memory space to the memory allocation area, and merging the free memory space of the memory allocation area to obtain a second memory space; In response to determining that the second memory space meets a second preset condition for returning the second memory space to the operating system, the second memory space is returned to the operating system.

5. The method according to claim 4, wherein: The method further comprises: In response to determining that the first memory space does not meet the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located or the second memory space does not meet the second preset condition for returning it to the operating system, the operation is terminated.

6. The method according to any one of claims 3 to 5, wherein: The method further comprises: Configuration prohibits cross-thread scheduling of coroutines.

7. A memory management device based on coroutine, the device comprising: A startup module, configured to start at least one coroutine scheduling thread; A configuration module is configured to configure at least one memory allocation area for each coroutine scheduling thread, wherein each memory allocation area in the at least one memory allocation area corresponds to a thread local cache area; The binding module is configured to start a coroutine and, when submitting the coroutine to a coroutine scheduling thread among the at least one coroutine scheduling threads, bind the coroutine to a memory allocation area corresponding to the coroutine scheduling thread to which the coroutine is submitted according to a preset load balancing algorithm, wherein the coroutines bound to the same memory allocation area constitute a coroutine group.

8. The device according to claim 7, wherein: The device also includes: The marking module is configured to mark the atomic variable before performing a memory allocation operation based on a memory request of the coroutine, or before performing a memory merge and return operation based on a memory release request of the coroutine, under the condition that the configuration allows cross-thread scheduling of coroutines; in response to determining that the memory allocation operation is completed or the memory merge and return operation is completed, the atomic variable is cleared.

9. The device according to claim 7, wherein: The device also includes: an allocation module configured to, in response to obtaining a first request for memory application from a first coroutine, search for a target memory space corresponding to the first request in a thread local cache area corresponding to a memory allocation area bound to a coroutine group to which the first coroutine is located; In response to a successful search, a target memory space is allocated; in response to a failed search, a target memory space corresponding to the first request is searched for and allocated in a memory allocation area bound to the coroutine group where the first coroutine is located.

10. The device according to claim 7, wherein: The device also includes: A release module is configured to, in response to obtaining a second request from the second coroutine to release memory, merge the free memory space in the thread local cache area corresponding to the memory allocation area bound to the coroutine group where the second coroutine is located, to obtain the first memory space; In response to determining that the first memory space meets the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, returning the first memory space to the memory allocation area, and merging the free memory space of the memory allocation area to obtain the second memory space; In response to determining that the second memory space meets the second preset condition for returning to the operating system, the second memory space is returned to the operating system.

11. The device according to claim 10, wherein: The device also includes: The return module is configured to terminate the operation in response to determining that the first memory space does not meet the first preset condition for returning the memory allocation area bound to the coroutine group where the second coroutine is located, or the second memory space does not meet the second preset condition for returning to the operating system.

12. The device according to any one of claims 8 to 10, wherein: The device also includes: The configuration module is configured to prohibit cross-thread scheduling of coroutines.

13. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores computer instructions that can be executed by the at least one processor. When the computer instructions are executed by the at least one processor, the at least one processor is enabled to implement the method according to any one of claims 1 to 6.

14. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to cause the computer to execute the method according to any one of claims 1 to 6.

Images