Arena-based Memory Management

Abstract

A memory management system based on arena is disclosed. In response to a call for reclaiming memory for storing a group of objects allocated in an arena, unused objects in the group of objects allocated in the arena are collected (302). Active objects among the multiple objects are copied from the arena to the heap (304).

Description

Background Art

[0001] Two common memory management techniques in computer systems include manual memory management and garbage collection. Manual memory management involves explicit memory allocation and deallocation by a programmer, such as using the malloc() and free() functions in the C programming language standard library or the new and delete operators in the C++ programming language. Garbage collection is a form of automatic memory management that attempts to detect objects no longer used by a software application or program on a computer system and reclaim the memory occupied by objects no longer used by the software application or program running on the computer system. Another memory management technique used in unmanaged programming languages (such as C++) is arena-based memory allocation. Arena-based memory management techniques are also known as region-based, zone-based, and group-based memory techniques. In an arena-based memory management system, each allocated object is placed in an arena specified by the program. Memory is reclaimed by destroying the arena and freeing all allocated objects within the arena. Summary of the Invention

[0002] This Summary of the Invention is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary of the Invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003] Manual memory management techniques rely on the programmer to determine which objects can be safely deleted and whether an object can be safely deleted. If an object is deleted prematurely, different parts of the program may attempt to use the same memory for different purposes. If an object is deleted too late or not at all, a memory leak may occur in the program. Garbage collection techniques can address the hazards of manual memory management techniques but may use more memory or more execution time than appropriate manual memory management techniques. Generally, arenas are explicit in software applications and are controlled by the programmer, and can improve program performance through explicit memory allocation and deallocation by the programmer, but do not address the problem of relying on the programmer to determine which objects can be safely deleted and whether an object can be safely deleted.

[0004] The present disclosure is directed to a managed environment, which may include garbage collection, but allows a programmer to express grouping of objects with a common lifetime, since many of the objects in the object group can be collected at the determination of the programmer at the end of the common lifetime. In addition, the managed environment may allow certain objects to survive the common lifetime, which addresses the problem of a programmer erroneously deleting an object too early. Scenarios where objects may be expressed in groups with a common lifetime may include server environments, where groups of objects are allocated together to service requests. Once a request has been serviced, many (if not all) of the objects may be collected. Another scenario may include a compiler or a language translator. Objects are typically allocated together to form an intermediate representation of a translation unit (such as a module or a method). Once the translation is complete, many (if not all) of the intermediate representations may be collected. The collected objects may be deleted.

[0005] In one example, the present disclosure provides an arena-based memory management system. In response to a call to reclaim memory storing objects allocated in an arena, unused objects in the arena are collected. Active objects in the arena are copied from the arena to the heap of a garbage collection service. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this disclosure. The drawings illustrate embodiments and, together with the description, are used to explain the principles of the embodiments. Other embodiments and many of the intended advantages of the embodiments will be readily understood as they become better understood by reference to the following description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals represent corresponding like parts.

[0007] Figure 1 is a block diagram illustrating an example of a computing device that may be configured in a computer network to provide, for example, a cloud computing environment.

[0008] Figure 2 is a block diagram illustrating an exemplary arena-based memory management framework for execution in a Figure 1 computing device.

[0009] Figure 3 is a block diagram illustrating Figure 2 an example method of an arena-based memory management framework. DETAILED DESCRIPTION

[0010] In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which specific embodiments of the invention are illustrated by way of example. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following description should not, therefore, be taken in a limiting sense. It is to be understood that the features of the various example embodiments described herein may be combined in part or in whole with each other, unless specifically stated otherwise.

[0011] Figure 1 An exemplary computer system is illustrated, which can be employed in an operating environment and is used to host or run computer applications included on one or more computer-readable storage media that store computer-executable instructions for controlling a computer system, such as a computing device, to perform processes. Examples of computer-implemented processes include concurrent garbage collection, which can be stored in computer memory and executed using a processor to be triggered according to dynamically adjustable parameters based on previous garbage collections.

[0012] The exemplary computer system includes a computing device, such as computing device 100. In a basic hardware configuration, computing device 100 generally includes a processor system having one or more processing units (i.e., processor 102) and a memory 104. For example, the processing unit may include two or more processing cores on one chip or two or more processor chips. In some examples, the computing device may also have one or more additional processing or dedicated processors (not shown), such as a graphics processor for general computing on a graphics processing unit, to perform processing functions offloaded from processor 102. Memory 104 may be arranged in a hierarchical structure and may include one or more levels of cache. Depending on the configuration and type of the computing device, memory 104 may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.) or some combination of both. Computing device 100 may take one or more of a variety of forms. Such forms include tablet computers, personal computers, workstations, servers, handheld devices, consumer electronic devices (such as video game consoles or digital video recorders), etc., and may be a stand-alone device or configured as part of a computer network.

[0013] The computing device 100 may also have additional features or functions. For example, the computing device 100 may also include additional storage devices. Such storage devices may be removable and / or non-removable, and may include magnetic or optical disks, solid-state memories, or flash devices, such as removable storage device 108 and non-removable storage device 110. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any suitable method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Memory 104, removable storage device 108, and non-removable storage device 110 are all examples of computer storage media. Computer storage media includes RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disc (DVD), or other optical storage devices, magnetic tape cartridges, tapes, magnetic disk storage devices, or other magnetic storage devices, universal serial bus (USB) flash drive devices, flash memory cards, or other flash devices, or any other storage media that can be used to store the required information and can be accessed by the computing device 100. Thus, a propagated signal itself does not qualify as a storage medium. Any such computer storage media may be part of the computing device 100.

[0014] The computing device 100 generally includes one or more input and / or output connections, such as USB connections, display ports, proprietary connections, and other connections for connecting to various devices to provide input and output to the computing device. Input device 112 may include devices such as a keyboard, a pointing device (e.g., a mouse, a trackpad), a stylus, a voice input device, a touch input device (e.g., a touch screen), etc. Output device 111 may include devices such as a display, a speaker, a printer, etc.

[0015] The computing device 100 generally includes one or more communication connections 114 that allow the computing device 100 to communicate with other computers / applications 115. Example communication connections may include an Ethernet interface, a wireless interface, a bus interface, a storage area network interface, and a proprietary interface. The communication connections may be used to couple the computing device 100 to a computer network, which may be classified according to various characteristics such as topology, connection method, and scale. A network is a collection of computing devices and possibly other devices interconnected by communication channels that facilitate communication and allow sharing of resources and information among the interconnected devices. Examples of computer networks include local area networks, wide area networks, the Internet, or other networks.

[0016] The computing device 100 can be configured to run an operating system software program and one or more computer applications that make up a system platform. The computer applications configured to execute on the computing device 100 include at least one process (or task), and at least one process is an executing program. Each process provides resources for the executing program. One or more threads run in the context of the process. A thread is the basic unit for which the operating system allocates time in the processor 102. A thread is an entity within a process that can be scheduled to execute. The threads of a process can share its virtual address space and system resources. Each thread can include an exception handler, a scheduling priority, thread-local storage, a thread identifier, and a thread context or thread state until the thread is scheduled. The thread context includes the set of machine registers of the thread, the kernel stack, the thread environment block, and the user stack in the process address space corresponding to the thread. Threads can communicate with each other during processing by means of techniques such as message passing.

[0017] Operations can be executed in a thread separate from the main application thread. When an application calls a method to execute an operation, the application can continue to execute on its thread while the method performs its task. Concurrent programming in a shared-memory multiprocessor can include the ability for multiple threads to access the same data. The shared-memory model is the most commonly deployed method of multithreaded communication. Multiple threads execute on multiple processors, multiple processor cores, multiple logical nodes in a single processor core, and / or other parallel classes attached to memory shared between processors.

[0018] The present disclosure generally relates to memory management techniques that combine an arena-based memory management system with garbage collection used with a programming language or runtime system in a data processing system such as the computing device 100. Aspects of the present disclosure can be embodied as a system, a method, or a computer program product. Thus, aspects of the present disclosure can take the form of entirely hardware, entirely software, or a combination of software and hardware aspects that are commonly referred to as a system, the software including firmware, resident software, microcode. In addition, aspects of the present disclosure can take the form of a computer program product that includes one or more computer-readable media or a medium having computer-readable program instructions for causing a processor to execute aspects of the present disclosure.

[0019] Figure 2Illustrates the features of an example software framework 200 that can be implemented on a computing device 100. The framework 200 can be used with software applications or programs written by developers, which are created for one or more platforms in one or more framework-compatible languages. The example framework 200 includes a class library 202 having a runtime library and a base class library, and an application engine such as a runtime system 204, a virtual machine, or a software container. In one example, the class library 202 includes a collection of classes organized by namespaces to define features available in a framework-compatible programming language. In some implementations, a software application written in a framework-compatible language is compiled as source code into a platform-neutral language or bytecode, which can be executed in a platform-specific virtual machine installed on a platform such as the computing device 100. The runtime system 204 compiles the bytecode into machine code that is executed on the platform. The runtime system 204 can provide additional services, including memory management, type safety, exception handling, garbage collection, security, and thread management. When executing a program written by a developer, the platform-specific just-in-time compiler 210 of the runtime system 204 translates the bytecode into machine code. The compiler 210 can provide a combination of ahead-of-time compilation and interpretation, and the runtime system 204 can handle late-bound data types and enforce security guarantees.

[0020] The class library 202 of this example can include one or more classes 206 implemented according to the disclosed method. Generally speaking, a class 206 is an extensible program code template or blueprint for creating objects, providing initial values of states, and implementing behaviors. A class is a construct that enables developers to create custom types by combining variables of other types, methods, and events. One or more classes 206 can include class variables, instance variables, local variables, parameters, user-defined methods, inherited states and behaviors, and interfaces. Variables can be retained in the memory 104 until they are deleted by an arena-based memory management system. At this time, the runtime system 204 can mark the variables as suitable for garbage collection via the garbage collector 208.

[0021] The library 202 may include functions or support operators provided for arena-based memory management, in which each allocated object is assigned to an arena. In one implementation, all objects in an arena may be allocated within a single contiguous memory address range in the memory 104. Multiple arenas may be active simultaneously, and each memory address range corresponding to each arena may be discontinuous from other allocated arenas. In one example, each arena is implemented as a data structure (such as a linked list) of memory segments (such as large memory blocks) in the memory 104, and each block in the memory 104 may be used for multiple allocations. The segment maintains a pointer to the next free position in the block, and if the block is filled, a new block is allocated and added to the linked list. When an arena is deallocated, the next free position pointer is reset to the beginning of the first block, and the block linked list may be reused for the next arena to be created. Additionally, when the region is deallocated, the block linked list may be appended to the global free list, from which other arenas may later allocate new blocks. Many operations may be performed to construct the linked list, and a single operation may deallocate the arena without having to traverse the linked list. The operations of allocation and deallocation may be implemented using simple functions in a library available to the programmer. The arena-based memory management system includes features and mechanisms for assigning allocated objects to an arena and immediately deallocating the objects from the arena in this way.

[0022] The runtime system 204 may allocate a memory segment in the memory 104 for an arena to store and manage objects. In one example, the memory segment is a heap. (The "heap" in this disclosure is different from the native heap in an operating system.) In one example, each process may have a heap, and threads in the process allocate memory for objects on the same heap. In another example, the heap may be a cumulative of a large object heap (such as a heap including objects with sizes exceeding a selected threshold) and a small object heap. The heap may include any number of discontinuous virtual memory chunks, each virtual memory chunk including an active block with objects, and these objects are scattered in free memory regions or free space regions. The runtime system 204 may maintain a free list data structure or a physical free list that indexes all the free memory that has been allocated.

[0023] The runtime system 204 may include a garbage collector 208 to automatically manage the allocation and deallocation of memory on the heap or managed heap of a software application. The garbage collector 208 attempts to detect objects that are no longer used by software applications on a computer system and reclaim the memory occupied by objects that are no longer used by software applications running on the computing system. In one example, the garbage collector 208 may provide tracing garbage collection to determine which objects should be deallocated by tracing which objects can be accessed by reference chains from certain root objects and collecting the remaining objects, rather than by reference counting. The garbage collector 208 includes an optimization engine 212 to determine the preferred time or timing for performing the collection. The garbage collector 208 examines objects in a memory segment that are no longer used by the application and performs operations to reclaim the memory. Garbage collection may occur in response to heap-related parameters such as when the system is physically out of memory or when the memory used by objects allocated on a memory segment exceeds an acceptable threshold.

[0024] In one example, the heap may be a generational heap. The heap may be organized into multiple generations to handle long-term and short-term objects. Garbage collection mainly occurs when reclaiming short-term objects that typically occupy a small portion of the heap. One example includes three generations of objects on the heap, including generation 0, generation 1, and generation 2. Generation 0 is the youngest generation and contains short-term objects such as temporary variables. Garbage collection occurs most frequently in this generation. In one example, newly allocated objects form a new generation of objects and implicitly are part of the generation 0 collection, unless they are large objects (in which case they go to the large object heap above the generation 2 collection). For garbage collection, many objects are reclaimed in generation 0 and do not survive to the next generation. Generation 1 includes short-term objects and may act as a buffer between short-term and long-term objects. Some example garbage collectors do not include a generation 1 heap and only include heaps for short-term and long-term objects. Additionally, short-term objects in one or more generations may be referred to as the ephemeral generation. Generation 2 includes long-term objects. An example of a long-term object is an object in a server application that contains static data that is valid for the duration of the process. When conditions permit, garbage collection occurs in a specific generation. Collecting a generation means collecting the objects in that generation and all of its younger generations. Generation 2 garbage collection is typically a full garbage collection because it reclaims all objects in all generations of the managed heap. Objects that are not reclaimed in garbage collection are called survivors and may be promoted to the next generation. For example, objects that survive generation 0 garbage collection are promoted to generation 1, objects that survive generation 1 garbage collection are promoted to generation 2, and objects that survive generation 2 garbage collection remain in generation 2.

[0025] Before garbage collection begins or is triggered, managed threads other than the thread that triggered the garbage collection can be suspended. The garbage collector 208 can determine whether an object is alive by information such as stack variables provided by the just-in-time compiler and stack walker, handles that point to managed objects and can be allocated by user code or the runtime, and based on static objects in the application domain that may be referencing other objects. Each application domain keeps track of its static objects. In one example, garbage collection can occur in a set of phases, which include a marking phase that finds and creates a linked list of all live objects, a relocation phase that updates references to objects that will be compacted, and a compaction phase that reclaims the space occupied by dead objects and compacts the surviving objects. The compaction phase moves the objects that survive the garbage collection towards the older end of the memory segment. In one example, the garbage collector 208 can be a mark-and-sweep collector that can find and create a list of all live objects, update references to objects that occupy memory to be compacted, reclaim the address space occupied by dead objects, and compact the surviving objects.

[0026] Figure 3 An example method 300 for use with an arena-based memory management system (such as framework 200 that supports using an arena for memory management and has a garbage collector 208) is illustrated. In this example, an arena is created in a memory segment (such as memory 104) separate from the heap of the garbage collection service. In response to a call to reclaim memory for a plurality of objects allocated in the arena, at 302, unused objects in the arena are collected. In one example, the call to reclaim memory is delayed until the cleaning of the arena is triggered based on selected metrics. This may contrast with typical arena collection that reclaims memory directly in response to a call. The selected one or more metrics can include typical garbage collection triggers. However, in the case of method 300, the cleaning of the arena does not occur until after a call to reclaim the memory of the arena. This can contrast with typical garbage collection that can occur before programmatic memory deallocation. A cleaning routine or cleaning task for the arena can be used to destroy the arena.

[0027] In addition, in response to a call to reclaim memory, at 304, the active objects among the multiple objects are preserved by copying the active object to the heap. In this example, the heap is a service with garbage collection. In one example, garbage collection is tracking garbage collection and detecting active objects that have been set to be released. In one example, a call to reclaim memory can relocate the active object outside the arena, such as in a portion of the managed heap before the arena is deallocated. A typical implementation of an arena is unsafe because the arena can be deleted even if other arenas have accessible pointers to objects to be deleted in the arena. Instead of applying a reference counter to prevent the arena from being deleted, the active objects are relocated and the arena is deleted. Pointers to the active objects relocated from the arena to the heap are updated. In one example, the arena can be deleted after the arena no longer includes active objects or pointers to the arena. Thus, method 300 deletes the arena at a valid point in the program after calling to reclaim memory (which may occur after calling to reclaim memory), and preserves the active objects that may inadvertently remain in the arena to be deleted in the heap. The active objects relocated to the heap can be garbage collected after they are no longer used. The portion of the memory used by the reclaimed arena can be used for other arenas.

[0028] In one example, framework 200 can allow garbage collection and arena-based memory management to coexist in the same application by using separate memory segments for garbage collection and arena-based managed objects. Class library 202 can provide functions and statements to implement arena-based memory management in a program addressed at objects with a common lifetime. In one example, class library 202 can include functions to allocate memory to an arena and to allocate objects within the arena.

[0029] In one example, an arena can be created in a program using the following statement:

[0030] Arena abc = new Arena()

[0031] Objects (such as objects with a common lifetime) can then be assigned to the arena. At a certain part of the program, when many (if not all) of the objects in the arena are no longer in use, i.e., the common lifetime expires, the arena can be reclaimed in the program using the Dispose method in the following statement, such as

[0032] abc.Dispose()

[0033] The runtime system 204 will determine which objects (if any) allocated in the Arena are still alive or in use and copy those objects to the garbage collection heap. In one example, the runtime system 204 can wait until an appropriate time to copy the surviving objects to the heap. The class library 202 can also provide mechanisms to group parts of the program to create and collect Arenas for objects with a common lifetime in the program using statements such as:

[0034] using(Arena abc = new Arena())

[0035] {

[0036] / / … Program statements using arena abc

[0037] }

[0038] Directing allocations to an Arena can be referred to as “activating the Arena”. The Activate function can cause a thread to allocate in the Arena using a statement such as:

[0039] ArenaThread xyz = abc.Activate()

[0040] The Activate function returns an ArenaThread object. Allocations can be directed back to the heap by calling the Dispose function on the ArenaThread object, such as:

[0041] xyz.Dispose()

[0042] The class library can also provide mechanisms to combine these two operations with the using statement, such as:

[0043] using(abc.Activate())

[0044] {

[0045] / / … Here allocations go to Arena abc

[0046] }

[0047] Example implementations can include an allocator stack attached to each execution thread. In response to the execution of the Activate function, the allocator associated with the Arena is pushed onto the allocator stack. In response to the ArenaThread object set using the Dispose function, the associated allocator is popped from the allocator stack. For object allocation, the topmost allocator on the stack provides the memory. The use of multiple threads within the same Arena is expected and can be used in scenarios of a server environment where multiple threads cooperate to service requests.

[0048] Framework 200 can include support for asynchronous programming, where a task can be initiated by a first thread, suspended while waiting, and then continued in a second thread. In the case where the task is associated with an Arena, the first thread and the second thread are allocated within the same Arena. Framework 200 includes provisions for automatically allocating the threads of a task to the same Arena.

[0049] Allocation is directed to the Arena in such a way that implies that other code or arena-aware logic called by the logic using the Arena will allocate memory within the Arena without modification or recompilation. In this configuration, existing code can be modified to work with arena-aware logic. In cases where it is not desired for existing code to work with an Arena, such as for certain library routines known to allocate independent of any Arena, the garbage collection heap can be activated using the following statement:

[0050] using(Arena.GCHeap.Activate())

[0051] {

[0052] / / … Here allocations go to the heap instead of the Arena

[0053] }

[0054] A reference counting scheme can be implemented to address the situation where an Arena is set up but still in use for allocation. In an example of the reference counting scheme, Arenas are created with a reference count x (such as 1). For each instance, the allocator for the arena is pushed onto the allocator stack of the thread, and the reference count for the arena is incremented. Calling the Dispose function on an Arena decrements the reference count. Additionally, calling the Dispose function on an ArenaThread object pops the allocator stack on the current thread and decrements the reference count for the Arena associated with the allocator. If the reference count on the Arena drops to x - 1, or 0 in the example, the Arena becomes collectible, i.e., the system will copy out all live objects or objects that are still reachable at some point in the future and then destroy the arena.

[0055] In one example, the framework 200 may not restrict where pointers to objects in an Arena can be stored. Thus, pointers to objects in Arenas may be encountered in local variables, in objects within the same Arena, in different Arenas, or in the heap. Similarly, objects in an Arena can freely point to regular garbage-collected objects or objects in different Arenas. To determine which objects in a collectible Arena are still reachable and thus to be retained, the thread stack and its associated local variables, as well as heap objects, can be examined. To simplify this examination, the runtime system 202 can record instances where references are created between different Arenas or between an Arena and the heap. In one example, a reference from the heap to an Arena sets a byte in the card table used by the heap to track cross-generation pointers, and the reference is also recorded in the per-thread reference list. If the reference is to a short-lived garbage-collected memory, i.e., garbage collection generation 0 or 1, a bit is set in a side table for the reference from the Arena to the heap. Additionally, references between Arenas also have a bit set in the side table and are recorded in each thread's reference linked list.

[0056] When an Arena becomes collectible, such as when the reference count on the Arena drops to x - 1 or 0 in the reference count example, the runtime system 202 copies the still-accessible objects of the Arena to the heap and the garbage collector 208 will service them. The runtime system 202 can include Arena collection and Arena collection with garbage collection. In Arena collection, the active objects or object-accessible objects in the collectible arena are copied to the heap. In one example, objects in the heap are not considered for collection unless they have a pointer to an object in the collectible Arena. Arena collection is relatively fast but can be relatively conservative because inaccessible objects in the heap may contain pointers to objects in the Arena. An object in the Arena will be considered accessible even if it can only be accessed through an object that is itself inaccessible. This can cause inaccessible objects in the Arena to survive. Arena collection with garbage collection allows the runtime system 202 to calculate accessibility with relatively higher precision, but Arena collection with garbage collection is relatively more expensive than Arena collection.

[0057] In one example, the runtime system 202 can automatically determine whether to apply Arena collection or Arena collection with garbage collection. For example, the runtime system 202 can evaluate and determine based on metrics including the amount of memory used on the heap and the amount used in the reference linked list. A program can trigger garbage collection by calling the GC.Collect() function, and in one example, the function can cause Arena collection with garbage collection to occur.

[0058] References to objects in Arenas during Arena collection can be determined according to the following metrics, which include local variables in the user program, reference linked lists built when creating references from the heap to an Arena or between different Arenas, finalizable objects in the collectible Arenas, and garbage collection handles. It can be determined whether the object being pointed to is in the collectible arena. If the object being pointed to is in the collectible Arena, the object is copied to the heap and the garbage collector 208 will service it. The reference to the object (if it exists) can be updated to point to the new location.

[0059] Determining whether the object being pointed to is in the collectible arena can include determining whether the pointer points to the memory range reserved for the arena. If the pointer points to the memory range reserved for Arenas, the block number contained in the Arena memory is calculated. In one example, the Arena memory is subdivided into 1MB (1MiB) blocks, and determining the block number includes subtracting the base address of the Arena memory range and dividing the resulting offset by 2 20, or 1 MiB. The block number is used to index into a lookup table that contains the number of the Arena that each block contains. It is possible to determine whether the actual reference count of the Arena containing the Arena is 0.

[0060] Objects that are referenced from the copied object can be in a collectible Arena or can be copied to the heap. This includes objects that are referenced from objects that are referenced from the copied object, and so on.

[0061] In scenarios that include a server environment, several execution threads can cooperate to perform the cleanup task, and the runtime system 202 can provide a locking scheme and work coordination among the cleanup threads. The locking scheme can help ensure that a given Arena object will be copied by one cleanup thread and that the cleanup thread will see a consistent new location for the object. This also ensures that if there are multiple references to an object, they will all be updated to the same new location. As a special case, several threads might try to update the same reference simultaneously, which is acceptable because all threads write the same value. The work coordination among the cleanup threads can keep all cleanup threads busy, thus minimizing or reducing the time for the cleanup task. The work coordination can be performed by efficiently enumerating shared data structures (Arenas, Arena blocks, reference lists) across multiple cleanup threads. Since the cleanup process is a multi-stage process, the work coordination helps prevent threads from moving to the next stage before all threads have completed the current stage. For example, before destroying an Arena, we need to ensure that all cleanup threads have indeed completed evacuating objects from it.

[0062] Although specific embodiments have been illustrated and described herein, those of ordinary skill in the art will understand that various alternative and / or equivalent implementations may be used in place of the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any modifications or variations of the specific embodiments discussed herein.

Claims

1. A method for controlling an arena - based memory management system, the method comprising: creating an arena in memory in response to a program statement of a program running in a framework, wherein the framework allocates a plurality of objects to the arena in memory, the arena being recyclable after programmed de - allocation, the memory comprising the arena and a segment for collected managed objects automatically allocated by the framework; and in response to a call from the program for reclaiming memory storing a plurality of objects allocated in the arena, de - allocating the arena, copying active objects among the plurality of objects from the arena to the segment for collected managed objects before de - allocating the arena, and collecting, using the framework, objects among the plurality of objects that are not in use in the arena.

2. The method according to claim 1, comprising destroying the arena in response to the call.

3. The method according to claim 1, wherein the segment for collected managed objects comprises a heap, and the heap is serviced by garbage collection.

4. The method according to claim 3, wherein the garbage collection is generational garbage collection.

5. The method according to claim 1, wherein the call for reclaiming memory comprises a destroy method.

6. The method according to claim 1, wherein the call for reclaiming memory comprises reclaiming the arena.

7. The method according to claim 6, wherein the call for reclaiming memory further comprises garbage collection.

8. The method according to claim 1, wherein copying active objects further comprises copying objects referenced from the active objects.

9. The method according to claim 1, comprising using reference counting if the arena is being used for allocation.

10. The method according to claim 1, wherein the segment for collected managed objects comprises a heap, and the plurality of objects point to objects in the heap.

11. An arena - based memory management system, comprising: a memory device for storing a set of instructions; and a processor for executing the set of instructions for: creating an arena in memory in response to a program statement of a program running in a framework, allocating a plurality of objects to the arena in memory using the framework, the arena being recyclable after programmed de - allocation, the memory comprising the arena and a segment for collected managed objects automatically allocated by the framework; and in response to a call from the program for reclaiming memory storing a plurality of objects allocated in the arena, collecting, using the framework, objects among the plurality of objects that are not in use in the arena, de - allocating the arena, and copying active objects among the plurality of objects from the arena to the segment for collected managed objects before de - allocating the arena.

12. The system according to claim 11, wherein the segments for the collected managed objects are served by a generational garbage collector.

13. The system according to claim 11, wherein the segments for the collected managed objects include a heap, and the heap has pointers to objects not in use in the arena, and the objects not in use are collected in response to the call for memory reclaim.

14. The system according to claim 11, wherein the response to the call for memory reclaim includes garbage collection.

15. The system according to claim 11, wherein multiple threads are allocated in the arena.

16. The system according to claim 15, wherein each thread includes an allocator stack.

17. A computer-readable device for storing computer-readable instructions for controlling a processor to control arena-based memory, the instructions comprising: creating an arena in memory in response to a program statement of a program running in a framework, allocating multiple objects to the arena in memory using the framework, the arena being recyclable after programmed deallocation, the memory including the arena and segments for collected managed objects automatically allocated by the framework; and in response to a call from the program for reclaiming memory storing multiple objects allocated in the arena, collecting, using the framework, the objects not in use in the arena among the multiple objects, deallocating the arena, and copying active objects among the multiple objects from the arena to the segments for the collected managed objects before deallocating the arena.

18. The computer-readable device according to claim 17, including instructions for a destruction method for reclaiming memory.

19. The computer-readable device according to claim 17, including an activation method for allocation in the arena.

20. The computer-readable device according to claim 17, wherein the instructions for collecting the objects not in use in the arena include performing a cleanup task.

Images