Pointer recycling method, system and device

Abstract

The application provides a pointer recycling method, system and device, the method comprising: scanning source code or an abstract syntax tree through a compile-time automatic instrumentation module, identifying a resource reference entry and a target variable to be managed, inserting a cleanup attribute and ownership transfer semantics for the target variable, and generating a resource description table; the resource reference entry comprises a naked pointer; the naked pointer is wrapped using a lightweight proxy structure, and metadata is associated through the lightweight proxy structure; a resource in the resource description table is registered, reference count management is performed, cross-function transfer migration is performed, and a unified cleaning operation is performed through a runtime resource manager, to obtain a pointer life cycle state; system memory occupation information is collected in real time at runtime, memory recycling frequency and strategy are dynamically adjusted according to the memory occupation information, and resource recycling is performed according to the pointer life cycle state. The scheme improves the stability of long-term system operation, and improves the stability, reliability and development efficiency of C language software development.

Description

Technical Field

[0001] This application relates to the field of memory management technology for computer programming languages, and more specifically, to a pointer reclamation method, system, and device. Background Technology

[0002] With the rapid development of computer technology, C language, as an efficient and flexible system-level programming language, has been increasingly applied in core areas such as operating system kernel development, embedded device drivers, high-performance computing clusters, and critical network systems due to its ability to directly manipulate memory and its excellent execution performance.

[0003] Currently, traditional C language uses the "raw pointer" mechanism to directly read and write memory addresses, giving developers a high degree of freedom in memory control. However, this flexibility comes at the cost of a lack of built-in memory lifecycle tracking and automatic garbage collection mechanisms. This has led to a series of difficult-to-cure memory safety problems in C language software development for a long time: dangling pointers and wild pointers are easily generated, causing unexpected system crashes. Furthermore, memory leaks can easily occur due to programmers omitting free operations or missing logical paths, affecting the long-term stability of the system. The validity analysis of pointers across statements and functions relies on single-statement analysis and complex symbolic execution based on CFG, which places a heavy burden on the compiler and has limited coverage in large projects. Finally, the lack of raw pointer reference counting or lifecycle information makes it impossible to determine at runtime whether the memory pointed to by the pointer is valid, resulting in poor reliability and affecting the stability, reliability, and development efficiency of the software system. Summary of the Invention

[0004] This application provides a pointer recycling method, system, and device.

[0005] A first aspect of the embodiments of this application provides a pointer reclamation method, the method comprising: The compiler automatically instrumentes the source code or abstract syntax tree to identify the resource reference entry points and target variables that need to be managed. It then inserts cleanup attributes and ownership transfer semantics into the target variables and generates a resource description table. The target variables serve as storage carriers for the raw pointers and resource handles. The resource description table includes the resources and their corresponding metadata. The resource reference entry points are used to access the resources and include raw pointers. The raw pointer is wrapped using a lightweight proxy structure, and the metadata is associated with the lightweight proxy structure. The runtime resource manager performs registration, reference counting management, cross-function transfer migration, and unified cleanup operations on the resources in the resource description table to obtain the pointer lifecycle state. The system collects system memory usage information in real time during runtime, dynamically adjusts the memory reclamation frequency and strategy based on the memory usage information, and performs resource reclamation based on the pointer lifecycle state.

[0006] A second aspect of this application provides a pointer recycling system, the system comprising: Compile-time automatic instrumentation module, runtime resource manager, and lightweight proxy structure; The compile-time automatic instrumentation module is used to: scan source code or abstract syntax tree, identify resource reference entry points and target variables that need to be managed, insert cleanup attributes and ownership transfer semantics into the target variables, and generate a resource description table; the target variables are the storage carriers for the raw pointers and resource handles; the resource description table includes resources and corresponding metadata; the resource reference entry points are used to access the resources; the resource reference entry points include raw pointers; The lightweight proxy structure is used to: wrap the raw pointer and associate the metadata through the lightweight proxy structure; The runtime resource manager is used to: register resources in the resource description table, manage reference counts, perform cross-function transfer migrations, and perform unified cleanup operations to obtain the pointer lifecycle state; The system collects system memory usage information in real time during runtime, dynamically adjusts the memory reclamation frequency and strategy based on the memory usage information, and performs resource reclamation based on the pointer lifecycle state.

[0007] A third aspect of this application provides a computer device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above methods.

[0008] This application provides a pointer reclamation method, which includes: scanning the source code or abstract syntax tree through a compile-time automatic instrumentation module to identify resource reference entry points and target variables that need to be managed; inserting cleanup attributes and ownership transfer semantics into the target variables; and generating a resource description table. The target variables are storage carriers for raw pointers and resource handles. The resource description table includes resources and corresponding metadata. Resource reference entry points are used to access resources. Resource reference entry points include raw pointers. A lightweight proxy structure is used to wrap the raw pointers, and the metadata is associated through the lightweight proxy structure. A runtime resource manager performs registration, reference counting management, cross-function transfer migration, and unified cleanup operations on the resources in the resource description table to obtain the pointer lifecycle state. At runtime, system memory usage information is collected in real time, and the memory reclamation frequency and strategy are dynamically adjusted according to the memory usage information. Resource reclamation is performed according to the pointer lifecycle state.

[0009] Compared with existing technologies, the technical solution in this application solves the problem of the lack of a built-in lifecycle marking mechanism in traditional C language by automatically instrumenting resource reference entry points and target variables at compile time, inserting cleanup attributes and ownership transfer semantics, and generating a resource description table. By pre-binding cleanup logic and ownership rules, it avoids dangling pointers, wild pointers, and memory leaks caused by manual management oversights at the source. Furthermore, by wrapping raw pointers with a lightweight proxy structure and associating them with metadata, it not only maintains compatibility with native C pointer syntax but also achieves the binding of raw pointers with resource metadata without requiring compiler modifications or the introduction of garbage collection (GC), thus reducing the integration cost of the technical solution. Finally, it performs resource registration and reference through a runtime resource manager. The technical features of reference counting management, cross-function transfer and migration, and unified cleanup enable dynamic tracking of the entire resource lifecycle. This solves the problems of limited coverage and heavy compiler burden of traditional CFG-based single-statement analysis. Through precise maintenance of reference counting and cross-function ownership transfer, it ensures that resources are not released repeatedly or missed. By combining system memory usage information to dynamically adjust the frequency and strategy of garbage collection and performing garbage collection based on pointer lifecycle status, it achieves intelligent decision-making on garbage collection timing. This not only avoids blind garbage collection affecting program running efficiency, but also prioritizes the collection of invalid resources when memory usage is too high, further improving the long-term stability of the system. Ultimately, it comprehensively improves the stability, reliability, and development efficiency of C language software development. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application; Figure 2 A flowchart of a pointer reclamation method provided in one embodiment of this application; Figure 3 This is a flowchart illustrating a method for inserting a cleanup attribute and ownership transfer semantics into a target variable, as provided in one embodiment of this application. Figure 4 A flowchart illustrating the lifecycle state machine of a raw pointer provided in one embodiment of this application; Figure 5 This is a schematic diagram illustrating the process from compile-time instrumentation enhancement to runtime management system-wide automated management of resources throughout their entire lifecycle, as provided in one embodiment of this application. Detailed Implementation

[0011] In the process of implementing this application, the inventors discovered that the raw pointer in traditional C language has problems such as uncontrolled lifetime, difficulty in garbage collection, and poor reliability.

[0012] To make the technical solutions and advantages of the embodiments of this application clearer, the exemplary embodiments of this application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0013] Currently, the design features of the C language dictate the lack of built-in raw pointer lifetime tracking and automatic garbage collection mechanisms. When the memory pointed to by a pointer is released prematurely (e.g., by calling `free` or `delete`), but the pointer's reference is not cleared, a dangling pointer is formed; while an uninitialized pointer used directly constitutes a wild pointer. When the memory pointed to by such pointers is released prematurely, but the pointer reference still exists, the program can access illegal memory addresses, easily leading to unpredictable system crashes. Furthermore, C requires developers to manually manage memory allocation and deallocation using functions like `malloc` / `free` and `new` / `delete`. However, in complex business logic, programmers can easily overlook deallocation operations, or flaws in code branch logic can result in missing deallocation paths. This can cause memory to be continuously occupied and unreclaimed during system operation, eventually leading to memory exhaustion, resulting in system performance degradation or even crashes.

[0014] Traditional compilers primarily rely on single-statement analysis based on control flow graphs (CFGs) or complex symbolic execution techniques to check pointer validity. However, in large projects with numerous code branches and complex function call relationships, these analysis methods not only impose a significant computational burden on the compiler but also struggle to cover multi-statement, cross-function pointer passing scenarios, failing to fully guarantee pointer safety. Furthermore, unlike C++'s RAII (Resource Acquisition-Initialization) mechanism, shared_ptr / unique_ptr smart pointers, and Rust's ownership and borrowing mechanisms, C does not provide any built-in raw pointer reference counting or lifetime tracking features. Developers must rely entirely on their experience to manually maintain pointer states, increasing the development threshold and significantly raising the probability of human error. Additionally, during C runtime, the program cannot automatically determine whether the memory pointed to by a pointer is still valid. Developers must design their own logic to record memory usage, which not only increases code redundancy but also risks accidentally releasing memory due to logical oversights, leading to system exceptions.

[0015] To address the aforementioned shortcomings, this application provides a pointer reclamation method. Compared with related technologies, the technical solution in this application solves the problem of the lack of a built-in lifecycle marking mechanism in traditional C language by automatically instrumenting resource reference entry points and target variables at compile time, inserting cleanup attributes and ownership transfer semantics, and generating a resource description table. By pre-binding cleanup logic and ownership rules, it avoids the generation of dangling pointers and wild pointers, as well as memory leaks caused by manual management oversights. Furthermore, by wrapping raw pointers with a lightweight proxy structure and associating them with metadata, it is compatible with native C language pointer syntax and achieves the binding of raw pointers with resource metadata without requiring compiler modifications or the introduction of garbage collection (GC), thus reducing the integration cost of the technical solution. Finally, it utilizes runtime resource management... The system employs technical features such as resource registration, reference counting management, cross-function transfer and migration, and unified cleanup to achieve dynamic tracking of the entire resource lifecycle. This solves the problems of limited coverage and heavy compiler burden associated with traditional CFG-based single-statement analysis. Through precise maintenance of reference counting and cross-function ownership transfer, it ensures that resources are not repeatedly released or missed. By dynamically adjusting the frequency and strategy of garbage collection based on system memory usage information and performing garbage collection based on pointer lifecycle states, it achieves intelligent decision-making on garbage collection timing. This not only avoids blind garbage collection affecting program efficiency but also prioritizes the collection of invalid resources when memory usage is too high, further improving the long-term stability of the system. Ultimately, this comprehensively improves the stability, reliability, and development efficiency of C language software development.

[0016] The solutions in this application embodiment can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0017] Please see Figure 1 The present application provides a schematic diagram of the structure of an example computer device. Figure 1As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media can be, for example, a hard disk. The non-volatile storage media stores files (which can be files to be processed or processed files), an operating system, and computer programs. The internal memory provides an environment for the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a pointer recycling method. The display screen can be an LCD screen or an e-ink display. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse. The computer device has wireless communication transceiver capabilities, such as ad hoc network communication devices, data link communication devices, and Bluetooth communication devices.

[0018] Please see Figure 2 The following embodiments use the aforementioned computer device as the execution subject, and specifically illustrate the application of the pointer recycling method provided in this application to the aforementioned computer device for data processing. The pointer recycling method provided in this application includes the following steps 201-204: Step 201: Scan the source code or abstract syntax tree using the compile-time automatic instrumentation module to identify the resource reference entry points and target variables that need to be managed, insert the cleanup attribute and ownership transfer semantics into the target variables, and generate a resource description table; the target variables are storage carriers for raw pointers and resource handles; the resource description table includes resources and corresponding metadata; the resource reference entry point is used to access resources; the resource reference entry point includes raw pointers.

[0019] It should be noted that the pointer recycling method adopted in this application is applied to a pointer recycling system, which includes: a compile-time automatic instrumentation module (Auto-Instrument), a runtime resource manager (RRM), and a lightweight proxy structure. The lightweight proxy structure can be a raw pointer proxy wrapper structure (Pointer Proxy, PP).

[0020] The compile-time automatic instrumentation module is a preparatory stage. It first scans the C source code or Abstract Syntax Tree (AST) to automatically discover the raw pointers that need to be managed. This AST is an intermediate form of the compiled code, making it easier for the program to identify and manipulate, and accurately locating the resource reference entry point. The core of the resource reference interface is the raw pointer, which also includes a resource handle. This serves as the sole entry point for accessing the underlying resource and identifies the target variable, which is a container for storing the raw pointer / handle, such as `char`. p、FILE fp; then two key semantics are inserted for the target variable: the cleanup attribute and the ownership transfer definition. The cleanup attribute is used to bind the automatic cleanup function and establish the basic rules for triggering cleanup when the scope exits. The ownership transfer semantics are used to resolve resource conflicts when passing resources across functions / scopes. Finally, a resource description table (RDT) is generated. The resource description table is a static metadata list that records resources and their corresponding metadata one-to-one, becoming an information bridge between compile time and runtime.

[0021] Among them, raw pointers and resource handles include at least one of the following: heap memory pointers returned by malloc / calloc / realloc functions, file handles returned by fopen / open functions, system resource handles returned by socket / pipe / pthread functions, and user-defined resource types marked with the __resource keyword.

[0022] For example, by scanning C source code or AST (such as clang), identify: return values ​​of malloc / calloc / realloc; return values ​​of fopen / open; handles returned by functions such as socket, pipe, and pthread; and user-annotated resource types, such as __resource int fd; __resource void buf.

[0023] Specifically, a raw pointer can include the return value of malloc / calloc / realloc, that is, a pointer to the allocated heap memory such as char. In `p=malloc(128)`, `p` refers to the heap memory reference; a resource handle is an identifier for a system resource, such as a file handle returned by `fopen`, a socket handle returned by `socket`, a thread handle returned by `pthread`, and a pipe handle returned by `pipe`. Its core characteristic is that it is the medium for accessing resources; if its lifecycle is out of control, it can lead to problems such as memory leaks and dangling references, which is the core management objective of this patent.

[0024] The target variable refers to the variable in the C source code that stores the aforementioned raw pointers or resource handles (i.e., the variable carrying a resource reference), and is the object of operation for the compile-time instrumentation module. For example, it can include variables storing heap memory pointers: char... p, the variable p stores the raw pointer returned by malloc; FILE is the variable that stores the resource handle. `fp` (the variable `fp` stores the file handle returned by `fopen`), `int fd = open(...)`, where `fd` stores the file descriptor handle returned by `open`; user-defined resource variable: `__resourcevoid` The variable `buf` stores user-defined pointers to resources that need to be managed. Its core feature is that it is a container for raw pointers / resource handles. The compile-time instrumentation module indirectly manages the lifecycle of the raw pointers / handles it carries by manipulating this variable.

[0025] Furthermore, inserting the `cleanup` attribute of the target variable to bind an automatic cleanup function refers to adding compiler-supported cleanup attributes, such as GCC's `__attribute__((cleanup))`, to the target variable that carries a raw pointer / resource handle, binding a predefined automatic cleanup function. Inserting ownership transfer semantics means that when the resource (raw pointer or resource handle) carried by the target variable is passed across functions / scopes (such as a function returning a pointer), automatic marking logic is inserted to clarify the rules for transferring resource ownership.

[0026] In this step, the resource identification and rule binding are completed in advance by the compile-time tool (compile-time automatic instrumentation module), avoiding additional complex analysis overhead at runtime.

[0027] Step 202: Wrap the raw pointer with a lightweight proxy structure and associate the metadata through the lightweight proxy structure.

[0028] Wrapping raw pointers with a lightweight proxy structure falls under the syntax adaptation stage, primarily addressing compatibility issues between resource management and native C pointer usage habits. By using a custom lightweight proxy structure (such as the `auto_ptr` structure), raw pointers are non-intrusively wrapped. This structure contains only two core fields: a `value` field, which stores the original raw pointer value and is directly accessible to the user, functioning identically to a regular raw pointer; and a `meta_id` field, a unique identifier associated with the resource metadata in the Resource Description Table (RDT). Essentially, this adds management metadata to the raw pointer without altering user habits, decoupling raw pointer operations from resource lifecycle management.

[0029] This application does not modify the raw pointer itself, but instead wraps it with a lightweight proxy structure to ensure full compatibility with C pointer syntax. An example of the lightweight proxy structure can be represented as follows: typedef struct { void value uint32_t meta_id; / / RR table index } auto_ptr; When using it, it should be consistent with a regular raw pointer: p.value p.value.

[0030] Step 203: The runtime resource manager performs registration, reference counting management, cross-function transfer migration, and unified cleanup operations on the resources in the resource description table to obtain the pointer lifecycle status.

[0031] The runtime maintains the pointer lifecycle. The runtime resource manager acts as the central brain, performing full-process management of resources based on the resource description table (RDT) generated during compilation and the metadata bound to the proxy structure. Finally, it outputs the pointer lifecycle status, such as "allocated", "in use", "ownership transferred", "expired", etc.

[0032] Specifically, this is achieved through four core operations: First, resource registration, which includes creating an RRNode structure, associating it with RDT metadata, storing it in a resource record table, and completing runtime archiving of resources; second, reference counting management, which updates the refcnt field in RRNode in real time to record the number of times a resource is referenced, providing a basis for reclamation judgment; third, cross-function transfer migration, which completes the increment and decrement of reference counts on the transferring end and the transferring end by responding to the auto_move flag, ensuring clear ownership; and fourth, unified cleanup, which performs corresponding cleanup operations according to the release callback in RDT and according to the resource type.

[0033] During resource registration, the RRNode structure is created using the following configuration: typedef struct { void ptr; ResourceType type; int refcnt; cleanup_fn fn; } RRNode; And register the pointer, and register the new resource in the RR table using auto_wrap().

[0034] It's important to note that during reference counting management, when multiple raw pointers point to the same address, the Reference Counting (RR) table records the reference relationships to prevent duplicate releases. Specifically, when the resource associated with the first raw pointer (carried by the target variable and wrapped by a proxy structure) is registered, the runtime creates a corresponding RRNode structure and stores it in the RR table. At this time, the reference count field (refcnt) in the RRNode is initialized to 1, indicating that the resource currently has only one pointer reference. When other raw pointers subsequently point to the same resource address, the compile-time instrumentation mark and the proxy structure's meta_id guide the runtime resource manager to quickly match the corresponding RRNode in the RR table and automatically increment its refcnt field, completing the recording and updating of the reference relationships. When any raw pointer pointing to the resource becomes invalid (e.g., its scope ends, or it is actively set to null), the runtime will locate the corresponding RRNode again and decrement the refcnt field. Only when the refcnt field of the RRNode eventually reaches 0 does it mean that no raw pointers are currently referencing the resource, and only then will the runtime resource manager's cleanup unit trigger the corresponding release logic such as free and fclose.

[0035] This automatic reference counting mechanism based on RR table and RRNode structure eliminates the need for developers to manually maintain reference counts. By accurately recording the association between multiple raw pointers and the same resource address, it fundamentally avoids two core problems: when a resource is referenced by multiple pointers, blindly releasing the resource when one pointer fails, causing other pointers to become dangling pointers; and repeatedly executing release operations when multiple pointers fail one after another, causing program crashes. This achieves secure management and efficient recycling of shared resources.

[0036] Step 204: Collect system memory usage information in real time during runtime, dynamically adjust the memory reclamation frequency and strategy based on the memory usage information, and perform resource reclamation based on the pointer lifecycle status.

[0037] This step, which performs resource replay based on pointer lifecycle states, aims to address the rigidity of traditional fixed reclamation strategies and achieve on-demand reclamation. The specific process is as follows: First, a dedicated monitoring thread collects real-time system memory usage information, such as memory utilization rate, remaining available memory, and memory fragmentation level. Then, based on this information, the reclamation strategy is dynamically adjusted. For example, when memory utilization is low, the reclamation frequency is reduced to minimize the impact on program efficiency; when memory utilization is high, the reclamation frequency is increased, prioritizing the reclamation of long-term idle resources with a reference count of 0. Finally, combining the pointer lifecycle states output by the runtime resource manager, reclamation operations are only performed on resources that are invalid and have a reference count of 0, ensuring both the safety and efficiency of reclamation.

[0038] In this embodiment, the target variables and resource description tables (RDTs) marked by the compile-time automatic instrumentation module are output to provide input for the proxy structure wrapper; the proxy pointer with metadata is output through the lightweight proxy structure wrapper to provide the runtime resource manager with a resource access entry and metadata index; the runtime resource manager outputs the pointer lifecycle state to provide the core decision basis for dynamic adaptive reclamation; the dynamic adaptive reclamation sends reclamation control instructions to the runtime resource manager to drive the unified cleanup operation to complete the resource reclamation and update the pointer lifecycle state at the same time, forming a closed-loop management.

[0039] Compared with existing technologies, the technical solution in this application solves the problem of the lack of a built-in lifecycle marking mechanism in traditional C language by automatically instrumenting resource reference entry points and target variables at compile time, inserting cleanup attributes and ownership transfer semantics, and generating a resource description table. By pre-binding cleanup logic and ownership rules, it avoids dangling pointers, wild pointers, and memory leaks caused by manual management oversights at the source. Furthermore, by wrapping raw pointers with a lightweight proxy structure and associating them with metadata, it is compatible with native C language pointer syntax and achieves the binding of raw pointers with resource metadata without modifying the compiler or introducing garbage collection, thus reducing the integration cost of the technical solution. Finally, it performs resource registration and reference calculation through a runtime resource manager. The technical features of reference counting, cross-function transfer and migration, and unified cleanup enable dynamic tracking of the entire resource lifecycle. This solves the problems of limited coverage and heavy compiler burden of traditional CFG-based single-statement analysis. Through precise maintenance of reference counting and cross-function ownership transfer, it ensures that resources are not released repeatedly or missed. By combining system memory usage information to dynamically adjust the frequency and strategy of garbage collection and performing garbage collection based on pointer lifecycle status, it achieves intelligent decision-making on garbage collection timing. This not only avoids blind garbage collection affecting program running efficiency, but also prioritizes the collection of invalid resources when memory usage is too high, further improving the long-term stability of the system. Ultimately, it comprehensively improves the stability, reliability, and development efficiency of C language software development.

[0040] In one embodiment, the above describes the insertion of the cleanup attribute into the target variable and the semantics of ownership transfer; please refer to [link to relevant documentation]. Figure 3 As shown, it includes: Step 301: Insert the cleanup property of the target variable to bind the automatic cleanup function.

[0041] Step 302: When the raw pointer and resource handle carried by the target variable are passed across scopes through function return, the original return statement corresponding to the target variable is converted into a call form with ownership transfer flags to insert ownership transfer semantics.

[0042] Specifically, after obtaining the target variables, the cleanup attribute can be automatically inserted into these variables. Here, the target variables are the storage carriers (such as char) that hold raw pointers (such as the heap memory pointer allocated by malloc) and resource handles (such as the file handle returned by fopen). p、FILE fp), the inserted cleanup attribute is a hook attribute based on compiler native support (such as GCC's attribute_((cleanup))).

[0043] When inserting the cleanup attribute into a target variable, it can be represented by the following structure: void func() { char p = malloc(128); ... } Automatically converted to during compilation: auto_ptr p __attribute__((cleanup(__auto_cleanup))) = auto_wrap(malloc(128), RESOURCE_HEAP); When inserting ownership transfer semantics, it can be represented by the following structure: return p; Automatically converted to: return auto_move(p); This prevents the pointer from being cleared twice.

[0044] It also automatically generates a Resource Description Table (RDT), in which each resource is recorded with its type, release callback, and source location.

[0045] This embodiment, by inserting the `cleanup` attribute into the target variable, fundamentally avoids the problems of traditional C language where developers forget to call release functions such as `free` / `close`, or where resources are missed due to missing business logic branches. This significantly reduces the risk of memory leaks and system resource exhaustion (such as file handle exhaustion). Furthermore, by binding a unified automatic cleanup function, the cleanup logic is standardized, eliminating the need for developers to write custom cleanup code for different types of resources, simplifying the development process and improving development efficiency. Based on native compiler attributes, it requires no modification to the compiler kernel, is compatible with mainstream C language compilers, and has good compatibility and portability, allowing direct embedding into various C / C++ projects. By inserting ownership transfer semantics, two core conflicts caused by cross-scope resource transfer are completely resolved. This avoids the problem of dangling pointers / invalid handles when the resource is released by the cleanup function triggered by the cleanup property when the original scope exits, and also avoids the problem of program crashes caused by duplicate releases when both the original and new scopes perform cleanup operations on the resource. Furthermore, it eliminates the need for developers to manually mark resource ownership or write additional resource transfer verification logic, achieving non-intrusive automated processing of ownership transfer and reducing the probability of human error. It also supports multi-level nested function transfer scenarios, and the ownership mark can be automatically synchronized with the transfer of the target variable, covering the complex call chain of large projects, ensuring the clarity and accuracy of resource ownership traceability, and further improving the stability and reliability of program operation.

[0046] In one optional embodiment of this application, cross-function transfer includes: When calling the function for ownership migration marker, the resource reference count corresponding to the outgoing location is decremented by 1, and the resource reference count corresponding to the incoming location is incremented by 1 to obtain the updated resource reference count; When performing a cleanup operation in the original scope, the release operation of the resource is skipped based on the updated resource reference count.

[0047] Specifically, when the program executes a function with an ownership transfer flag (such as auto_move), the runtime resource manager first locates the corresponding RRNode structure of the resource in the RR table using the meta_id in the target variable proxy structure. Then, it triggers a bidirectional update of the reference count, decrementing the reference count of the RRNode corresponding to the resource transfer-out position (the target variable in the original scope) by 1, indicating that the original scope relinquishes ownership of the resource. It also increments the reference count of the same RRNode corresponding to the resource transfer-in position (the receiving variable in the new scope) by 1, indicating that the new scope takes over ownership of the resource. Finally, the updated resource reference count is obtained. When the original scope finishes execution and triggers the cleanup operation, the runtime reads the updated reference count of the resource. If the count is greater than 0, it means that a new scope has taken over the resource. In this case, the release operation of the resource is automatically skipped, and only the state of the target variable itself is reset without touching the underlying resource.

[0048] Automatic transfer across functions can be represented by the following structure: During the call to auto_move(): Transfer location refcnt-- Transfer position refcnt++ The original scope will not be incorrectly released during cleanup.

[0049] This embodiment uses cross-function transfer to accurately maintain resource reference relationships, completely avoiding resource duplication and dangling pointer issues caused by cross-scope transfer, thus ensuring program stability. It eliminates the need for manual maintenance of reference counts and ownership verification, achieving automated management of resource transfer and reducing development costs and the probability of human error. Logical jumps are achieved solely through reference count increments and decrements and threshold judgments, making it lightweight with no additional performance loss and adaptable to various C language engineering scenarios.

[0050] In one optional embodiment of this application, the metadata includes: resource type, release callback, source location, and resource identifier; performing a unified cleanup operation includes: matching the corresponding release function based on the resource type to select the corresponding cleanup method; resource types include memory resources, file handles, file descriptors, and thread locks. Matching the corresponding release function based on the resource type includes: Call the `free` function for heap memory resources, the `fclose` function for file handles, the `close` function for file descriptors, and the `pthread_mutex_destroy` function for thread locks.

[0051] Specifically, the aforementioned metadata carries the core management information of the managed resources. Among them, the four major fields—resource type, release callback, source location, and resource identifier—work together to provide a clear basis for the unified cleanup operation. When performing the unified cleanup operation, the runtime resource manager first queries the resource description table (RDT) for the corresponding resource's metadata using the resource identifier in the target variable proxy structure. Then, it uses the resource type in the metadata as the matching basis to filter out the corresponding release function and determine the specific cleanup method.

[0052] Differentiated and precise release logic is executed for different types of core resources: for heap memory resources, they are allocated by malloc / calloc / realloc, and the free function is called to complete memory reclamation; for file handles, fopen returns a FILE... For file descriptors, i.e., the integer identifier returned by open, the close function is called to release the kernel resources associated with the file; for thread locks, i.e., mutexes initialized by pthread_mutex_init, the pthread_mutex_destroy function is called to destroy the lock and release the resources it occupies, ultimately achieving standardized and unified cleanup of different types of resources.

[0053] When selecting a cleanup method based on resource type, the corresponding structure can be as follows: heap: free fd: close file: fclose lock: pthread_mutex_destroy.

[0054] In this embodiment, the release function is precisely matched according to the resource type, which completely avoids program crashes caused by mismatched release logic and ensures the security of resource cleanup; it combines a unified cleanup interface with differentiated release logic, simplifies the development process, reduces the probability of errors when manually writing release code; it covers core C language resource types, adapts to various business scenarios, is lightweight with no additional performance loss, and improves the long-term stability of the system.

[0055] In one optional embodiment of this application, the runtime resource manager includes runtime resource nodes, and the runtime resource nodes include RRNode structures that implement pointer lifetime tracking, reference counting management, and automatic garbage collection; the RRNode structure includes: Pointer address field, resource type field, reference count field, and release function pointer field.

[0056] It should be noted that the runtime resource manager is the core hub for implementing the full lifecycle management of raw pointers and resource handles, while the runtime resource node is the basic unit that carries the management data. Among them, the RRNode structure is the key carrier for the node to implement its core functions.

[0057] The RRNode structure contains four key components: a pointer address field that stores the original resource address corresponding to the raw pointer or resource handle, serving as a unique identifier for locating the underlying resource at runtime; a resource type field that marks the specific category of the resource, such as heap memory or file handles, providing a basis for matching release logic; a reference count field that records the number of pointers currently pointing to the resource in real time, serving as the core threshold for determining whether to trigger reclamation; and a release function pointer field that is pre-bound to the release function corresponding to the resource type, such as `free` or `fclose`, providing a direct execution entry point for unified cleanup operations. Through the organic integration of these four fields, the RRNode structure enables complete lifecycle tracking of resources from allocation, use, transfer to expiration, while supporting dynamic increase and decrease management of reference counts. Ultimately, this provides accurate data support for automatic reclamation, ensuring the orderly execution of all operations of the runtime resource manager.

[0058] In this embodiment, by constructing an RRNode structure, core resource management data can be integrated, providing a unified carrier for pointer lifecycle tracking, reference counting maintenance, and automatic garbage collection, thereby improving the standardization of resource management. The various fields work together efficiently, enabling rapid resource location and accurate release, avoiding problems such as dangling pointers and duplicate releases, and ensuring program stability. At the same time, the lightweight structure design has no additional performance or memory overhead, adapting to various C language engineering scenarios and reducing the cost of solution integration.

[0059] In one optional embodiment of this application, the system memory usage information includes memory usage rate; dynamically adjusting the memory reclamation frequency and strategy based on the memory usage information, and performing resource reclamation based on the pointer lifecycle state, includes: Based on memory usage, frequency reclamation scheduling data is generated. This data includes first and second frequency reclamation scheduling data. The first data is generated when memory usage is below a preset threshold, and the second data is generated when memory usage is not below the preset threshold. Based on pointer lifecycle status and frequency reclamation scheduling data, when the runtime detects that a raw pointer has entered an invalid state and the reference count in the corresponding runtime resource node is 0, the runtime resource manager calls the cleanup method corresponding to the raw pointer's associated resource to perform the corresponding resource reclamation.

[0060] Specifically, the dynamic resource reclamation mechanism uses system memory usage as the core adjustment criterion, combined with pointer lifecycle states to achieve intelligent, on-demand reclamation. First, a monitoring thread collects the key indicator of system memory usage in real time, serving as the core input for adjusting the reclamation strategy. Then, a two-way judgment is performed using a preset memory usage threshold, generating two different frequencies of reclamation scheduling data. When the memory usage is below the threshold, indicating sufficient system memory resources, a low-frequency first-frequency reclamation scheduling data is generated to reduce the impact of reclamation operations on the main program's running efficiency. When the memory usage is not lower than the threshold, indicating system memory pressure, a high-frequency second-frequency reclamation scheduling data is generated to prioritize the release of idle resources and alleviate memory pressure.

[0061] Specifically, when the scope of the target variable exits and triggers the cleanup hook function, the hook will first quickly find the corresponding resource's RRNode through the metadata of the proxy structure, and then call the release logic bound to that node. Only when the reference count (refcnt) of that node is 0, that is, when no pointer references the resource, will the actual resource reclamation operation be performed.

[0062] The runtime resource manager combines the frequency recycling scheduling data and pointer lifecycle status mentioned above to perform the recycling judgment process. Only when the two core conditions of "the raw pointer has expired" and "the reference count of the corresponding runtime resource node (RRNode) is 0, that is, no pointer is referencing the resource" are met, will the resource recycling operation be triggered according to the preset cleanup method to ensure that the recycling behavior is both efficient and safe and does not affect the normal use of resources.

[0063] In this embodiment, the recycling frequency is dynamically adjusted based on memory occupancy, balancing program running efficiency and memory release needs, and avoiding the drawbacks of rigid recycling. Furthermore, recycling is triggered by the dual conditions of pointer invalidation and reference count reaching 0, completely avoiding accidental and duplicate releases and ensuring program stability. Its scheduling logic is lightweight, with no additional performance loss, and is adaptable to various memory-sensitive scenarios, improving the long-term reliability of the system.

[0064] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0065] In another embodiment provided in this application, a pointer recycling system is also provided, which includes: a compile-time automatic instrumentation module, a runtime resource manager, and a lightweight proxy structure.

[0066] The compile-time automatic instrumentation module is used to: scan source code or abstract syntax tree, identify resource reference entry points and target variables that need to be managed, insert cleanup attributes and ownership transfer semantics into the target variables, and generate a resource description table; the target variables are storage carriers for raw pointers and resource handles; the resource description table includes resources and corresponding metadata; resource reference entry points are used to access resources; resource reference entry points include raw pointers.

[0067] The lightweight proxy structure is used to: wrap raw pointers and associate metadata through the lightweight proxy structure; the runtime resource manager is used to: register resources in the resource description table, manage reference counting, perform cross-function transfer migration and perform unified cleanup operations to obtain the pointer lifecycle state; collect system memory usage information in real time at runtime, dynamically adjust the memory reclamation frequency and strategy according to the memory usage information, and perform resource reclamation according to the pointer lifecycle state.

[0068] Please see Figure 4 As shown, Figure 4 This is a schematic diagram of the raw pointer lifecycle state machine provided in an embodiment of this application. The raw pointer is initially in the "Uninitialized" state, which is the default state after the raw pointer is declared. At this time, the pointer is only allocated variable storage space, but no valid memory address value is assigned. Its pointer is random and unpredictable. A typical example is char. `p;` declares a pointer `p`, but it is not initialized. After memory is allocated by `malloc` / `new`, it enters the "Allocated" state, meaning it has been allocated and points to valid memory. That is, when a developer calls memory allocation functions such as `malloc` / `calloc` / `realloc` (in C) or C++ to allocate heap memory for a raw pointer and returns the starting address of the valid memory, the pointer transitions from the "Uninitialized" state to the "Allocated" state. At this point, the pointer points to a legal and usable heap memory region, which is a prerequisite for a raw pointer to safely perform read and write operations. A typical example is `p = (char...)`. `malloc(128); p` points to 128 bytes of valid heap memory.

[0069] Subsequently, when reading and writing data via dereference, the pointer transitions to the "Using" state. When the raw pointer is in the "Allocated" state, the developer performs dereference on the pointer. When read and write operations such as p and member access (p->data) are performed, the pointer enters the "Using" state. This state is the core state for the raw pointer to perform data access functions, and it can repeatedly switch between "Allocated" and "Using" (i.e., multiple read and write operations are performed on the valid pointer). As long as the pointer is not reassigned or released, it will always remain a valid pointer.

[0070] If a pointer is reassigned to another memory location or passed back from a function, it enters the "Moved" state, meaning the memory ownership remains the same but the pointer's location changes. Calling `free` or `delete` puts it into the "Freeing" state, starting with "Freeing" and ending with "Freed". When memory resources are no longer needed, developers call memory release functions like `free` (C) or `delete` (C++) to release pointers in the "Allocated" or "Moved" state. The pointer first enters the "Freeing" state (during the release function execution), and then officially enters the "Freed" state after the release operation is complete. At this point, the heap memory that the pointer originally pointed to is reclaimed by the operating system and can be reallocated later, while the pointer itself retains its original memory address value, becoming an "invalid address marker".

[0071] If the original pointer loses its target after Move and there is no path to release it, it will enter "Leaked" (memory leak); if the pointer is used after Freed, it will become "Dangling" (dangling pointer); while manually setting it to NULL can make Freed return to "Uninitialized", it depends on the developer's active operation. Once overlooked, it will cause security problems such as memory leaks and program crashes. This is the pain point that traditional raw pointer management cannot completely solve.

[0072] Please see Figure 5 As shown, during the compile-time instrumentation phase, user code contains pointer usage logic and raw pointer variables, which are taken over by the compile-time instrumentation module during the compilation stage. This module first analyzes the abstract syntax tree (AST) of the user code, identifying key nodes such as raw pointer variables and resource allocation / release logic. Based on the analysis results, it automatically generates instrumentation code, such as binding the `cleanup` attribute to raw pointer variables and inserting ownership transfer flags, thus enhancing the management of the user code. The core of this phase is to pre-implant the necessary management flags and logic for raw pointers without changing the user's code usage habits, which forms the basis for subsequent runtime automatic management.

[0073] Furthermore, the instrumentation code generated during compilation works in conjunction with the runtime management system to achieve automated management of the entire lifecycle of raw pointers. First, a monitoring thread collects real-time data such as system memory usage to provide a basis for reclamation strategies. Then, the PointerRegistry receives the raw pointer information from the instrumentation code and completes runtime registration of resources and the creation of the RRNode structure. Next, the StateMachine automatically tracks the lifecycle states of raw pointers, such as allocation, usage, and transfer, based on the registration information, and synchronously maintains the reference count. Finally, the MemoryPool combines the data from the monitoring thread with the state machine's state to perform unified cleanup and reclamation operations. This entire runtime process automates and intelligently manages raw pointers, completely replacing the traditional manual management model.

[0074] This embodiment, through a collaborative mechanism of compile-time instrumentation and runtime automatic management, not only retains the native user experience of raw pointers in C language, but also fundamentally solves the problems of traditional manual management. Compile-time instrumentation enables non-intrusive implantation of management logic, eliminating the need for developers to modify their coding habits or learn new syntax, thus reducing development costs. The runtime system, through end-to-end automated processing of pointer registration, state tracking, and memory pool reclamation, completely avoids risks such as dangling pointers and memory leaks. At the same time, relying on monitoring threads to dynamically adjust the reclamation strategy, it balances program execution efficiency and memory stability, significantly improving the reliability and long-term robustness of C language programs. It is especially suitable for large projects and complex calling scenarios, significantly reducing the difficulty of later maintenance and debugging.

[0075] The aforementioned runtime resource manager includes: a pointer registration unit, a reference counting management unit, a cross-function migration unit, a cleanup unit, and an adaptive scheduling unit.

[0076] The pointer registration unit is used to: receive resources passed by the lightweight proxy structure, create and initialize the corresponding RRNode structure instance, and store it in the resource record table so that the managed resources can be registered and archived at runtime; the reference counting management unit is used to: update the reference count field in the RRNode structure in real time, maintain the increase and decrease of resource reference counts, and provide a counting basis to avoid duplicate or missed release of resources; the cross-function migration unit is used to: respond to the ownership transfer semantics of the ownership transfer flag, and migrate the reference count of the resource corresponding to the transfer location during cross-function transfer; the cleanup unit is used to: receive the reclamation control instruction, execute the corresponding release logic according to the release callback function bound to the RRNode structure, and perform the final cleanup and reclamation of resources; the adaptive scheduling unit is used to: dynamically adjust the memory reclamation frequency and strategy according to the system memory usage information collected by the monitoring thread, and output reclamation control instructions to drive the cleanup unit to execute resource reclamation.

[0077] Specifically, the pointer registration unit, acting as the management entry point, receives resource information packaged by a lightweight proxy structure. It creates and initializes a corresponding RRNode structure for each managed resource, filling in core data such as pointer address and resource type, and then stores it in a resource record table, completing runtime archiving of the resource and providing a basic data carrier for all subsequent management operations. The reference counting management unit, using the reference counting field of the RRNode structure as its core, performs real-time increment / decrement operations based on scenarios such as new and invalid references to accurately maintain resource reference relationships, providing crucial counting basis for determining whether a resource is reclaimable. The cross-function migration unit specifically responds to ownership transfer markers. During resource transfer across functions, the reference count migration between the transfer-out and transfer-in locations is automatically completed, i.e., the transfer-out end is decremented by 1 and the transfer-in end is incremented by 1, ensuring clear and conflict-free resource ownership. The cleanup unit, as the final execution carrier, receives the reclamation control instruction and directly calls the release callback function pre-bound to the RRNode structure to execute differentiated release logic according to resource type, completing the final cleanup of resources. The adaptive scheduling unit acts as the "decision center," dynamically adjusting the memory reclamation frequency and priority strategy based on the system memory usage information collected by the monitoring thread, while outputting precise reclamation control instructions to drive the cleanup unit to execute reclamation operations in an orderly manner, realizing intelligent management of "reclaiming on demand."

[0078] This embodiment achieves automated management of the entire resource lifecycle, completely avoiding problems such as dangling pointers, duplicate releases, and memory leaks, ensuring program stability; it also eliminates the need for manual maintenance of reference counting and garbage collection logic, reducing development costs and the probability of human error, and improving development efficiency; and it adopts a dynamic adjustment garbage collection strategy, taking into account both program running efficiency and memory utilization efficiency, adapting to various C language engineering scenarios; at the same time, it accurately releases resources according to resource type, achieving standardized management and reducing the difficulty of later maintenance.

[0079] In one embodiment, a computer device is provided, and the internal structure diagram of the communication terminal can be as follows: Figure 1As shown. The communication terminal includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory of the communication terminal includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and the database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the communication terminal stores data. The network interface of the communication terminal is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the pointer reclamation method described above. It includes: memory and a processor; the memory stores the computer program; and the processor, when executing the computer program, implements any step of the pointer reclamation method described above.

[0080] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, can perform any of the steps in the pointer reclamation method described above.

[0081] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0082] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0083] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The function specified in one or more boxes.

[0084] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0085] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0086] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A pointer recycling method, characterized in that, The pointer reclamation method includes: The compiler automatically instrumentes the source code or abstract syntax tree to identify the resource reference entry points and target variables that need to be managed. It then inserts cleanup attributes and ownership transfer semantics into the target variables and generates a resource description table. The target variables serve as storage carriers for the raw pointers and resource handles. The resource description table includes the resources and their corresponding metadata. The resource reference entry points are used to access the resources and include raw pointers. The raw pointer is wrapped using a lightweight proxy structure, and the metadata is associated with the lightweight proxy structure. The runtime resource manager performs registration, reference counting management, cross-function transfer migration, and unified cleanup operations on the resources in the resource description table to obtain the pointer lifecycle state. The system collects system memory usage information in real time during runtime, dynamically adjusts the memory reclamation frequency and strategy based on the memory usage information, and performs resource reclamation based on the pointer lifecycle state.

2. The pointer retrieval method according to claim 1, characterized in that, The resource reference entry also includes: a resource handle; the raw pointer and resource handle include at least one of the following: a heap memory pointer returned by the malloc / calloc / realloc function, a file handle returned by the fopen / open function, a system resource handle returned by the socket / pipe / pthread function, and a user-defined resource type marked with the __resource keyword.

3. The pointer retrieval method according to claim 2, characterized in that, Insert the cleanup attribute and ownership transfer semantics into the target variable, including: Insert the `cleanup` property, which binds an automatic cleanup function, into the target variable; When the raw pointer and resource handle carried by the target variable are passed across scopes through function return, the original return statement corresponding to the target variable is converted into a call form with ownership transfer flags to insert ownership transfer semantics.

4. The pointer retrieval method according to claim 1, characterized in that, The cross-function transfer includes: When calling the function for ownership migration marker, the resource reference count corresponding to the outgoing location is decremented by 1, and the resource reference count corresponding to the incoming location is incremented by 1 to obtain the updated resource reference count; When performing a cleanup operation in the original scope, the release operation of the resource is skipped based on the updated resource reference count.

5. The pointer retrieval method according to claim 1, characterized in that, The metadata includes: resource type, release callback, source location, and resource identifier; the unified cleanup operation includes: matching the corresponding release function based on the resource type to select the corresponding cleanup method; the resource type includes memory resources, file handles, file descriptors, and thread locks; Based on the resource type, a corresponding release function is matched, including: Call the `free` function for heap memory resources, the `fclose` function for file handles, the `close` function for file descriptors, and the `pthread_mutex_destroy` function for thread locks.

6. The pointer retrieval method according to claim 1, characterized in that, The runtime resource manager includes runtime resource nodes, which include RRNode structures that implement pointer lifetime tracking, reference counting management, and automatic garbage collection; the RRNode structure includes: Pointer address field, resource type field, reference count field, and release function pointer field.

7. The pointer retrieval method according to claim 6, characterized in that, The system memory usage information includes memory utilization rate; the memory reclamation frequency and strategy are dynamically adjusted based on the memory usage information, and resource reclamation is performed based on the pointer lifecycle state, including: Based on the memory occupancy rate, frequency reclamation scheduling data is generated; the frequency reclamation scheduling data includes first frequency reclamation scheduling data and second frequency reclamation scheduling data, wherein the first frequency reclamation scheduling data is generated when the memory occupancy rate is lower than a preset threshold; and the second frequency reclamation scheduling data is generated when the memory occupancy rate is not lower than the preset threshold. Based on the pointer lifecycle state and frequency reclamation scheduling data, when the runtime identifies that the raw pointer has entered an invalid state and the reference count in the corresponding runtime resource node is 0, the runtime resource manager calls the cleanup method corresponding to the raw pointer's associated resource to perform the corresponding resource reclamation.

8. A pointer retrieval system, characterized in that, The pointer recycling system includes: a compile-time automatic instrumentation module, a runtime resource manager, and a lightweight proxy structure; The compile-time automatic instrumentation module is used to: scan source code or abstract syntax tree, identify resource reference entry points and target variables that need to be managed, insert cleanup attributes and ownership transfer semantics into the target variables, and generate a resource description table; the target variables are the storage carriers for the raw pointers and resource handles; the resource description table includes resources and corresponding metadata; the resource reference entry points are used to access the resources; the resource reference entry points include raw pointers; The lightweight proxy structure is used to: wrap the raw pointer and associate the metadata through the lightweight proxy structure; The runtime resource manager is used to: register resources in the resource description table, manage reference counts, perform cross-function transfer migrations, and perform unified cleanup operations to obtain the pointer lifecycle state; The system collects system memory usage information in real time during runtime, dynamically adjusts the memory reclamation frequency and strategy based on the memory usage information, and performs resource reclamation based on the pointer lifecycle state.

9. The pointer retrieval system according to claim 8, characterized in that, The runtime resource manager includes: a pointer registration unit, a reference counting management unit, a cross-function migration unit, a cleanup unit, and an adaptive scheduling unit; The pointer registration unit is used to: receive resources passed by the lightweight proxy structure, create and initialize the corresponding RRNode structure instance, and store it in the resource record table so that the managed resources can be registered and archived at runtime. The reference count management unit is used to: update the reference count field in the RRNode structure in real time, maintain the increase or decrease of resource reference count, and provide a counting basis to avoid repeated or missed resource release; The cross-function migration unit is used to: respond to the ownership migration mark in response to ownership transfer semantics, and migrate the reference count of the resource corresponding to the transfer-out location during cross-function transfer; The cleanup unit is used to: receive recycling control instructions, execute the corresponding release logic according to the resource type based on the release callback function bound to the RRNode structure, and perform the final cleanup and recycling of resources; The adaptive scheduling unit is used to: dynamically adjust the memory reclamation frequency and strategy based on the system memory usage information collected by the monitoring thread, and output reclamation control instructions to drive the cleanup unit to perform resource reclamation.

10. A computer device, comprising: A memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method according to any one of claims 1 to 7.

Images