Computing device and method for identifying and grouping heap objects

Abstract

A computing device comprising memory and controller. The memory comprises stack and heap. The controller is configured to allocate memory space in memory for plurality of heap objects based on grouping of at least some of plurality of heap objects by receiving memory allocation call indicating object and size of allocation of memory, obtaining return address, obtaining stack pointer, generating a site allocation ID value based on a combination of the size of allocation, the return address and the stack pointer, determining if there is an allocation site group having the site allocation ID value, and if not generating an allocation site group having the site allocation ID value, and then adding the object to the allocation site group and allocating memory according to the allocation site group in the heap in the memory. Moreover, the objects in the same allocation site group are grouped in the heap.

Description

[0001] COMPUTING DEVICE AND METHOD FOR IDENTIFYING AND GROUPING HEAP OBJECTS

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to the field of memory management and, more specifically, to a computing device comprising a memory and a controller. Furthermore, the present disclosure relates more specifically to a method for the computing device for identifying and grouping heap objects.

[0004] BACKGROUND

[0005] Computer memory management is a critical aspect of modem computing systems, playing a vital role in the performance, efficiency, and security of software applications. As the complexity in the modem software systems continue to increase, the demands on memory management systems have grown significantly, necessitating the need of more sophisticated approaches to memory allocation and organization, such as by the use of heap memory. Various techniques have been developed to optimize the heap memory usage, such as the slab allocator, which divides memory pages into equal-sized objects to minimize fragmentation. However, many existing memory management techniques rely on simple allocation strategies that do not fully leverages the relationships between objects or the context in which the objects are created. Furthermore, one of the key challenges in optimizing heap memory management is the identification and grouping of objects originating from the same allocation site.

[0006] Certain attempts have been made to overcome the challenges in optimizing heap memory management, including retrieving function call chains, using stack predictors, and employing type-based allocators. Additionally, various stack predictors have been explored as identification points for grouping similar objects, including stack pointers, path points, and stack contents. However, such attempts often fail due to various reasons, such as runtime identification of allocation sites frequently introduces overhead due to code instrumentation or costly stack unwinding operations. Furthermore, conventional methods that rely on a singular allocation site identifier struggle to differentiate between objects allocated by disparate call chains, resulting in the same malloc location. Therefore, there exists a technical problem of how to efficiently allocate and organize heap objects in computer memory by performing clustering at runtime without any computational overhead while separating the objects with similar behavior accurately.

[0007] Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with conventional computing devices and conventional methods for the computing device for identifying and grouping heap objects.

[0008] SUMMARY

[0009] The present disclosure provides a computing device comprising a memory and a controller and a method for the computing device. The present disclosure provides a solution to the existing problem of how to efficiently allocate and organize heap objects in computer memory by performing clustering at runtime without any computational overhead while separating the objects with similar behavior accurately. An objective of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in the prior art and provides the computing device and the method for the computing device for identifying and grouping heap objects.

[0010] One or more objectives of the present disclosure are achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims.

[0011] In one aspect, the present disclosure provides a computing device comprising a memory and a controller. The memory comprises a stack and a heap, and the controller is configured to allocate memory space in the memory for a plurality of heap objects based on a grouping of at least some of the plurality of heap objects by receiving a memory allocation call indicating an object and a Size of Allocation (SoA) of memory, obtaining a Return Address (RA), obtaining a Stack Pointer (SP), generating a Site Allocation ID value based on a combination of the Size of Allocation (SoA) of memory, the Return Address (RA), and the Stack Pointer (SP), determining if there is an Allocation Site Group having the Site Allocation ID value, and if not generating an Allocation Site Group having the Site Allocation ID value, and then adding the object to the Allocation Site Group and allocating memory according to the Allocation Site Group in the heap in the memory, wherein objects in the same Allocation Site Group are grouped in the heap.

[0012] Advantageously, the controller is configured to generate the site allocation ID in order to ensure that the objects with similar characteristics are grouped together with reduced fragmentation for improving the memory utilization. The controller tracks and optimizes memory deallocation while reducing memory leaks for enhancing the overall cache management locally in order to access the frequently used data. The allocation strategy further reduces the memory fragmentation, such as by placing the memory objects from the same site together and improving the overall performance of the computing device, especially in long-running applications. Furthermore, by monitoring the SoA, RA, and SP, the controller implements security measures to prevent vulnerabilities, such as buffer overflows and use-after-free errors thereby, ensuring safe memory allocation and reuse. The controller is also configured to manage memory paging efficiently, such as by using algorithms, for example, LRU and FIFO in order to optimize the overall memory utilization and stores the required data in RAM while paging out less critical data. As a result, such dynamic and adaptive computing device continuously analyzes the memory demands thereby, allowing the controller to efficiently allocate and deallocate memory in real-time, ensuring scalability and optimal performance.

[0013] In another aspect, the present disclosure provides a method for a computing device comprising a memory and a controller. The memory comprises a stack and a heap and the controller is configured to allocate memory space in the memory for a plurality of heap objects based on a grouping of at least some of the plurality of heap objects. The method comprises receiving a memory allocation call indicating a Size of Allocation (SoA) of memory, obtaining a Return Address (RA), obtaining a Stack Pointer (SP), generating a Site Allocation ID value based on a combination of the Size of Allocation (SoA) of memory, the Return Address (RA), and the Stack Pointer (SP). Further, the method comprises determining if there is an Allocation Site Group having the Site Allocation ID value, and if not generating an Allocation Site Group having the Site Allocation ID value, and then adding the object to the Allocation Site Group and allocating memory according to the Allocation Site Group in the heap in the memory, wherein objects in the same Allocation Site Group are grouped in the heap.

[0014] The method achieves all the advantages and technical effects of the method of the computing device.

[0015] It is to be appreciated that all the aforementioned implementation forms can be combined.

[0016] It has to be noted that all devices, elements, circuitry, units, and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application, as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity that performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements or any kind of combination thereof. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims. Additional aspects, advantages, features, and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative implementations construed in conjunction with the appended claims that follow.

[0017] BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

[0019] Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

[0020] FIG. 1 is a block diagram that illustrates a computing device for identifying and grouping heap objects, in accordance with an embodiment of the present disclosure;

[0021] FIG. 2 is a flowchart that illustrates a method for identifying and grouping heap objects, in accordance with an embodiment of the present disclosure; and

[0022] FIG. 3 is a flowchart that illustrates handling of allocation site data, in accordance with an embodiment of the present disclosure.

[0023] In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the non-underlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.

[0024] DETAILED DESCRIPTION OF EMBODIMENTS

[0025] The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible.

[0026] FIG. 1 is a block diagram that illustrates a computing device for identifying and grouping heap objects, in accordance with an embodiment of the present disclosure. With reference to FIG. 1, there is shown a diagram 100, which includes a computing device 102. The computing device 102 further includes a controller 104, a memory 106.

[0027] The computing device 102 refers to a functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations without human intervention. The computing device 102 may consist of a standalone unit or several interconnected units. Furthermore, the computing device 102 may consist of a device that provides a specific set of functions, such as a phone or a personal organizer, or more general functions such as a laptop or desktop computer.

[0028] The controller 104 is configured to receive memory allocation calls, specifying the size of memory required for an object. Moreover, the controller 104 is configured to retrieve specific data, such as the Return Address (RA), Stack Pointer (SP), Size of Allocation (SoA), and the like. Furthermore, based on the retrieved data, the controller 104 is configured to generate a site allocation ID that uniquely identifies the allocation site. The controller 104 is further configured to check for an existing allocation site group associated with the site allocation ID in the heap. If no allocation site group is associated with the site allocation ID, the controller 104 is configured to create a new allocation site group in the heap llO.Examples of the controller 104 include, but are not limited to an integrated circuit, a co-processor, a microprocessor, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a very long instruction word (VLIW) processor, a central processing unit (CPU), a state machine, a data processing unit, and other processors or circuits. Moreover, the controller 104 may refer to one or more individual processors, a processing unit that is part of a machine. The controller 104 is configured to control the execution, ordering and validation of the transactions that are performed in the computing device 102.

[0029] The memory 106 includes suitable logic, circuitry, and / or interfaces that are configured to store the instructions executable by the memory controller. Examples of implementation of the memory 106 may include, but are not limited to, Electrically Erasable Programmable Read-Only Memory (EEPROM), Dynamic Random-Access Memory (DRAM), Random Access Memory (RAM), Read-Only Memory (ROM), Elard Disk Drive (1TDD), Flash memory, a Secure Digital (SD) card, Solid-State Drive (SSD), and / or CPU cache memory. The memory 106 of the computing device 102 further includes stack 108 and heap 110.

[0030] The stack 108 refers to a region of the memory 106 in the computing device 102 where data is added and removed in a last-in- first-out (LIFO) manner. The stack 108 is primarily used to store temporary data such as function call frames, local variables, and function parameters. Moreover, the stack 108 is configured to operate in communication with the controller 104 in the computing device 102 to manage the flow of data during program execution, ensuring that each function call is correctly tracked and handled within the execution flow of a program.

[0031] The heap 110 refers to a large area of the memory 106 that can be used to store and access data during the execution of any process. Unlike the stack 108, which follows a Last-In-First-Out (LIFO) structure, the heap 110 allows for dynamic memory allocation, meaning that the memory 106 can be allocated and deallocated as needed at runtime. In the heap 110, the memory 106 is not automatically managed, user needs to manually allocate and free the memory 106 from the heap 110 using various functions like malloc () for allocation and free () for deallocation.

[0032] There is provided the computing device 102 comprising the memory 106 and the controller 104. The computing device 102 is configured to address various challenges in memory management with conventional computing devices, such as fragmentation, inefficient usage, security vulnerabilities, and the like by introducing an additional memory or CPU overhead or by providing additional compilation instrumentation.

[0033] Furthermore, the memory 106 comprises the stack 108 and the heap 110. The stack 108 is used for short-term, temporary storage, handling function calls, local variables, and function parameters. The heap 110 is responsible for dynamic memory allocation, storing data structures and objects with a longer lifespan that are created and destroyed during runtime. The controller 104 is configured to manage both the stack 108 and the heap 110 to ensure efficient memory usage. Moreover, the controller 104 is further configured to retrieve information from the stack 108 to generate the RA and the SP values, which are critical in identifying where objects originate. Also, the controller 104 is configured to handle memory allocation in the heap 110, ensuring that objects are properly grouped and stored based on the allocation site of the respective objects.

[0034] In accordance with an embodiment, the memory 106 comprises a site allocation list of site allocation ID values and associated allocation sites. The allocation site refers to the specific memory region in the heap 110 where objects corresponding to that site allocation ID are stored. Moreover, the allocation site is configured to map each site allocation ID to the respective location in the heap 110, enabling the controller 104 to organize and track heap objects effectively. In an implementation, when the memory allocation request is made, the controller 104 is configured to generate the site allocation ID based on the SoA, the RA, and the SP. The site allocation ID is then stored in the site allocation list in the memory 106. Thus, the site allocation list allows the system to group heap objects that share the same site allocation ID into the same allocation site in the heap 110.

[0035] In accordance with an embodiment, the controller 104 is further configured to determine if there is an allocation site having the Site Allocation ID value by checking the site allocation list. Initially, the controller 104 is configured to retrieve the site allocation ID generated from the current memory allocation request. Further, the controller 104 is configured to access the site allocation list stored in the memory 106, which contains entries mapping existing site allocation ID values to their corresponding allocation sites in the heap 110. Upon accessing the site allocation list, the controller 104 checks for a match with the current allocation ID. If a match is found, the controller 104 confirms the existence of an allocation site associated with that ID. If no match is present in the site allocation list, the controller 104 concludes that a new allocation site must be created for the current memory request, thereby improving memory organization and management by grouping similar objects together in the heap 110.

[0036] Furthermore, the controller 104 is configured to allocate memory space in the memory 106 for a plurality of heap objects based on a grouping of at least some of the plurality of heap objects. Initially, the controller 104 is configured to receive a memory allocation call indicating the size of the memory required for the object. The controller 104 is further configured to retrieve information from the computing device 102, such as the RA and the SP, which helps to uniquely identify where the memory allocation request originated. Based upon such information, the controller 104 is configured to generate a site allocation ID, which serves as a unique identifier for the memory allocation site. Moreover, by using the site allocation ID, the controller 104 is configured to determine whether any allocation site group is associated with the site allocation ID. If such a group exists, the new object is added to that allocation site group, and if no such group exists, the controller 104 is configured to create a new allocation site Group, grouping objects based on respective allocation origin and behaviour. Thus, the grouping of at least some of the plurality of heap objects ensures that the memory in the heap 110 is used efficiently, reducing fragmentation and improving memory reuse.

[0037] Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes receiving a memory allocation call indicating an object and the SoA of the memory 106. In an implementation, when the memory allocation call is received, the controller 104 is configured to extract the SoA, which represents the size of memory required for the object. The SoA is determined based on the type or structure of the object and how much memory the object needs for storage. Moreover, once the SoA is determined, the controller 104 is configured to retrieve the additional data, such as the RA and the SP to create the Site Allocation ID, which is used to group objects that originate from the same or similar allocation sites. By receiving the exact SoA for each object, the controller 104 ensures that memory is allocated precisely as needed, avoiding the overuse of memory resources.

[0038] In accordance with an embodiment, the memory allocation call is associated with a function call, and the return address is for that function call. Initially, when a function in the program requests memory allocation, the RA for the function call is stored in the call stack. Further, when the memory allocation request is made, the computing device 102 is configured to capture the RA and associate the RA with allocation. The controller 104 is configured to retrieve the RA and use the RA along with other key data, such as the SoA and the SP to generate a unique site allocation ID. By associating memory allocations with the RA of the function call, the controller 104 can accurately track the source of each memory request.

[0039] Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes obtaining the RA. The RA refers to the location in the memory 106 that holds the instruction where the control should return once the function call completes. In an implementation, when the memory allocation is requested by the function, the controller 104 is configured to generate a memory allocation call. Furthermore, once the memory allocation call is generated, the controller 104 is configured to retrieve the RA, which is saved on the call stack to generate a unique site allocation ID. The Site Allocation ID is further used to group the objects that are allocated from the same or similar allocation sites, thereby ensuring that the objects with similar origin are placed together in the heap 110, optimizing both memory usage and performance of the computing device 102.

[0040] In accordance with an embodiment, the controller 104 is further configured to obtain the RA via the stack 108. In an implementation, when the function in the program requests memory allocation, the stack 108 is configured to automatically store the RA for the function call. The controller 104 is further configured to access the stack 108 to retrieve the RA during the memory allocation process by reading the top of the stack 108, where the RA is stored along with other function-related information. By retrieving the RA from the stack 108, the controller 104 ensures that memory allocation requests are linked to the specific function calls that initiated the function.

[0041] In accordance with an embodiment, the RA is obtained through a command: void * builtin return address (unsigned int level) when the function relates to a GNU Compiler Collection (GCC) built application. The command void * builtin return address (unsigned int level) refers to a built-in function provided by GCC that allows the program to retrieve the RA for a specific function call level in the call stack. The level parameter of the built-in function indicates the depth of the function call stack, with level 0 returning the RA for the current function and higher levels returning RAs for the calling functions in the stack 108. By obtaining the RA directly from the function stack frame using the built-in function, the controller 104 ensures precise tracking of where memory allocation requests originate.

[0042] Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes obtaining the SP. The SP refers to a specialized register that holds the memory address of the most recent entry, or top, of the call stack. The SP is utilized during the allocation of memory space in the heap 110 to improve the organization and grouping of heap objects. The SP, in combination with other elements such as the RA and the SoA, is used to generate a site allocation ID. By incorporating the SP along with other elements like the RA and the SoA, the controller 104 is configured to generate the unique site allocation ID that reflects the precise context of each memory request.

[0043] In accordance with an embodiment, the controller 104 is further configured to obtain the SP via the stack 108. Every time the function is called, the stack 108 is configured to grow, and a new stack frame is created for the function. The SP is updated to point to the top of the stack, marking the beginning of the stack frame of the current function. Furthermore, the controller 104 is configured to retrieve the SP from the stack 108 using built-in functions provided by the compiler. In an example, the controller 104 may retrieve the SP from the stack 108 using the function builtin frame address () that returns the current SP. By obtaining the SP, the controller 104 can accurately track the state of the current function and where the current function is located in the call stack.

[0044] Furthermore, the process of minimizing the performance impact of object identification focuses on efficiently retrieving the RA, the SP, and the SoA using dedicated functions. For applications built with GCC, the return address can be accessed using void * builtin return address (unsigned int level), while the SP can be retrieved by accessing the SP register content or obtaining the address of a local variable. The SoA refers to the input parameter passed to malloc () by the application. The computing device 102 facilitates identifying heap objects allocated from the same location in application code, anticipating that such objects will exhibit similar behavior and allowing the memory allocator to group them effectively. The identification of the heap objects allocated from the same location in the application code enhances the memory management efficiency, improved security, and optimized heap object placement, ultimately resulting in a more effective and responsive computing environment.

[0045] Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes generating the site allocation ID value based on a combination of the SoA of memory, the RA, and the SP. Initially, the memory allocation call is made, specifying the SoA, which indicates how much memory is required for the object. Further, the controller 104 is configured to receive the RA from the call stack, which provides the location in the code where the allocation request originated. Additionally, the SP is retrieved to provide further context about the position of the function in the call stack during the allocation. The controller 104 is further configured to combine the elements such as the SoA, the RA, and the SP to create the site allocation ID. Advantageously, the generation of the site allocation ID ensures that the objects with similar characteristics are grouped together in the heap 110, thereby reducing the memory fragmentation. Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes determining if there is the allocation site group having the site allocation ID value and, if not, generating the allocation site group having the site allocation ID value. After generating the site allocation ID, the controller 104 is configured to check if there is already an allocation site group with the same site allocation ID in the heap 110. If the allocation site group exists, the controller 104 is configured to add the new object to the allocation site group. Adding the new object to the allocation site group ensures that objects with the same allocation site group characteristics are stored together, improving memory efficiency and access performance of the computing device 102. If no allocation site group exists, the controller 104 is configured to generate a new group using the site allocation ID to store objects that share the same origin, size, and stack context, providing an organized structure for future memory allocation requests.

[0046] Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes generating an allocation site group having the site allocation ID value. In an implementation, after determining that there is no existing allocation site group with the site allocation ID, the controller 104 is configured to generate the new allocation site group. The new allocation site group serves as a container for the heap objects that originate from the same code location, shares the same allocation size, and are part of the same function call stack. Furthermore, once the allocation site group is created, any subsequent memory allocation requests that have the same site allocation ID will be assigned to the allocation site group having the site allocation ID value. The site allocation ID value refers to a unique identifier generated by the controller 104 during the memory allocation process to organize heap objects in a way that optimizes memory management. The objects in the allocation site group are stored together in the heap 110, ensuring that memory is used efficiently and organized logically.

[0047] In accordance with an embodiment, the controller 104 is further configured to generate the site allocation ID value by applying a hash function to the combination of the SoA, the RA, and the SP. The controller 104 is configured to use a hash function, that is a mathematical operation, which transforms the input values (i.e., the SoA, the RA, and the SP) into a fixed-size output that is the hash value. The hash value is considered as the site allocation ID. The hash functions are highly sensitive to input changes, meaning even a small difference in the SoA, the RA, or the SP to produce a completely different hash value, ensuring that each site allocation ID is unique for different allocation sites.

[0048] Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes adding the object to the allocation site group. In an implementation, after determining that there exist the allocation site group, the controller 104 is configured to add the newly allocated object to the existing allocation site group. Furthermore, the newly allocated object is stored alongside other objects that share the same characteristics, such as size and origin in the program, thereby ensuring that related objects are kept together in the heap 110, allowing for more efficient memory management and easier deallocation when necessary.

[0049] Furthermore, the allocation of memory space in the memory 106 for a plurality of heap objects includes allocating memory according to the allocation site group in the heap 110 in the memory 106. The allocation of memory is executed according to allocation site group in the heap 110 by grouping heap objects based on a site allocation ID and placing them together in the memory 106. Allocating memory based on allocation site groups ensures that objects are stored together in a way that reduces scattering, which can lead to memory fragmentation.

[0050] Furthermore, the objects in the same allocation site group are grouped in the heap 110. Once the group is identified or created, the objects belonging to the same allocation site group are physically grouped together in a specific region of the heap 110. By grouping objects that share the same site allocation ID, the computing device 102 minimizes memory fragmentation and maximizes memory reuse. In accordance with an embodiment, the controller 104 is further configured to perform memory management optimizations based on the combination of the SoA, the RA, and the SP. The SoA allows the controller 104 to allocate the exact amount of memory needed, preventing both over-allocation and under-allocation of the memory 106. The RA and the SP allows the controller 104 to group related memory allocations, thereby improving cache locality and reducing fragmentation. By virtue of combining the SoA, the RA, and the SP, the controller 104 is configured to implement strategies such as grouping related allocations to improve cache performance, minimizing fragmentation by ensuring that similarly sized allocations are placed close together, and thereby ensuring efficient deallocation by keeping track of object lifetimes and usage patterns of the object.

[0051] In accordance with an embodiment, the controller 104 is further configured to perform security enhancements based on the combination of the SoA of the memory 106, the RA, and the SP. The SoA is configured to provide information about how much memory is needed for the object, allowing the memory manager or the controller 104 to allocate the appropriate amount of space. The RA is configured to provide information about which function initiated a memory allocation request and the SP is configured to provide information about which function is currently executing and the state of its local variables and parameters, helping maintain the execution context. Based on the combined information from the SoA, the RA, and the SP, the controller 104 is configured to implement various security measures, such as ensuring that the memory allocations do not exceed expected limits, enhancing memory security by randomizing the memory addresses used for allocations, keeping track of memory allocation lifetimes and ensuring that freed memory cannot be accessed, thus reducing the risk of use-after-free vulnerabilities in the memory 106.

[0052] In accordance with an embodiment, the controller 104 is further configured to perform paging and / or memory use based on the combination of the SoA of the memory 106, the RA, and the SP. In an implementation, the controller 104 is configured to implement a page replacement strategy to determine which page should be swapped out of random-access memory (RAM). In an example, the controller 104 may use the least recently used (LRU) algorithm to swap out pages that have not been accessed for the longest time, based on access patterns inferred from the RA and SP. In another example, the controller 104 may use the first in, first out (FIFO) algorithm to remove the oldest pages in the memory 106, regardless of access patterns. In yet another example, the controller 104 may use an optimal page replacement algorithm to predict which pages will not be used for the longest period in the future. Furthermore, the controller 104 is configured to identify less frequently used or irrelevant pages in the memory 106 and writes the irrelevant pages to a secondary storage like a hard drive or SSD to free up space to perform the paging out function. Simultaneously, controller 104 is configured to load the required pages into RAM to perform paging in function. By incorporating the SoA, the RA, and the SP into the paging and the memory use decisions, the controller 104 enhances the overall efficiency of memory management, ensuring that resources are used optimally.

[0053] Advantageously, the controller 104 is configured to generate the site allocation ID in order to ensure that the objects with similar characteristics are grouped together with reduced fragmentation for improving the memory utilization. The controller 104 tracks and optimizes memory deallocation while reducing memory leaks for enhancing the overall cache management locally in order to access the frequently used data. The allocation strategy further reduces the memory fragmentation, such as by placing the memory objects from the same site together and improving the overall performance of the computing device 102, especially in long-running applications. Furthermore, by monitoring the SoA, RA, and SP, the controller implements security measures to prevent vulnerabilities, such as buffer overflows and use-after-free errors thereby, ensuring safe memory allocation and reuse. The controller 104 is also configured to manage memory paging efficiently, such as by using algorithms, for example, LRU and FIFO in order to optimize the overall memory utilization and stores the required data in RAM while paging out less critical data. As a result, such dynamic and adaptive computing device continuously analyzes the memory demands thereby, allowing the controller 104 to efficiently allocate and deallocate the memory 106 in real-time, ensuring scalability and optimal performance. FIG. 2 is a flowchart that illustrates a method for the computing device, in accordance with an embodiment of the present disclosure. FIG. 2 is described in conjunction with elements from FIG. 1. With reference to FIG. 2, there is provided a flowchart of a method 200 method for the computing device 102. The method 200 includes steps 202 to 216.

[0054] There is provided the method 200 for the computing device 102 comprising the memory 106 and the controller 104. The method 200 refers to operations performed by the computing device 102, which includes the memory 106 and the controller 104. Furthermore, the method 200 enables the controller 104 to manage memory allocation and memory usage efficiently by utilizing information such as the SoA, the RA, and the SP. Moreover, the method 200 enables the controller 104 to ensure that objects are grouped together based on respective allocation characteristics, thereby minimizing fragmentation and improving the performance of the memory 106. Additionally, the method 200 is configured to handle memory optimization, memory deallocations and implements security measures to prevent issues like buffer overflows, enhancing the overall integrity of the computing device 102.

[0055] Furthermore, the controller 104 is configured to allocate memory space in the memory 106 for the plurality of heap objects based on the grouping of at least some of the plurality of heap objects. The controller 104 is configured to identify certain criteria for grouping heap objects, which could be based on attributes like size, allocation site, or the function calls that created the heap objects. Furthermore, the controller 104 is configured to retrieve the information about existing groups of the heap objects, including the respective site allocation IDs. Moreover, when the controller 104 receives a memory allocation request for multiple objects, the controller 104 uses the grouping information to allocate the multiple objects with the space in the memory 106 in a manner that keeps related objects together, leading to improved memory efficiency, performance, and simplified memory management in the computing device 102.

[0056] At step 202, the method 200 includes receiving the memory allocation call indicating the SoA of the memory 106. The SoA specifies the amount of memory required for the object. By knowing the exact space required, the controller 104 can allocate the appropriate amount of memory to the object, avoiding both over-allocation and under-allocation, which can lead to the reduction of memory errors like overflows or fragmentation.

[0057] At step 204, the method 200 includes obtaining the RA. The RA is configured to track where the execution should resume after a function call by storing the memory address of the instruction following the function call on the call stack. The RA accurately points to the code location and is responsible for the memory allocation. However, the RA is unable to differentiate between different call paths leading to the same function (for e.g., main()->function2() vs main()->functionl()->function2()), which can cause issues when managing memory allocations based on specific call contexts. In order to overcome such issues, the controller 104 is configured to combine the RA with the SP to track the call stack depth and function origin and provides more detailed context about how a function was invoked, enabling better memory allocation management.

[0058] At step 206, the method 200 includes obtaining the SP. The SP refers to the memory address of the last item placed onto the call stack, essentially marking the top of the stack 108. The value of the SP changes based on various parameters such as the function call chain, the parameters passed to functions, and the local variables stored in the stack frame of each function. As the functions are invoked and respective data is pushed onto the stack 108, the SP is adjusted to reflect the current state of the stack 108, helping to manage memory and track function execution flow.

[0059] At step 208, the method 200 includes generating the site allocation ID value based on the combination of the SoA of the memory 106, the RA, and the SP. The SoA refers to the amount of memory requested by an application for particular object. Further, the SoA serves as a distinguishing feature that can influence the behaviour of the objects, even if the objects may originate from the same source code or have been invoked by the same sequence of functions. Variations in the SoA can affect how objects are stored, managed, and accessed in the memory 106, potentially impacting performance, memory fragmentation, and the overall behavior of the computing device 102. Initially, the SoA is extracted from the memory allocation request, providing the size of the memory block as needed. Further, the RA is retrieved from the call stack to identify the location in the code that requested the memory 106. Moreover, the SP is obtained to provide further context about the function call that initiated the allocation. Finally, the obtained values of the SoA, the RA, and the SP are combined, potentially using a hashing algorithm, to generate the Site Allocation ID.

[0060] At step 210, the method 200 includes determining if there is an allocation site group having the site allocation ID value. In an implementation, the controller 104 is configured to generate the site allocation ID based on several parameters such as the SoA, the RA and the SP. The site allocation ID uniquely identifies the characteristics of the current memory allocation request. Furthermore, the controller 104 is configured to check the site allocation list stored in the memory 106, which contains mappings between existing site allocation ID values and corresponding allocation site groups. Moreover, if an allocation site group corresponding to the generated site allocation ID is found, the controller 104 confirms that a suitable group already exists, but when no match is found, the controller 104 determines that a new allocation site group needs to be created. Thus, by determining whether a suitable allocation site group already exists, the controller 104 ensures that memory objects with similar characteristics are grouped together, reducing fragmentation and improving overall memory efficiency.

[0061] At step 212, the method 200 includes generating an allocation site group having the site allocation ID value. When the allocation site group corresponding to the generated site allocation ID is not found, then the controller 104 creates a new allocation site group. Furthermore, the controller 104 ensures that memory objects corresponding to the site allocation ID are allocated within the newly generated allocation site group, leading to more structured and organized memory usage. Additionally, grouping memory objects based on the site allocation ID improves cache locality, allowing for faster access to related objects.

[0062] At step 214, the method 200 includes adding the object to the allocation site group. In an implementation, when the correct allocation site group is created or generated, the controller 104 is configured to add the newly allocated object to the group. The memory for the object is allocated within the designated region associated with the site allocation ID, ensuring that the object is stored together with other objects that share similar characteristics. After adding the object to the allocation site group, the controller 104 updates the site allocation list and other internal memory management structures to reflect the newly added object. Therefore, adding the newly allocated objects to allocation site groups ensures that related objects are stored together, leading to better memory organization and reducing the likelihood of fragmentation.

[0063] At step 216, the method 200 includes allocating memory according to the allocation site group in the heap 110 in the memory 106. The memory is allocated according to allocation site groups in the heap 110 by generating a site allocation ID, checking or creating an appropriate allocation site group, and placing the memory in the designated region in the heap 110, ensuring organized, efficient, and optimized memory usage.

[0064] Advantageously, the method 200 manages the memory allocation for the computing device 102 efficiently by grouping related memory objects based on the SoA, the RA and the SP. Also, the grouping of related memory objects based on the SoA, the RA and the SP minimizes the memory fragmentation and improves the performance of the computing device 102 by ensuring that objects with similar characteristics are stored together in the heap 110 of the memory 106. Further, by organizing the objects into the allocation site groups, the method 200 is configured to optimize the memory usage and enhance cache locality, leading to a faster memory access. Additionally, the method 200 is configured to address the security concerns like buffer overflows by incorporating detailed context into memory allocation decisions. The controller 104 is configured to use the generated site allocation ID to check for an existing group can accommodate the new objects, creating a new group if necessary, ensuring efficient memory organization. Moreover, the method 200 is configured to simplify the memory management by keeping related objects together, reducing fragmentation, and facilitating better memory reuse. As a result, the performance and scalability of the computing device 102 is enhanced, thereby supporting an optimized and organized memory management in dynamic environments. The combined processing also ensures that the method 200 enables the computing device 102 to handle memory efficiently, improve the integrity of the computing device 102, and maintain organized memory allocation, thereby managing complex memory demands.

[0065] The steps 202 to 216 are only illustrative, and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

[0066] There is further provided a computer program product comprising program instructions for performing the method 200 when executed by one or more processors in the computing device 102. The computer program product is implemented as an algorithm, embedded in a software stored in a non-transitory computer-readable storage medium. The non-transitory computer- readable storage means may include, but are not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. Examples of implementation of computer-readable storage medium, but are not limited to, Electrically Erasable Programmable Read-Only Memory (EEPROM), Random Access Memory (RAM), Read Only Memory (ROM), Elard Disk Drive (EfDD), Flash memory, a Secure Digital (SD) card, Solid-State Drive (SSD), a computer-readable storage medium, and / or CPU cache memory.

[0067] FIG. 3 is a flowchart that illustrates handling of allocation site data, in accordance with an embodiment of the present disclosure. FIG. 3 is described in conjunction with elements from FIG. 1 to 2. With reference to FIG. 3, there is provided a diagram 300 includes a flowchart for handling of allocation site data in the computing device 102. The flowchart includes operations 302 to 316.

[0068] At operation 302, an application initiates the memory allocation request by calling the malloc () function, indicating the need for a certain amount of memory, which is passed to the memory allocator for further processing. In an implementation, the memory allocator can be the controller 104.

[0069] At operation 304, the memory allocator is configured to receive the memory allocation request from the application. The memory allocator acts as an intermediary between the application and kernel, handling how and where the memory will be allocated in the computing device 102.

[0070] At operation 306, the memory allocator is configured to retrieve key information, including the RA, the SP, and the SoA. The RA, the SP, and the SoA are then combined and processed, likely using a hashing algorithm, to generate a unique identifier, referred to as the hash value. The unique identifier helps distinguish between different memory allocation requests, even if they come from the same function or source code.

[0071] At operation 308, the memory allocator is configured to search for internal structures to check if the generated hash value alreadv exists. The internal structures are configured to store previously allocated memory blocks with the associated allocation characteristics. If a matching hash value is found, the memory allocator is configured to group the new allocation request with the existing group.

[0072] At operation 310, the memory allocator is configured to check whether the allocation site corresponding to the generated hash value already exists, which involves determining if a suitable group has already been formed for similar allocation requests based on the hash value.

[0073] At operation 312, when no existing allocation site group is found, the memory allocator creates a new allocation site group. The newly created allocation group serves as a container for memory objects that share similar characteristics, such as size, source, or function calls. The memory allocator is also configured to store the new group in its internal structures for future use.

[0074] At operation 314A, when the hash value matches an existing allocation site group, the new object is added to the existing allocation site group. By adding the new object to the existing allocation site group, the memory allocator ensures that memory objects with similar characteristics are grouped together, thereby enhancing the memory efficiency and minimising fragmentation.

[0075] At operation 314B, once an object is assigned to an allocation site group, the memory allocator applies specific logic tailored to that allocation site group. The specific logic may include strategies for optimizing memory access, improving cache locality, or managing deallocations, thereby ensuring that memory is used efficiently based on the characteristics of the allocation site group.

[0076] At operation 316, the memory allocator is configured to allocate the memory space in the heap 110 for the object according to the characteristics of the allocation site group to which the object belongs. The memory allocation happens in the heap 110, and related objects are placed together, improving access times, reducing fragmentation, and ensuring efficient use of memory resources.

[0077] Advantageously, the memory allocation by dynamically requesting memory optimizes the overall resource utilization. The memory allocator serves as an intermediary, managing communication between the application and the kernel, thereby improving the modularity of the process. By using key information, such as the Return Address, Stack Pointer, and Source of Allocation, the memory allocator creates a unique hash value for each request, thereby efficiently distinguishing and tracking memory allocations. Moreover, by checking internal structures for existing hash values, the memory allocator is configured to identify previously allocated memory, promoting effective reuse and preventing redundancy while maintaining consistent allocation site groups. When no existing group is found, a new allocation site group is created to organize memory management, ensuring that memory objects with similar characteristics are grouped together. Adding objects to existing groups minimizes fragmentation, while the specific logic applied optimizes memory access and cache locality. Additionally, the memory is allocated in the heap 110 based on group characteristics, enhancing access times and ensuring efficient memory resource utilization, ultimately benefiting application execution and improving the overall performance of the computing device 102.

[0078] Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as "including", "comprising", "incorporating", "have", "is" used to describe and claim the present disclosure are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural. The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or to exclude the incorporation of features from other embodiments. The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". It is appreciated that certain features of the present disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as suitable in any other described embodiment of the disclosure.

Claims

CLAIMS1. A computing device (102) comprising a memory (106) and a controller (104), wherein the memory (106) comprises a stack (108) and a heap (110), and wherein the controller (104) is configured to allocate memory space in the memory (106) for a plurality of heap objects based on a grouping of at least some of the plurality of heap objects by: receiving a memory allocation call indicating an object and a Size of Allocation (SoA) of memory, obtaining a Return Address (RA), obtaining a Stack Pointer (SP), generating a Site Allocation ID value based on a combination of the Size of Allocation (SoA) of memory, the Return Address (RA), and the Stack Pointer (SP), determining if there is an Allocation Site Group having the Site Allocation ID value, and if not generating an Allocation Site Group having the Site Allocation ID value, and then adding the object to the Allocation Site Group and allocating memory according to the Allocation Site Group in the heap (110) in the memory (106), wherein objects in the same Allocation Site Group are grouped in the heap (110).

2. The computing device (102) according to claim 1, wherein the controller (104) is further configured to generate the Site Allocation ID value by applying a hash function to the combination of the Size of Allocation (SoA) of the memory (106), the Return Address (RA), and the Stack Pointer (SP).

3. The computing device (102) according to any preceding claim, wherein the memory allocation call is associated with a function call, and wherein the return address is for that function call.

4. The computing device (102) according to any preceding claim, wherein the controller (104) is further configured to obtain the Return Address (RA) via the stack (108).

5. The computing device (102) according to claim 4, wherein the Return Address is obtained through a command: void * builtin return address (unsigned int level) when the function relates to a GCC built applications.

6. The computing device (102) according to any preceding claim, wherein the controller (104) is further configured to obtain the Stack Pointer (SP) via the stack (108).

7. The computing device (102) according to any preceding claim, wherein the memory (106) comprises a site allocation list of Site Allocation ID values and associated Allocation Sites, and wherein the controller (104) is further configured to determine if there is an Allocation Site having the Site Allocation ID value by checking the site allocation list.

8. The computing device (102) according to any preceding claim, wherein the controller (104) is further configured to perform memory management optimizations based on the combination of the Size of Allocation (SoA) of memory, the Return Address (RA), and the Stack Pointer (SP).

9. The computing device (102) according to any preceding claim, wherein the controller (104) is further configured to perform Security enhancements based on the combination of the Size of Allocation (SoA) of memory, the Return Address (RA), and the Stack Pointer (SP).

10. The computing device (102) according to any preceding claim, wherein the controller (104) is further configured to perform Paging and / or Memory Use based on the combination of the Size of Allocation (SoA) of memory, the Return Address (RA), and the Stack Pointer (SP).

11. A method (200) for a computing device (102) comprising a memory (106) and a controller (104), wherein the memory (106) comprises a stack (108) and a heap (110), and wherein the controller (104) is configured to allocate memory space in the memory for a plurality of heap objects based on a grouping of at least some of the plurality of heap objects, the method (200) comprising: receiving a memory allocation call indicating a Size of Allocation (SoA) of memory, obtaining a Return Address (RA), obtaining a Stack Pointer (SP), generating a Site Allocation ID value based on a combination of the Size of Allocation (SoA) of memory, the Return Address (RA), and the Stack Pointer (SP), determining if there is an Allocation Site Group having the Site Allocation ID value, and if not generating an Allocation Site Group having the Site Allocation ID value, and then adding the object to the Allocation Site Group and allocating memory according to the Allocation Site Group in the heap in the memory (106), wherein objects in the same Allocation Site Group are grouped in the heap (110).

12. A computer program product comprising program instructions for performing the method (200) according to claim 11 , when executed by one or more processors in a computing system.

Images