Database memory control method and system, medium, equipment and program product
By configuring alignment parameters and a pre-allocated buffer mechanism, the problem of improper memory management in the database system is solved, achieving efficient memory control and ensuring the stability and response speed of the database.
Patent Information
- Application Number
- CN202511577364.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-31
- Publication Date
- 2026-01-16
AI Technical Summary
In the Go runtime environment, database systems, especially graph databases or relational databases, struggle to achieve precise control over memory usage. Complex data structures and object references make it difficult to analyze object activity, leading to improper memory management.
By introducing configuration alignment parameters and a pre-allocated buffer mechanism, memory allocation and deallocation are ensured by configuring alignment for memory allocation sizes and managing memory within the pre-allocated buffer. Object pools and finalizer functions are used to manage memory usage, ensuring the accuracy and efficiency of memory allocation and deallocation.
It enables memory access judgment to be completed in constant time, reduces metadata overhead and branch jumps, improves memory preparation efficiency, prevents memory penetration layer by layer, maintains the latency stability and availability of the database, and enhances system stability.
Smart Images
Figure CN121349698A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of memory processing, in particular to a memory control method, system, medium, equipment and program product of a database. BACKGROUND
[0002] In a database system, it is usually necessary to accurately measure memory usage so as to schedule and limit according to the resource quota of a query session. In an ideal case, if the timing of each memory allocation and release can be accurately grasped, the database system can maintain the memory usage amount through simple "additive statistical allocation and subtractive statistical release".
[0003] However, in the runtime environment of the Go language (a statically strongly typed, compiled and concurrent programming language), such accurate control is almost impossible to achieve. This is because there are often a large number of complex data structures and object reference relationships in the upper-layer application program of the database. In the kernel implementation of a graph database or a relational database, typical objects include nodes (Node), edges (Edge), index entries, query execution plans and transaction contexts, etc. These objects are often shared among multiple coroutines or cross-referenced by different data structures. For example, a query context object may be simultaneously referenced by the execution engine, the optimizer and the storage engine; an edge object in a graph database may be simultaneously held by the data structures of the source node and the target node. In summary, the "everywhere reference" in the program makes it almost impossible to analyze whether an object is an active object in the program, and almost only the garbage collection mechanism can analyze and release the memory. SUMMARY
[0004] The purpose of the present application is to provide a memory control method, system, computer-readable storage medium, electronic device and computer program product of a database, which can effectively control the memory limit of a single query session.
[0005] To solve the above technical problems, the present application provides a memory control method of a database, which is applied to a memory allocator containing preset memory allocation parameters in a query context object, and the specific technical solutions are as follows:
[0006] Obtain a configuration alignment parameter;
[0007] Align the allocated memory request size according to the configuration alignment parameter;
[0008] If the aligned memory request size and the first total capacity of the used memory offset address do not exceed the capacity of the pre-allocated buffer, reassign the used memory offset address, take the first total capacity as the updated used memory offset address, and return the used memory offset address as the updated used memory offset address.
[0009] Optionally, if the aligned memory allocation size and the first total capacity of the used memory offset addresses exceed the capacity of the pre-allocated buffer, the following further steps are included:
[0010] Determine whether the second total capacity, which includes the allocated memory size and the memory size of the array to be allocated, exceeds the total amount of memory available for the query session in the memory allocation parameters.
[0011] If so, return a memory out-of-limit error;
[0012] If not, allocate an array object through the object pool;
[0013] Inject a finalizer function into the array object, reassign the address corresponding to the query context memory usage quantity in the memory allocation parameters, and use the sum of the historical allocated memory size and the size of the array object as the updated query context memory usage quantity;
[0014] The pre-allocated buffer and the used memory offset address are reassigned.
[0015] Optionally, for setting an array, it also includes:
[0016] The address corresponding to the query context memory usage quantity in the memory allocation parameters is reassigned, and the difference between the historical allocated memory size and the size of the array object is used as the updated query context memory usage quantity;
[0017] Set the memory usage of the query context corresponding to the set array to a null pointer and put it back into the memory pool.
[0018] Optionally, aligning the allocated memory request size according to the configuration alignment parameters includes:
[0019] Determine the alignment granularity in the configured alignment parameters;
[0020] Alignment is performed by calculating the quotient and remainder based on the allocated memory request size and the alignment granularity.
[0021] Optionally, aligning based on the allocated memory request size and the quotient and remainder calculated with respect to the alignment granularity includes:
[0022] If the remainder is zero, the memory request size is submitted to the memory allocator so that a memory block is returned according to the boundary-aligned address.
[0023] If the remainder is not zero, fill the gaps;
[0024] The total length after padding is submitted to the memory allocator as the final memory request size so that memory blocks can be returned according to boundary-aligned addresses.
[0025] Optional, also includes:
[0026] The memory allocation parameters of the memory allocator are set; the memory allocation parameters include the amount of memory used in the query context, the total amount of memory available for the query session, the pre-allocated buffer, and the offset address of the used memory.
[0027] This application also provides a database memory control system applied to a memory allocator whose query context object contains preset memory allocation parameters, the system comprising:
[0028] The parameter acquisition module is used to obtain configuration alignment parameters;
[0029] The memory alignment module is used to align the allocated memory request size according to the configuration alignment parameters.
[0030] The address assignment module is used to reassign the used memory offset address if the aligned memory allocation size and the first total capacity of the used memory offset address do not exceed the capacity of the pre-allocated buffer, using the first total capacity as the updated used memory offset address, and returning the used memory offset address as the updated used memory offset address.
[0031] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the memory control method described above.
[0032] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of the memory control method described above.
[0033] This application also provides a computer program product, including a computer program that, when executed, implements the steps of the memory control method described above.
[0034] This application provides a database memory control method, applied to a memory allocator whose query context object contains preset memory allocation parameters. The method includes: obtaining configuration alignment parameters; aligning the allocated memory request size according to the configuration alignment parameters; if the aligned memory request size and the first total capacity of the used memory offset address do not exceed the capacity of the pre-allocated buffer, reassigning the used memory offset address, using the first total capacity as the updated used memory offset address, and returning the used memory offset address as the updated used memory offset address.
[0035] This application introduces configuration alignment parameters and a pre-allocated buffer mechanism. After the memory request size is configured and aligned, it only needs to compare whether the aligned demand and the accumulated sum of used offset addresses exceed the buffer limit to complete the admission judgment in constant time, avoiding the frequent system calls and lock contention caused by the traditional "on-demand allocation - block-by-block return" approach. Once the judgment is successful, the memory allocator writes back the accumulated sum as a new offset address and immediately returns that address as a usable starting pointer. There is no need to maintain a free list or bitmap, which significantly reduces metadata overhead and branch jumps, thereby shortening the memory preparation time for a single query. Since the pre-configured memory allocation parameters are passed along with the query context, different concurrent queries can each carry independent buffer sizes and alignment strategies. This ensures fast response for lightweight transactions and allows complex analytical statements to reserve large blocks of contiguous space at once, avoiding the data migration risk caused by mid-term expansion. By pre-constraining the total memory consumption within the pre-allocated buffer, the system can complete capacity auditing before the query starts. When a surge in concurrency leads to insufficient remaining space, the memory scheduler can trigger flow control or circuit breaking in advance to prevent memory from penetrating the operating system layer by layer and causing a swap storm. This maintains the overall latency stability and availability of the database. Limiting memory resources for each query session enhances system stability.
[0036] This application also provides a database memory control system, a computer-readable storage medium, an electronic device, and a computer program product, which have the above-mentioned beneficial effects, and will not be elaborated here. Attached Figure Description
[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0038] Figure 1 A flowchart illustrating a database memory control method provided in an embodiment of this application;
[0039] Figure 2 A flowchart illustrating another database memory control method provided in an embodiment of this application;
[0040] Figure 3 This is a schematic diagram of a database memory control system structure provided in an embodiment of this application;
[0041] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0042] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0043] See Figure 1 , Figure 1 A flowchart illustrating a database memory control method provided in this application embodiment, the method comprising:
[0044] S101: Obtain configuration alignment parameters;
[0045] S102: Align the allocated memory request size according to the configuration alignment parameters;
[0046] S103: If the aligned memory allocation size and the first total capacity of the used memory offset address do not exceed the capacity of the pre-allocated buffer, reassign the used memory offset address, use the first total capacity as the updated used memory offset address, and return the used memory offset address as the updated used memory offset address.
[0047] In step S101, when a memory allocation request arrives, the original request length is normalized upwards using the above-mentioned configuration alignment parameters as the granularity scale, so that any length of service request is mapped to an integer multiple of the alignment granularity, ensuring that the starting address and length of the newly allocated block fall on the preset boundary, thereby eliminating the performance penalty and bus error that may be caused by non-aligned access.
[0048] The method of configuration alignment is not limited here. In one feasible implementation, the alignment granularity in the configuration alignment parameters can be determined first, and then the quotient and remainder can be calculated based on the allocated memory request size and the alignment granularity for alignment. Specifically, if the remainder is zero, the memory request size is submitted to the memory allocator so that a memory block can be returned according to the boundary-aligned address; if the remainder is not zero, gaps are filled. Finally, the total length after filling is submitted as the final memory request size to the memory allocator so that a memory block can be returned according to the boundary-aligned address.
[0049] Configuring alignment parameters is used to ensure memory access consistency, eliminate false sharing, and improve bus utilization. The primary basis for determining the alignment granularity comes from the formal description of the hardware specifications: the cache line length specified in the processor datasheet is usually a basic candidate value, such as 64 bytes, which is commonly used in current mainstream server platforms; when the system is equipped with coprocessor units that support vector extensions or atomic instruction sets, their boundary constraints on memory access should be further determined, and some accelerators require 128-byte or even 256-byte alignment.
[0050] In step S102, after obtaining the alignment granularity, whenever a business thread submits a memory request, the allocator first treats the original length as the dividend and performs integer division with the alignment granularity as the divisor, obtaining two intermediate values: the quotient and the remainder. If the remainder is zero, it indicates that the requested length is exactly an integer multiple of the alignment granularity, requiring no additional padding, and can directly proceed to the subsequent offset address calculation; if the remainder is non-zero, it indicates that there are free segments at the tail that have not reached the boundary, and in this case, it is necessary to fill the gaps. By adding a unit to the quotient and then multiplying it by the alignment granularity, the aligned length after rounding up can be obtained, ensuring that no matter how discrete the initial size of the business request is, the effective block length finally mapped to the memory pool is always regularized to an integer multiple of the alignment granularity. This ensures that the starting address and length of the newly allocated block fall on the preset boundary, eliminating performance penalties and bus errors caused by unaligned access, and providing a predictable step size unit for atomic address updates, thereby achieving lock-free, low-latency continuous memory allocation in high-concurrency scenarios.
[0051] The original memory request size requested by the business layer is rounded up according to the aforementioned alignment parameters to complete the configuration alignment. The length is normalized before it falls into the buffer, ensuring that each segment to be occupied can be aligned with the physical boundary of the hardware or protocol. This eliminates fragmentation gaps caused by non-integer divisibility of length, which not only improves cache utilization but also avoids bus errors and performance penalties that may be triggered by cross-boundary access.
[0052] In step S103, the used memory offset address and the pre-allocated buffer are both memory allocation parameters. In one feasible implementation, the memory allocation parameters of the memory allocator can be set in advance. The memory allocation parameters include the amount of memory used in the query context, the total amount of memory available for the query session, the pre-allocated buffer, and the used memory offset address.
[0053] In this invention example, a memory allocator for implementing the Malloc function needs to be injected into the query context object SessionCtx. The core data structure of the allocator is as follows:
[0054]
[0055] Here, `count` represents the amount of memory used in the query context, and can be added or subtracted from the memory address corresponding to the `count` variable. `total` represents the total amount of memory that can be used in each query session, i.e., the total amount of memory available for the query session. `Buffer` is a pre-allocated buffer, representing a contiguous block of memory, and `offset` indicates the location of the pre-allocated buffer that is being used.
[0056] The control flow of the memory control process of the above database is equivalent to the following steps:
[0057] Step 1: Align the allocated memory request size according to the alignment requirements based on the configured alignment parameters.
[0058] Step 2: Determine whether the result of adding offset to the aligned size is less than or equal to the buffer capacity.
[0059] Step 3: If the offset is reassigned, that is, the new result is the original offset result plus the aligned size, the address corresponding to the original offset is returned.
[0060] Align the size requested by the caller upwards to the minimum alignment multiple required by the configuration, resulting in the actual aligned size to be used. Add the aligned size to the current offset and check if the sum exceeds the total capacity of the buffer; if it does, the allocation fails.
[0061] If the boundary is not exceeded (i.e., not out of bounds), update the offset to "current offset + aligned size" and record the new used endpoint. Return the offset value before the update, which is the starting offset address of the allocated region in the buffer.
[0062] This application's embodiments introduce configuration alignment parameters and a pre-allocated buffer mechanism. After the memory request size is configured and aligned, it only needs to compare whether the aligned demand and the accumulated sum of used offset addresses exceed the buffer limit to complete the admission judgment in constant time, avoiding the frequent system calls and lock contention caused by the traditional "on-demand request - block-by-block return" approach. Once the judgment is successful, the memory allocator writes back the accumulated sum as a new offset address and immediately returns that address as a usable starting pointer, eliminating the need to maintain a free list or bitmap, significantly reducing metadata overhead and branch jumps, and thus shortening the memory preparation time for a single query. Since the pre-configured memory allocation parameters are passed along with the query context, different concurrent queries can each carry independent buffer sizes and alignment strategies, ensuring fast response for lightweight transactions and allowing complex analytical statements to reserve large blocks of contiguous space at once, avoiding the data migration risks caused by mid-term expansion. By pre-constraining the total memory consumption within the pre-allocated buffer, the system can complete capacity auditing before the query starts. When a surge in concurrency leads to insufficient remaining space, the memory scheduler can trigger flow control or circuit breaking in advance to prevent memory from penetrating the operating system layer by layer and causing a swap storm. This maintains the overall latency stability and availability of the database. Limiting memory resources for each query session enhances system stability.
[0063] The following section explains the changes in query context memory usage:
[0064] The steps for increasing the query context memory usage are as follows:
[0065] Step 1: Determine whether the second total capacity of the allocated memory size and the array memory size to be allocated exceeds the total memory available to the query session in the memory allocation parameters; if yes, return a memory over-limit error; if no, proceed to Step 2.
[0066] The second step is to allocate an array object through the object pool;
[0067] The third step is to inject a finalizer function into the array object, reassign the address corresponding to the query context memory usage quantity in the memory allocation parameters, and use the sum of the historical allocated memory size and the size of the array object as the updated query context memory usage quantity.
[0068] Step 4: Reassign values to the pre-allocated buffer and the used memory offset address.
[0069] Before the query engine prepares to request a new array for the result set, it first reads the total memory already used by the current query session, adds the allocated memory size to the estimated size of the array to be allocated, and obtains a second total capacity. Then, it retrieves the session-level "total available memory" threshold from the memory allocation parameters and compares it with the second total capacity. If the second total capacity is greater than the threshold, it immediately returns a memory overrun error code to the upper layer, terminating subsequent allocation operations, thereby ensuring that a single session does not exceed the global resource limit.
[0070] When the first step of the comparison passes, an array object allocation request is sent to the pre-built object pool. The object pool locks an array object of the same size in its own free list and returns its address to the query layer.
[0071] After the array object is returned, the engine immediately injects a finalizer function into it. The finalizer function is automatically triggered when the array's lifetime ends and it is garbage collected. Simultaneously, the field representing the memory usage of the query context is retrieved from the memory allocation parameters. This new value is then incremented by the current array object's byte length, and the new value is written back to the original field address. The existence of the finalizer function ensures that if a subsequent query is abnormally aborted or the array is prematurely released, the same counter will be decremented synchronously, thus reflecting the context's used memory accurately and in real time, preventing discrepancies caused by "only increasing, never decreasing" memory usage.
[0072] Finally, the pre-allocated buffer pointer is moved forward, skipping the space that was just occupied. At the same time, the used memory offset address is moved backward by the same distance, so that both point to the new free starting position. In this way, the next round of array allocation can still locate the contiguous available area in O(1) time, ensuring that the result set is stored compactly and sequentially in memory layout, improving the cache hit rate when transmitting to the client in batches, and eliminating the extra copying caused by gap fragmentation.
[0073] There are no restrictions on how to generate the finalizer function. In one feasible implementation, a target structure can be created, the function parameters can be set to empty and no return value can be set, and the finalizer function can be associated with the target structure to obtain the finalizer function.
[0074] Create a target structure that needs to manage its lifecycle. The target structure can contain relevant fields or status information to represent a specific resource object.
[0075] Write a special finalizer function for the target struct. An instance of the finalizer function could be as follows:
[0076] One parameter, which is the struct object itself, has no return value; the name can begin with "Finalize".
[0077] The main purpose of a finalizer function is to perform necessary cleanup work before an object is garbage collected, such as releasing occupied resources.
[0078] Use the `runtime.SetFinalizer` function to associate a pre-written finalizer function with its corresponding struct type. When an object of that type is no longer referenced and is facing garbage collection, the previously registered finalizer function will be automatically invoked.
[0079] Create and use object instances: Create instances of the above structure in the actual code and perform normal business logic processing. As the program runs, when these objects are no longer in use, they will become targets of garbage collection, triggering the registered finalizer functions to perform resource release and other cleanup operations.
[0080] In conjunction with the above embodiments, participants Figure 2 , Figure 2 A flowchart of another database memory control method provided in this application embodiment is shown below:
[0081] Step 1: Allocate a buffer of size n or 15 bytes of space;
[0082] The second step is to determine if the buffer, offset, and count parameters are all valid. If not, proceed to the next step. If yes, operate on the buffer and return the buffer address.
[0083] The third step is to determine whether the sum of total and count exceeds the size of the allocated buffer; if so, return an appropriate memory overrun error; otherwise, proceed to the next step.
[0084] Step 4: Determine the heap size allocated by the corresponding on_write function;
[0085] Step 5: Reset the buffer and offset;
[0086] Step 6: Assign values to the structure;
[0087] Step 7: Allocate new data objects from the memory pool.
[0088] To reduce the amount of memory used in the query context, taking a 32K array object as an example, the steps are as follows:
[0089]
[0090] Here, `buffer32K` is a 32K array. After allocation, `data` will be assigned to the `buffer` field. The `count` field of the array object needs to be assigned a value based on the `count` field in the `Aerna` structure object. The reduction of memory usage corresponding to the `count` variable mainly depends on the finalizer function. At this point, the address corresponding to the query context memory usage count in the memory allocation parameters can be reassigned, using the difference between the historical allocated memory size and the array object size as the updated query context memory usage count. Afterward, the query context memory usage count corresponding to the array is set to a null pointer and returned to the memory pool. The corresponding steps are as follows:
[0091] Step 1: Reassign the address corresponding to the count variable, that is, the new result is the original allocated memory size minus the size of this array object.
[0092] Step 2: Set the count corresponding to the array to nil, i.e., a null pointer;
[0093] Step 3: Put the specified array into the memory pool.
[0094] See Figure 3 , Figure 3 This is a schematic diagram of a database memory control system structure provided in an embodiment of this application. The system includes:
[0095] The parameter acquisition module is used to obtain configuration alignment parameters;
[0096] The memory alignment module is used to align the allocated memory request size according to the configuration alignment parameters.
[0097] The address assignment module is used to reassign the used memory offset address if the aligned memory allocation size and the first total capacity of the used memory offset address do not exceed the capacity of the pre-allocated buffer, using the first total capacity as the updated used memory offset address, and returning the used memory offset address as the updated used memory offset address.
[0098] Based on the above embodiments, as a preferred embodiment, it further includes:
[0099] The memory usage quantity increase module is used to perform the following steps: if the first total capacity of the aligned memory request size and the used memory offset address exceeds the capacity of the pre-allocated buffer, determine whether the second total capacity of the allocated memory size and the size of the array to be allocated exceeds the total amount of memory available for the query session in the memory allocation parameters;
[0100] If so, return a memory out-of-limit error;
[0101] If not, allocate an array object through the object pool;
[0102] Inject a finalizer function into the array object, reassign the address corresponding to the query context memory usage quantity in the memory allocation parameters, and use the sum of the historical allocated memory size and the size of the array object as the updated query context memory usage quantity;
[0103] The pre-allocated buffer and the used memory offset address are reassigned.
[0104] Based on the above embodiments, as a preferred embodiment, it further includes:
[0105] The memory usage increment module is used to perform the following steps: for a given array, reassign the address corresponding to the query context memory usage in the memory allocation parameters, and use the difference between the historical allocated memory size and the size of the array object as the updated query context memory usage; set the query context memory usage corresponding to the given array to a null pointer and put it back into the memory pool.
[0106] Based on the above embodiments, as a preferred embodiment, the memory alignment module includes:
[0107] A granularity determination unit is used to determine the alignment granularity in the configured alignment parameters;
[0108] Alignment units are used to align memory allocations by calculating the quotient and remainder based on the allocated memory request size and the alignment granularity.
[0109] Based on the above embodiments, as a preferred embodiment, the alignment unit is a unit for performing the following steps:
[0110] If the remainder is zero, the memory request size is submitted to the memory allocator so that a memory block can be returned according to the boundary-aligned address; if the remainder is not zero, gaps are filled; the total length after filling is submitted as the final memory request size to the memory allocator so that a memory block can be returned according to the boundary-aligned address.
[0111] Based on the above embodiments, as a preferred embodiment, it further includes:
[0112] The memory allocation parameter configuration module is used to set the memory allocation parameters of the memory allocator; the memory allocation parameters include the amount of memory used in the query context, the total amount of memory available for the query session, the pre-allocated buffer, and the offset address of the used memory.
[0113] This application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method described in the above method embodiments.
[0114] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0115] The computer-readable storage medium provided in this embodiment includes the method mentioned above, and has the same effect.
[0116] This application also provides an electronic device, see [link to document]. Figure 4 The present application provides a structural diagram of an electronic device, such as... Figure 4 As shown, it may include a processor 1410 and a memory 1420.
[0117] The processor 1410 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 1410 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 1410 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 1410 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 1410 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.
[0118] The memory 1420 may include one or more computer-readable storage media, which may be non-transitory. The memory 1420 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 1420 is used to store at least the following computer program 1421, which, after being loaded and executed by the processor 1410, is capable of implementing the relevant steps in the methods executed by the electronic device side as disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 1420 may also include an operating system 1422 and data 1423, etc., and the storage method may be temporary storage or permanent storage. The operating system 1422 may include Windows, Linux, Android, etc.
[0119] In some embodiments, the electronic device may further include a display screen 1430, an input / output interface 1440, a communication interface 1450, a sensor 1460, a power supply 1470, and a communication bus 1480.
[0120] certainly, Figure 4 The structure of the electronic device shown does not constitute a limitation on the electronic device in the embodiments of this application. In practical applications, the electronic device may include more than [other components]. Figure 4 More or fewer components as shown, or combinations of certain components.
[0121] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. As the system provided in the embodiments corresponds to the method provided in the embodiments, the description is relatively simple; relevant parts can be found in the method section.
[0122] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.
[0123] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
Claims
1. A memory control method of a database, characterized by, The method, applied to a memory allocator whose query context object contains preset memory allocation parameters, includes: Retrieve configuration alignment parameters; The allocated memory request size is aligned according to the configuration alignment parameters. If the aligned memory allocation size and the first total capacity of the used memory offset address do not exceed the capacity of the pre-allocated buffer, the used memory offset address is reassigned, the first total capacity is used as the updated used memory offset address, and the used memory offset address is returned as the updated used memory offset address.
2. The memory control method of claim 1, wherein, If the aligned memory allocation size and the first total capacity of the used memory offset addresses exceed the capacity of the pre-allocated buffer, it also includes: Determine whether the second total capacity, which includes the allocated memory size and the memory size of the array to be allocated, exceeds the total amount of memory available for the query session in the memory allocation parameters. If so, return a memory out-of-limit error; If not, allocate an array object through the object pool; Inject a finalizer function into the array object, reassign the address corresponding to the query context memory usage quantity in the memory allocation parameters, and use the sum of the historical allocated memory size and the size of the array object as the updated query context memory usage quantity; The pre-allocated buffer and the used memory offset address are reassigned.
3. The memory control method of claim 2, wherein, For setting arrays, it also includes: The address corresponding to the query context memory usage quantity in the memory allocation parameters is reassigned, and the difference between the historical allocated memory size and the size of the array object is used as the updated query context memory usage quantity; Set the memory usage of the query context corresponding to the set array to a null pointer and put it back into the memory pool.
4. The memory control method of claim 1, wherein, Aligning the allocated memory request size according to the configuration alignment parameters includes: Determine the alignment granularity in the configured alignment parameters; Alignment is performed by calculating the quotient and remainder based on the allocated memory request size and the alignment granularity.
5. The memory control method of claim 4, wherein, Alignment is performed by calculating the quotient and remainder based on the allocated memory request size and the alignment granularity, including: If the remainder is zero, the memory request size is submitted to the memory allocator so that a memory block is returned according to the boundary-aligned address. If the remainder is not zero, fill the gaps; The total length after padding is submitted to the memory allocator as the final memory request size so that memory blocks can be returned according to boundary-aligned addresses.
6. The memory control method according to any one of claims 1 to 5, wherein, Also includes: Set the memory allocation parameters of the memory allocator; The memory allocation parameters include the amount of memory used in the query context, the total amount of memory available for the query session, the pre-allocated buffer, and the offset address of the memory already used.
7. A memory control system of a database, characterized by, A memory allocator applied to a query context object containing preset memory allocation parameters, the system comprising: The parameter acquisition module is used to obtain configuration alignment parameters; The memory alignment module is used to align the allocated memory request size according to the configuration alignment parameters. The address assignment module is configured to reassign the used memory offset address if the aligned memory request size and the first total capacity of the used memory offset address do not exceed the capacity of the pre-allocated buffer, take the first total capacity as the updated used memory offset address, and return the updated used memory offset address.
8. An electronic device, comprising: The computer program product comprises: a memory for storing a computer program; a processor for executing the computer program to implement the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer program product comprises:
10. A computer program product, characterised in that, a memory for storing a computer program; a processor for executing the computer program to implement the steps of the method according to any one of claims 1 to 6. The computer program product comprises: a memory for storing a computer program; a processor for executing the computer program to implement the steps of the method according to any one of claims 1 to 6.