WO1995016957A1

WO1995016957A1 - Object-oriented memory allocation framework

Info

Publication number: WO1995016957A1
Application number: PCT/US1994/002627
Authority: WO
Inventors: Andrew G. Heninger; Rashmi Garde
Original assignee: Taligent, Inc.
Priority date: 1993-12-17
Filing date: 1994-03-11
Publication date: 1995-06-22
Also published as: AU7090894A

Abstract

A method and system for a system level memory allocation framework using object-oriented memory heaps. The heaps may be either local or shared, and may be subclassed to provide a variety of other types of heaps for the system and methods. The system and method also support techniques for iterating through allocated and unallocated memory heaps. Support is also provided for debugging operations of memory, and providing multiple heaps for a single application. The object-oriented memory allocation framework provides the ability to easily interface and manage segments which collectively comprise heaps in memory. The segments may be noncontiguous. Heaps may be shared across tasks, or across address spaces.

Description

OBJECT-ORIENTED MEMORY ALLOCATION FRAMEWORK

COPYRIGHT NOΗFICATION

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

Field of the Invention

This invention generally relates to improvements in computer systems, and more particularly to improvements in systems and methods for allocating memor

Background of the Invention Memory management in a computer system is one of the most important aspects of overall system performance of the computer system. Over the years numerous apparatus and methods have been developed which attempt to provide a system user with easy manipulation of memory entities, while at the same time implement extremely complex data transfers for purposes of providing efficient memory utilization. The tension between the ease of use for a user and the inherent complexity in managing memory in the most efficient manner has provided impetus for great advances in virtual memory systems, disk systems, cache memories, and shared environments. Even though some strides have been made to ease this tension, the user of the memory system, typically a programmer attempting to design an application program, is often confronted with extremely complex, bewildering and esoteric choices of memory management.

A developer of application programs must often learn nuances of particular memory architectures, transfer operations, timing, and general protocol in order to maximize the relationship between the application and the system on which the application runs. This is especially true with respect to the supporting data transfer operations available for managing the memory architecture. The developer often must learn excruciating details of the physical aspects of the memory. The burden clearly on the application developer to develop a meaningful memory management system for the particular application being designed. The complexity becomes even greater if the application is a multi-user application which requires access by multiple entities to common memory structures. Summary of the Invention

Accordingly, it is a primary object of the present invention to provide a system and method for providing a memory allocation system which provides uniform and powerful memory entities which can easily be manipulated and designed to enhance implementation of particular uses of the computer system. It is a further object of the present invention to provide object-oriented memory allocation systems and methods.

It is yet a further object of the present invention to provide memory heap objects which can be subclassed, used by single tasks and multiple tasks. The above and other objects are realized by a system and methods which provide heap objects for interfacing storage allocation with the memory system. The heap objects can be either local or shared, and can be subclassed to provide unique characteristics related, but not identical to, the abstract base class from whic they are subclassed. The system and methods of the present invention allow an application to have multiple independent heaps. There is also support for debugging the memor allocation system, and for providing iteration through allocated and unallocated memory. The heap objects allow a wide variety of manipulations on memory entities, and provides a variety of information regarding those entities.

Brief Description Of The Drawings Figure 1 illustrates a typical hardware configuration of a computer in accordance with the subject invention;

Figure 2 shows the general relationships among heap objects, heaps and segments;

Figure 3 shows the storage class hierarchy of the present invention; Figure 4 is a block diagram showing allocation using TLocalMemoryHeap; Figure 5 illustrates heaps being shared across tasks; Figure 6 shows the creation of a shared heap; Figure 7 shows the development of special heaps through subclassing;

Figure 8 shows the use of multiple heaps in a task address space; Figure 9 illustrates the delete operation;

Figure 10 shows the operation of reallocation of the present invention; Figure 11 demonstrates the operation of obtaining a heap pointer in respons to providing a block pointer;

Figure 12 shows the determination of heaps accessible by the current task;

Figure 13 shows objects stored in shared heaps;

Figure 14 shows a general processing flow for implementing write protection Figure 15 illustrates several debugging tools available in accordance with the present invention;

Figure 16 shows a processing flow for the heap iterator; and Figure 17 shows certain methods associated with heaps and the allocator framework.

Detailed Description Of The Invention

The detailed embodiments of the present invention are disclosed herein. It should be understood, however, that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. Therefore, the details disclosed herein are not to be interpreted as limiting, but merely as the basis for the claims and as a basis for teaching one skilled in the art how to make and /or use the invention.

The history of object-oriented programming and the developments of frameworks is well-established in the literature. C++ and Smalltalk have been well-documented and will not be detailed here. Similarly, characteristics of objects, such as encapsulation, polymorphism and inheritance have been discussed at length in the literature and patents. For an excellent survey of object oriented systems, the reader is referred to "Object Oriented Design With Applications" by Grady Booch.

While many object oriented systems are designed to operate on top of a basic operating system performing rudimentary input and output, the present system is used to provide system level support for particular features. It should be kept in mind, however, that innovative objects may also appear in layers above the system level in order to provide object support at different levels of the processing hierarchy.

The invention is preferably practiced in the context of an operating system resident on a personal computer or workstation such as the IBM ® PS/2 ® or Apple ® Macintosh ® computer. A representative hardware environment is depicted in Figure 1, which illustrates a typical hardware configuration of a computer in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units interconnected via a system bus 12. The computer shown in Figure 1 includes a Read Only Memory (ROM) 16, a Random Access Memory (RAM) 14, an I/O adapter 18 for connecting peripheral devices such as disk units 20 and other I/O peripherals represented by 21 to the system bus 12, a user interface adapter 22 for connecting a keyboard 24, a mouse 32, a speaker 28, a microphone 26, and /or other user interface devices such as a touch screen device (not shown) to the bus 12, a communication adapter 34 for connecting the workstation to a data processing network represented bv 23. A display adapter 36 for connecting the bus to a display device 38. The workstation has resident thereon an operating system such as the Apple System/ 7 ® operating system. The storage allocator of a preferred embodiment maintains the storage for all ordinary C++ objects (operators new and delete), as well as the storage allocated by the C library functions (malloc, free, etc.) The allocator has these characteristics: 1) Non-relocatable blocks, no compaction, no garbage collection. This is the standard model for C++. 2) The allocator is reentrant and multi-tasking safe. Multi- threaded applications need no special precautions when using the allocator. 3) Fast. 4) Able to deal efficiently with huge heaps (given sufficient physical memory). 5) Simplified error handling. Allocations of "reasonable" size will always succeed.

Users may design special purpose allocators that fit into the memory storage allocator framework. The storage allocator framework supports the following features: 1) Subclassing to implement special purpose heaps. 2) Applications may have multiple independent heaps. 3) Heaps may be placed in shared memory, and contain objects to be shared among tasks. 4) Debugging Aids 5) A way to iterate through the allocated or free blocks in a heap.

Figure 2 illustrates the general structural relationships of a heap. Heaps 202 in the present system consist of one or more memory segments, 204 and 206. Heaps may contain noncontiguous segments, as shown in the Figure 2. For example, an allocator may open a new segment to satisfy a large memory request. A heap object 200 describes the memory that it manages. The heap object 200 may or may not be allocated in the actual memory that it describes. However, any particular address can be contained in at most one heap. While it is possible to allocate a heap object in another heap, it is not possible to allocate the memory that the heap object describes within the bounds of another heap. In other words, the storage managed by one heap object can not overlap the storage managed by another heap object. In most cases the memory that the heap object manages is allocated by creating a kernel memory segment. Figure 2 is merely illustrative of the implementation of the memory heap. The actual heap could be implemented using a linked list of segments. The arrows between heap object 200 and heap segments 204 and 206 are merely for purposes of showing that the heap object has a relationship to the heap 202, and segments 204 and 206 of the heap. Multiple copies 208 of a heap object may exist. In fact the heap framework makes a copy (by using the heap objects copy constructor) of each unique heap object in a task's address space. These master copies of heap objects are used by the global operator delete and some methods of TMemoryHeap to "look up" the heap in which a certain block is allocated. All the copies of a heap object manage the same storage. Any one of the copies of the heap object can be used to allocate, free, etc. storage in the space that the heap objects manage.

Storage Allocator Classes

Figure 3 shows the class hierarchy for the storage allocator of the present invention. TMemoryHeap 300 is an abstract base class that defines the basic interface for system storage allocators. TStandardMemoryHeap 302 is the abstract base class of the two concrete storage allocator classes, TLocalMemoryHeap 304 and TSharedMemoryHeap 306. TStandardMemoryHeap 302 is intended to be subclasse and the inherited methods overridden. In addition to providing the features of TMemoryHeap 300, TStandardMemoryHeap 302 supports the association of TMemoryHook objects. TMemoryHook objects monitor heap usage. The support of TMemoryHook is specific to the standard concrete classes; it is not a part of the basic interface for storage allocators. TLocalMemoryHeap 304 provides heaps for us by a single task. As illustrated in Figure 4, unless you explicitly ask that it be otherwise, everything that you allocate, at 402, with either C++ operator new or mallocO, at 404, will go in a single default heap of this type, at 408 and 414. If explicitly requested otherwise, the memory is allocated according to the request, indicated by 406. A TLocalMemoryHeap 304 does not overflow unless it receives a request that it can not satisfy with the amount of memory available 410 in the system. If there is insufficient memory in the system to support the request, the TLocalMemoryHeap 304 raises an exception, at 412. In general a TLocalMemoryHeap 304 grows as large as necessary to support the requests that it receives. A size constructor parameter to TLocalMemoryHeap 304 specifies the initial size of the heap. The heap may dynamically grow larger than this initial size in order to satisfy requests. TSharedMemoryHeap 306 provides, as illustrated in Figure 5, heaps 504 that may be shared across tasks 500 (across address spaces). Placing objects in a shared heap (represented collectively by 502) allows any number of cooperating tasks to directly (with pointers) reference the objects. A size constructor parameter specifies the size of a TSharedMemoryHeap. A shared heap does not grow larger than its initial size. Requests that cause the shared heap to overflow cause an exception to be raised.

Figure 6 shows the flow of TSharedMemoryHeap creation. In order to use a shared memory heap, one of the group of cooperating tasks must initially create th heap, at 602, and then stream the heap object (it's small; it does not include the hea contents) to the other tasks, at 604, which then resurrect the heap from the stream, at 606. The storage for shared heaps will automatically be mapped at the same logical address in all tasks using the heap, at 608. This mapping allows for the use of ordinary pointers to refer to objects in these heaps.

Other heaps : Figure 7 illustrates the subclassing of heaps to create special purpose heaps. Heaps supporting some form of garbage collection 702; heaps that must live in a constrained logical address space (perhaps in physical memory on some peripheral board) 704; heaps that do not have multi-tasking synchronization (and consequently are faster) 706; heaps that are optimized for a peculiar pattern of usage

708. These heaps are implemented by subclassing from TMemoryHeap 700.

Subclasses must override some basic methods of TMemoryHeap 700. Other subclasses may not support the other features of the memory storage allocator framework. Some of the features of the storage allocator framework include streaming operators, information on heap content, debugging aids and heap iterators. Support of these features is not mandatory.

Storage may be allocated directly by calling methods of a TMemoryHeap object 300, or indirectly by using the C++ operator new or malloc() from the standard C library. These indirect allocations will eventually reference some heap object to do the actual allocation.

Multiple Heaps Figure 8 is a functional block diagram demonstrating the use of multiple heaps 804, 806 in a task address space 800. A task always has one default heap 804. It may have several additional heaps 806 . . . within its address space. A global variable, TMemoryHeap::fgDefaultHeap 802, points to the default heap. If a programmer uses the default C++ operators new or the C function malloc() for allocations, as indicated by the processing determination at 808, the storage is allocated in the default heap, at 810. If a programmer believes that a class object being designed may be allocated in some heap other than the default heap, indicated by 814, he should use the overloaded operator new(size_t, void *) 812 for any storage allocated by the class he is designing. It is necessary that any storage allocated by an object be allocated in the same heap as the object, if the object may be allocated in a shared heap.

A heap other than the default heap could be used for better performance for high volume allocations and deletions. TMemoryHeap subclasses may be designed to suit the needs of an application.

Allocate: By default, C++ heap objects are placed in the default heap. A block may be allocated in a specific heap by directly specifying the heap. However, allocating an object by using the default operator new and allocating space for an object by invoking the allocate method of a specific heap are not equivalent operations.

Using the global operator new to allocate space for an object will invoke the object constructor. The allocate method does not invoke the object constructor.

Storage may be allocated in the same heap as some previously existing storage with yet another overloaded version of operator new. If the original block not an address that is managed by any heap object (it may be NIL, or point to stack global data), the new block will be placed in the default heap.

This construct is useful when a class designer expects that objects may sometimes be placed in shared heaps. When an object is created in a shared heap, any additional objects or storage that are created by the object must also be placed in the same shared heap so that they will be accessible from all address spaces that can see the object.

Delete: As shown in Figure 9, delete is a conditional operation; it will identify the heap containing the block, indicated at 906, and delete it from that heap, at 908. A block may be deleted from a specific heap as well, at steps 902 and 904. However, deallocating an object by invoking the global operator delete and deallocating an object by directly invoking a heap's free method are not equivalent operations.

Deallocating an object by invoking the operator delete will invoke the object's destructor. A heap's free method does not invoke the object's destructor. Reallocate: Figure 10 shows the processing of reallocation. A block may be reallocated in a specific heap, as indicated by 1002, 1004, and 1006. If the heap containing the block is not known, at 1002, a static function,

TMemoryHeap::ReallocateAny may be invoked, at 1008.

TMemoryHeap::ReallocateAny determines in which heap a block is allocated, at 1010, and resizes the block in that heap, at 1012.

Finding a Heap As shown in Figure 11, given a pointer to a block, at 1100, that is allocated in a heap, decided at 1102, you can obtain a pointer to the heap object in which it is allocated, at 1106. If the specified address is not in the address space managed by any heap object, NIL is returned, at 1104.

Determining Accessible Heaps Figure 12 is a flow diagram which demonstrates determining which heaps are accessible by the current task. For er ample, an application 1200 may desire to know which heaps are accessible at a particular time, and makes a request of the memory framework 1202 to make such a determination. The procedure begins by invoking the static method TMemoryHeap::GetMemoryHeaps 1204. This method returns TMemoryHeap pointers 1208 in the TCollection reference parameter 1206.

Each TMemoryHeap pointer in the collection refers to a heap object that is accessibl to the current task. The collection of heap objects returned by TMemoryHeap::GetMemoryHeaps is a snap shot of the heaps in this task's address space. The set of heaps accessible to the task may change after the collection is returned. For example a new heap could be created, or an existing heap may be deleted. In the latter case the collection returned by the call to TMemoryHeap::GetMemoryHeaps will contain a pointer to a heap object that has been deleted. However, if no task in the current task creates or deletes a heap, the collection returned by TMemoryHeap::GetMemoryHeaps will contain an accurate representation of the heaps accessible by this task.

Shared Heaps

As previously discussed with respect to Figure 5, heaps may be shared among tasks (across address spaces). As shown in Figure 6, one task creates the shared heap (602). Knowledge of this heap is then passed to other tasks using the standard streaming operators (604). Only a description of the kernel memory segment managed by the heap object is passed in the stream; the contents of the heap are not streamed. Because shared memory heaps do not have global names, a task can not request to stream in some existing shared memory heap by name.

Note: Not all heaps can be streamed. Streaming a TLocalMemoryHeap causes an exception. In order for a heap to be streamed, the heap must have valid streaming operators. A shared heap will appear at the same logical address in all tasks using it. The physical heap will survive as long as any task is referencing it. Any shared heap operations may be performed by any task using the heap.

Objects in Shared heaps

Objects in shared heaps are supported. The prerequisites for objects in shared heaps is represented by a flow shown in Figure 13. Simply pass, by whatever means is convenient, the addresses of the objects to be shared, as shown at 1300. All tasks using the shared object must have streamed in the shared heap, at 1302, and have loaded the shared libraries containing the code for the object^'s methods, at 1304. The system ensures that the necessary shared libraries have been loaded, at 1306.

Shared objects will need to take precautions required of any object allocated in other than the default heap. Any subobjects referenced by the object must be allocated in the shared heap as well. Any pointers within a shared object referring to data that is not present in the address space of all tasks sharing the object will lead to disaster.

Figure 14 is a flow diagram demonstrating the write protection processing of the present invention. By default the write protection of a shared heap may be modified by any of the tasks that are using the shared heap, as indicated by 1406. The write protection is modified only in the task that makes the modification; the write protection remains the same in all the other tasks that are using the shared heap. When a task streams in a shared heap, the heap is streamed in with the same write protection as the task from which it is streaming the shared heap, indicated by 1408. For example, if a shared heap is used by three tasks: task one, task two and task three, and task one has set the shared heap read only in its address space, then if task three streams in the shared heap from task one, task three will access the shared heap in read only mode. Nevertheless, task three is free to change the write protection on that shared heap after it has streamed it in.

The task that creates a shared heap, however, may prohibit any other task from modifying the write protection of the shared heap. The creating task invokes SetWriteProtectionModifiable(FALSE), indicated by 1400, in order to thwart attempts by other tasks to modify the write protection of the shared heap in their address spaces. This method is useful for a task that creates a shared heap and wants to allow other tasks to use that shared heap in read only mode. The task must set write protection modifiable to FALSE and set the heap read only before streaming the heap to another task. The second task is only able to use the shared heap in read only mode and can not modify the write protection of the shared heap in its address space, unless the creating task resets write protection modifiable to TRUE, at 1404.

Debugging Aids

As shown in Figure 15, some options are provided by the memory storage allocator framework 1500, in the form of debug option modules 1502, that aid in debugging applications: the contents of heap blocks may be set to a certain value on allocation 1504; the contents of heap blocks, except for the space if any used by the storage allocator for management of the freed space, may be set to a certain value (different than the allocation value) on deallocation 1506; and /or heap blocks may be prohibited from reuse 1508. The values that are chosen for setting the contents of allocated /deallocated blocks are illegal as pointers, readily recognized when seen during debugging and less likely than NIL to occur otherwise. By default, none of these options is set. Use of these options may cause a noticeable degradation in performance. These debugging options are not a necessary part of the framework. A class designer may choose not to support them. These options are supported in the system concrete classes TLocalMemoryHeap and TSharedMemoryHeap. Fven if the options are not set, the TLocalMemoryHeap::Free and

TSharedMemoryHeap "Free methods set the contents of the first four bytes of the freed block to the free value. Heap Iterators

Figure 16 illustrates the general processing of iteration in accordance with the disclosed memory allocation system. Subclasses of the abstract class TMemoryHeapIterator are used for iterating through either the allocated or free blocks in a heap. An enumerated type, EHeapBlockType, passed into the First() method determines whether the iterator will go through the allocated or free blocks, at 1600. The default mode is to iterate through the allocated blocks, at 1604. The general process of iterating through either free or allocated memory is indicated by 1606. Figure 17 shows two of the iterator and memory allocator framework methods which are available. A possible scenario is an application 1700 sending requests to the memory allocation framework 1702. The heap iterator methods First() and Next() 1604 return the addresses of allocated or free blocks in their corresponding heap 1706. The size of an allocated or free block 1706 is obtained through an optional size_t reference parameter of the First() and Next() methods. Alternatively, the size of an allocated block 1710 can be determined by calling the heap's BlockSize() method 1708. Any modification to the heap (allocation, free, reallocation) that occurs while iterating through the heap invalidates the iterator, causing an exception to be raised. TStandardMemoryHeapIterator is the class provided for iterating through TLocalMemoryHeap and TSharedMemoryHeap objects; it is not intended to be subclassed unless the inherited methods are used. If the exact type of a heap is unknown, you can request that the heap create an iterator for itself. Provision of a heap iterator is not a necessary part of the memory storage allocator framework. A class designer may choose not to support a heap iterator. In this case, the heap's Createlterator method raises an exception.

Description of TMemoryHeap Methods

TMemoryHeap::~TMemoryHeap () Destructor. void TMemoryHeap::Allocate(size_t size) Allocate a new block of at least the specified size. An allocator may allocate a larger size block; in this case, no record of the originally requested size is kept. If the size is zero, NIL is returned. size_t TMemoryHeap::BlockSize(const void *block) Return the size in bytes of the specified allocated block. It assumes that block points to the start of a block in this heap. This method is not valid for free blocks. size_t TMemoryHeap::BytesAllocated() Return the total number of bytes allocated

(including space used by the heap for managing the heap). void TMemoryHeap::Check() Run a consistency check on the heap to detect corruption of the heap's internal state. Raise an exception if any inconsistencies are found.

TMemoryHeapIterator *TMemoryHeap::CreateIterator() Create an iterator for the heap. void TMemoryHeap::Free(void *block) Free the space to which block refers. If bloc is not an address of a previously allocated block in the address space managed by this heap object, an exception is raised.

TLocalMemoryHeap *TMemoryHeap::GetDefaultHeap() Return a pointer to the default local memory heap. Every task has a default local memory heap. void TMemoryHeap::GetMemoryHeaps(TCollection &) Return the set of heaps accessible to this task in the collection parameter. The returned collection contains pointers to TMemoryHeap subclass objects. This method returns a snap shot of the memory heaps accessible to this task. The set of memory heaps accessible to the task may change afterwards. For example, if a new heap is created, or an existing heap is deleted in this task's address space after that call to this method, then the collection returned by this method no longer contains an accurate set of heaps accessible by this task.

TMemoryHeap *TMemoryHeap::HeapOf (const void *block) Return a pointer to the heap object in which block is allocated. If block is not an address that is managed by any heap object (it may be NIL or point to stack or global data) return NIL. The pointer returned (if it is not NIL) points to a heap object that the memory heap framework needs and should NOT be deleted by a programmer after he is done using the pointer. Since multiple copies of a heap object may exist, a programmer should not compare pointers of heap objects in order to compare heap objects for equality. Boolean TMemoryHeap::IsWriteEnabled() Return TRUE if write permission is set; return FALSE otherwise. size_t TMemoryHeap::NumberAllocatedBlocks() Return the total number of distinct blocks currently allocated in the heap. This count includes the number of blocks, if any, allocated by the heap for its internal management. Consequently, the block count may be greater than the number of user allocated blocks. void *TMemoryHeap::Reallocate(void *block, size_t newSize) Reallocate the specified block to at least the specified size. In some cases, the block may not be resized, but the block returned will be at least as big as the new size specified. If the address of the block is not in the space managed by this heap object, an exception is raised. If the new size is smaller, the data from the higher address end of the block is lost. The address of a block may change after it is reallocated, even if the new size is smaller than the original size. If the block is NIL, a block of the new size is allocated. static void *TMemoryHeap::ReallocateAny(void *block, size_t newSize) Determine which heap the block is allocated in and reallocate the block in the space managed by that heap object. If the block is not NIL and is not in the address space managed by any heap object, an exception is raised. If the block is NIL, a block of the specified size is allocated in the default heap. The address of a block may change after it is reallocated, even if the new size is smaller than the original size. A programmer should not allocate a block of size zero in a specific heap and later call ReallocateAny and expect the new block to be allocated in the same heap. When a block of size zero is allocated a NIL pointer is returned. When a NIL pointer is passed to ReallocateAny, it allocates the block in the default heap TMemoryHeap : :f gDef aultHeap . void TMemoryHeap::Reset() A fast deletion of all the user allocated blocks in the heap. The heap may still contain blocks that it allocates for its internal management. void TMemoryHeap::SetWriteEnabled(Boolean) Set write permission if TRUE is specified; set read only if FALSE is specified. If write permission is not set, the heap is accessible in read only mode and only the const methods are valid. Invoking non const methods may cause a hardware exception. Boolean TMemoryHeap::GetBlockReuse() Return FALSE if reuse of previously allocated blocks is prohibited; return TRUE otherwise. *

Boolean TMemoryHeap::GetZapOnAllocate() Return TRUE if the contents of newly allocated blocks are set to a certain value; return FALSE otherwise. Boolean TMemoryHeap::GetZapOnFree() Return TRUE if the contents of freed blocks are set to a certain value; return FALSE otherwise. void TMemoryHeap::SetBlockReuse(Boolean) Do not allow reuse of previously allocated blocks if FALSE is specified; allow reuse of previously allocated blocks if TRUE is specified. By default reuse of previously allocated blocks is permitted. This method is a debugging tool. The allocator will cease to delete blocks when block reuse in set to FALSE, in effect causing a storage leak. Furthermore, the blocks can not be reclaimed if and when block reuse is reset to TRUE. void TMemoryHeap::SetZapOnAllocate(Boolean) Initialize the contents of newly allocated blocks to a certain value if TRUE is specified; do not initialize the contents of newly allocated blocks if FALSE is specified. By default the contents of newly allocated blocks are not initialized. This is a debugging tool. void TMemoryHeap::SetZapOnFree(Boolean) Set the contents of freed blocks to a certain value if TRUE is specified; do not set the contents of freed blocks if FALSE is specified. By default the contents of freed blocks are not set to any value. This is a debugging tool. Description of TMemoryHeapIterator methods TMemoryHeapIterator::TMemoryHeapIterator() Constructor. TMemoryHeapIteratoπ-TMemoryHeapIteratorO Destructor. TSurrogateMemory TMemoryHeapIterator::First(EHeapBlockType) Set the mode o the iterator to iterate through the allocated blocks if kAllocated is specified; set the mode of the iterator to iterate through the free blocks if kFree is specified; set the mode of the iterator to iterate through the allocate and the free blocks if kAllocatedAndFree is specified. Subsequent calls to Next() will continue to iterate through the specified block type. Also, return a TSurrogateMemory that describes the first allocated or free block in the heap, depending on the mode of the iterator. The iterator iterates through the blocks in an arbitrary order (not necessarily by address or size). First() returns a TSurrogateMemory for the first block based on thi order. Subsequent calls to Next() will go through the rest of the blocks in the heap. TSurrogateMemory TMemoryHeapIterator::Next() Return a TSurrogateMemory for the next allocated or free block in the heap, depending upon the mode specified in a prior call to First(). If there aren't any blocks that have not already been returned in a prior call to First() or Next(), return a TSurrogateMemory with addres NIL.

Description of TStandardMemoryHeapIterator Methods Refer to the description of TMemoryHeapIterator methods for a description of TStandardMemoryHeapIterator methods. TStandardMemoryHeapIterator is the class provided for iterating through TLocalMemoryHeap or TSharedMemoryHeap objects. It is not intended for subclassing unless the inherited methods are used (which is unlikely).

Description of TStandardMemoryHeap Methods

TStandardMemoryHeap is an abstract base class of TLocalMemoryHeap and TSharedMemoryHeap. It exists to provide the common implementation of

TLocalMemoryHeap and TSharedMemoryHeap. TStandardMemoryHeap is not intended to be subclassed. Programmers should write subclasses of TMemoryHeap.

TStandardMemoryHeap::~TStandardMemoryHeapO Destructor. void TStandardMemoryHeap::InstallHook(TMemoryHook *) Installs a heap instrumentation hook. At most one memory hook can be installed in a single heap. A memory hook must be allocated in the heap to which it refers. When a hook is installed, the hook is informed when blocks are allocated, deleted or reallocated. The hook keeps heap statistics. void TStandardMemoryHeap::RemoveHook(TMemoryHook *) Removes a heap instrumentation hook.

Description of TLocalMemoryHeap Methods TLocalMemoryHeap::TLocalMemoryHeap(size_t) Creates a new local heap of the specified size. Specify 0 for a default large heap size. The heap is accessible only in the address space of the task that created it. The heap may grow larger than its initial size.

TLocalMemoryHeap::TLocalMemoryHeap(const TLocalMemoryHeap &) Creates a copy of the specified local heap object. Both copies refer to the same kernel memory segment.

TLocalMemoryHeap::operator=(const TLocalMemoryHeap &) Assigns this local memory heap object to refer to the same kernel memory segment as the specified local heap object. If this local memory heap object is the last copy of the heap to which it originally referred, it will close the kernel segments to which it originally referred.

TLocalMemoryHeap::~TLocalMemoryHeap() Destructor.

Description of TSharedMemoryHeap Methods TSharedMemoryHeap::TSharedMemoryHeap(size_t) Creates a new shared heap of the specified size. Specify TSharedMemoryHeap::kDefaultSize for a default large heap size.

TSharedMemoryHeap::TSharedMemoryHeap() Creates a new default size shared heap. Use this constructor for stream in. TSharedMemoryHeap::TSharedMemoryHeap(const TSharedMemoryHeap &)

Creates a copy of the specified shared heap object in the current tasks address space.

Both copies of the shared heap object refer to the same kernel memory segment.

TSharedMemoryHeap::~TSharedMemoryHeap() Destructor.

TSharedMemoryHeap::IsWriteEnabled() Return TRUE if write permission for the shared heap is set in the current task; return FALSE if the shared heap is read only in the current task.

TSharedMemoryHeap::IsWriteProtectionModifiable() Return TRUE if the current task can modify the write protection of the shared heap; return FALSE if the current task can not modify the write protection of the shared heap. The write protection is always modifiable in the task that created the shared heap.

TSharedMemoryHeap::SetWriteEnabled(Boolean) Set write permission for the shared heap in the current task's address space if TRUE is specified. Set the shared heap read only in the current task's address space if FALSE is specified. If the write protection of the shared heap is not modifiable and the current task did not create the shared heap, an exception is raised.

TSharedMemoryHeap::SetWriteProtectionModifiable(Boolean) Allow all tasks tha access the shared heap to modify the write protection of the shared heap if TRUE is specified; Only allow the task that created the shared heap to modify the write protection of the shared heap if FALSE is specified.

TSharedMemoryHeap::operator=(const TSharedMemoryHeap &.) Assigns this shared heap object to refer to the same kernel memory segment as the specified shared heap object. If the original shared heap object is the last copy of the heap to which it previously referred in this task's address space, the kernel segments to which it originally referred are closed in this task's address space. TStream& TSharedMemoryHeap::operator »=(TStream&) Writes a description of the shared heap to the stream. In order for two or more tasks to share a heap, one task creates the shared heap. The remaining tasks create a shared heap object. The first task streams out a description of the shared heap. The remaining tasks stream in the shared heap description. The stream in operator opens the heap at the same address in their respective address spaces.

TStream& TSharedMemoryHeap::operator «=(TStream&) Reads a description of shared heap from the stream and opens the heap's memory segments at the same logical address in this task's address space. This task refers to objects in the shared heap using regular pointers.

Subclasses of TMemoryHeap class TMemoryHeap : public MCollectible { public: virtual -TMemoryHeapQ virtual void *Allocate(size_t size) = 0; virtual size_t BlockSize(const void "-block) const; virtual size_t By tes Allocated () const; virtual void Check()const; virtual TMemoryHeapIterator *CreateIterator(); virtual void Free(void *block) = 0; static TLocalMemoryHeap *GetDefaultHeap(); static void GetMemoryHeaps(TCollection &); static TMemoryHeap ΗeapOf(void *block); virtual Boolean IsWriteEnabled() const; virtual unsigned long NumberAllocatedBlocks() const; virtual void *Reallocate(void *block, size_t newSize) = 0; static void *ReallocateAny(void *block, size_t newSize); virtual void Reset() = 0; virtual void SetWriteEnabled(Boolean);

/ / Methods to aid in debugging. virtual Boolean GetBlockReuseQ const; virtual Boolean GetZapOnAllocate() const; virtual Boolean GetZapOnFreeO const; virtual void SetBlockReuse(Boolean); virtual void SetZapOnAllocate(Boolean); virtual void SetZapOnFree(Boolean);

protected: static void AddToGlobalHeapList(TMemoryHeap *); virtual Boolean IsMyBlock(cosnt void *) const = 0; static Boolean RemoveFromGlobalHeapList(TMemoryHeap *);

TMemoryHeapO;

TMemoryHeap(const TMemoryHeap &);

TMemoryHeap& operator =(const TMemoryHeap &); TStream& operator »=(TStream& toWhere) const;

TStream& operator «=(TStream& fromWhere);

Special purpose heaps are implemented as subclasses of TMemoryHeap. The class designer must implement five methods of TMemoryHeap, a copy constructor and an assignment operator, and may choose to implement any or all of the remaining TMemoryHeap methods. The following is a description of what TMemoryHeap overrides should do. The following five methods must be implemented: Allocate, Free, Reallocate,

Reset and IsMyBlock. In addition the programmer must implement a copy constructor and an assignment operator for the TMemoryHeap subclass. void *TMemoryHeap::Allocate(size_t) Allocate a block at least as large the specified size and return the start address of the block. If the size is zero, you may return NIL. However, if you want to support allocations of zero bytes which can later be reallocated in the same heap (using TMemoryHeap::ReallocateAny), you must return a non- NIL value for allocations of zero bytes. Allocated blocks should be long word aligned in order to aid in the portability of the system. void TMemoryHeap::Free(void *block) Deallocate the space for the specified block. void *TMemoryHeap::Reallocate(void *block, size_t size) Reallocate the specified block so that it is at least as large as the specified size and return the address of the reallocated block. If the new size is smaller copy as much of the data as possible, starting at the lower address end of the block. If you want to support the allocation of a zero byte block that can be reallocated in the same heap, then allocate should not return NIL if the requested size is zero. void TMemoryHeap::Reset() A fast deletion of all the user allocated blocks in the heap. The reset method may allocate some blocks in the space that the heap manages for its internal management.

Boolean IsMyBlock(const void *block) Return TRUE if the specified address is in the range of the address space managed by this memory heap; return FALSE otherwise.

When a memory heap is created or destroyed, the new heap must be added removed from the current task's global heap collection. Therefore, the memory heap constructor must add the heap object to the global heap collection by invokin TMemoryHeap::AddToGlobalHeapList() and the memory heap destructor must remove the heap object from the global heap collection by invoking TMemoryHeap::RemoveFromGlobalHeapList(). A master copy of the newly constructed heap is added to the task's global heap collection. Therefore, concrete subclasses of TMemoryHeap must be declared with the

MCollectibleDeclarationsMacroO and must have a valid copy constructor and assignment operator.

Since there can be multiple copies of all concrete subclasses of TMemoryHeap, a user can modify a heap through any instance of the heap.

Therefore, information about the state of a heap should be kept in an area commo to all copies of the heap. For example, the next available address to allocate should be kept in the common area.

The methods BlockSize, BytesAllocated and NumberAllocatedBlocks may or may not be implemented. size_t TMemoryHeap::BlockSize(void "'block) Return the size in bytes of the specified block. The size of a block is the space available to the user; it does not include the space, if any used by the memory heap for internal management. The default implementation always returns zero. size_t TMemoryHeap::BytesAllocated() Return the total number of bytes, includin any bytes used by the memory heap for management of its space, allocated in the address space managed by this heap object. The default implementation always returns zero. unsigned long TMemoryHeap::NumberAllocatedBlocks() Return the total number of distinct blocks allocated in the address space managed by this heap object including the blocks, if any, allocated by the heap itself for internal management of the heap. The default implementation always returns zero. By default, a memory heap is modifiable. However the class designer may choose to support a feature which allows a memory heap to by accessible in read only mode. This may be useful if a programmer wants to set up some initial structures that are not subsequently modified. When a memory heap is in read only mode, only the TMemoryHeap const methods are valid. Non-const TMemoryHeap methods should raise an exception if they are invoked when the heap is in read only mode. The methods SetWriteEnabled and IsWriteEnabled must be implemented if the class designer wishes to allow modification to the writ protection of a memory heap. Boolean TMemoryHeap::IsWriteEnabled() Return TRUE if the memory heap is accessible in read /write mode; return FALSE if the memory heap is accessible in read only mode. The default implementation always returns TRUE. void TMemoryHeap::SetWriteEnabled(Boolean ) If TRUE is specified, set the memory heap so that it is accessible in read /write mode; if FALSE is specified, set the memory heap so that it is accessible in read only mode. Return the read /write mode of the heap prior to the change. The default implementation does nothing. A class designer may choose to support methods to help programmers debug. The following are methods to help in debugging: Check, SetZapOnAllocate, GetZapOnAllocate, SetZapOnFree, GetZapOnFree, SetBlockReuse and GetBlockReuse. The designer may implement any number of these methods, however Set/Get methods should be implemented in pairs. void TMemoryHeaρ::Check() Run a heap consistency check to detect corruption of the heap's internal state. Raise an exception if any inconsistencies are found. The default implementation does nothing. Boolean GetZapOnAllocateO Return TRUE if newly allocated blocks are set to some specific value. Return FALSE otherwise. The default implementation always returns FALSE. void SetZapOnAllocate(Boolean) If TRUE is specified, from this point onwards, the contents of newly allocated blocks are set to some specific value. This value should be chosen so that it is easily recognizable in a debugger. If FALSE is specified, from this point onwards, do not set the contents of newly allocated blocks. The default implementation does nothing.

Boolean GetZapOnFreeO Return TRUE if freed blocks are set to some specific value. Return FALSE otherwise. The default implementation always returns FALSE. void SetZapOnFree(Boolean) If TRUE is specified, from this point onwards, the contents of freed blocks, except the space, if any, used by the memory heap for managing the block, should be set to some specific value. This value should be different than the value for allocated blocks and should be easily recognizable in a debugger. If FALSE is specified, from this point onwards, do not set the contents of freed blocks. The default implementation does nothing. Boolean GetBlockReuseO Return TRUE if previously allocated blocks can be reallocated; return FALSE if previously allocated blocks can not be reallocated. The default implementation always returns TRUE. void SetBlockReuse(Boolean) If FALSE is specified, from this point onwards, calls to Free should not deallocate blocks. This method causes a storage leak, and should only be used for debugging purposes. If freed blocks are not deallocated, they will not be reallocated. If TRUE is specified, from this point onwards, calls to Free should resume deallocating blocks. The default implementation does nothing. A class designer may choose to add a heap iterator for his class. A memory heap iterator object goes through either the allocated or the free blocks in a memory heap A memory heap is a non ordered collection of allocated and free blocks. The heap iterator traverses the memory heap and returns the address of each distinct allocated or free block. The class designer must define a subclass of TMemoryHeapIterator for his memory heap class.

TMemoryHeapIterator *CreateIterator() Create an iterator for this memory heap and return a pointer to the iterator. The default implementation returns a pointer to a TMemoryHeapIterator object. The First() and Next() methods of TMemoryHeapIterator always return NIL. Constructor The constructor has one parameter, a pointer to the memory heap which it iterates through. Initialize the memory heap iterator. Destructor Destroy the memory heap iterator.

TSurrogateMemory TMemoryHeapIterator::First(EHeapBlockType) Set the mode of the iterator to iterate through the allocated blocks if the specified block type is kAllocated; set the mode of the iterator to iterate through the free blocks if the specified block type is kFree; set the more of the iterator to iterate through the allocate and the free blocks if kAllocatedAndFree is specified. Return the address of the first allocated or free block, depending upon the mode of the iterator. If the mode is kAllocated and there are no allocated blocks in the heap, return a TSurrogateMemory with address NIL. If the mode is kFree and there is no free space in the heap, return a TSurrogateMemory with address NIL. If the mode of the iterator is kAllocatedAndFree and there are no allocated or free blocks in the heap, return a TSurrogateMemory with address NIL. Subsequent calls to Next() will return blocks of the specified type in an arbitrary order.

TSurrogateMemory TMemoryHeapIterator::Next() Return the address of the next allocated or free block in the memory heap, depending upon the mode of the iterator. The mode of the iterator was set in a prior call to First(). If the iterator mode is kAllocated and there aren't any allocated blocks that have not already been returned in a prior call to First() or Next(), return a TSurrogateMemory with address NIL. If the iterator mode if kFree and there aren't any free blocks that have not already been returned in a prior call to First() or Next(), return a TSurrogateMemory with address NIL. If the iterator mode is kAllocatedAndFree and there aren't any allocated or free blocks that have not already been returned in a prior call to First() or Next(), return a TSurrogateMemory with address NIL. The iterator should be in sync with the heap that it is traversing. If there is a modification to the heap (allocate, free, reallocate, reset) that invalidates the iterator, an exception should be raised. A TMemoryHeap subclass can get TMemoryHook support by implementing methods to install and remove the TMemoryHook. When the hook is installed the memory heap object must inform the hook when it allocates, frees, reallocates or resets the heap. The memory hook keeps statistics on heap usage. TMemoryHook is the abstract base class for memory hooks; TStandardMemoryHook is not intended to be subclassed unless the inherited methods are called. For more information refer to the description of TMemoryHook. A TMemoryHeap subclass only needs streaming operators if the subclass heap can be shared by two or more tasks. The streaming operators should stream only a description of the kernel memory segments that the heap manages. The stream in operator should then open the appropriate memory segments and add the heap object to the set of heaps accessible to the current task.

While the invention has been described in terms of a preferred embodiment in a specific system environment, those skilled in the art recognize that the invention can be practiced, with modification, in other and different hardware and software environments within the spirit and scope of the appended claims.

Claims

CLAIMSHaving thus described our invention, what we claim as new, and desire to secure by Letters Patent is:

1. An apparatus for memory allocation comprising: (a) processor means; (b) storage means attached to the processor means; (c) a system level memory allocation framework for creating and managing heap objects, including means for receiving memory allocation requests from an application; (d) at least one object for performing at least one memory allocation function with respect to at least one heap; and (e) an application for requesting memory allocation framework operations.

2. The apparatus of claim 1, wherein the at least one object includes memory descriptors to one or more heap segments.

3. The apparatus of claim 1, wherein the at least one object provides an interface to a local heap for use by a single task.

4. The apparatus of claim 3, wherein the at least one object is a default object for the task.

5. The apparatus of claim 2, wherein the task also uses other heaps.

6. The apparatus of claim 1, wherein the at least one object provides an interface to a shared heap shared by more than one task.

7. The apparatus of claim 6, wherein the shared heap may accommodate one or more objects.

8. The apparatus of claim 6, wherein the shared heap is created by a task, and the task comprises means for determining write permission with respect to the shared heap.

9. The apparatus of claim 1, wherein the at least one object provides special purpose memory allocation features.

10 The apparatus of claim 1, wherein the system level memory allocation framework includes an allocator for performing allocation associated with the heaps using the heap objects.

11. The apparatus of claim 1, wherein the system level memory allocation framework includes a deleting support for performing deletions associated with the heaps using the heap objects.

12. The apparatus of claim 1, wherein the system level memory allocation framework includes a reallocation support for performing reallocation associated with the heaps using the heap objects.

13. The apparatus of claim 1, wherein the system level memory allocation framework includes a finder for determining a pointer to a heap.

14. The apparatus of claim 1, wherein the system level memory allocation framework includes a determiner of accessible heaps.

15. The apparatus of claim 1, wherein the system level memory allocation framework includes at least one debugging aid for assisting debugging of the memory.

16. The apparatus of claim 15, wherein the debugging aids include a value setter which sets heap contents to a particular value upon an allocation operation.

17. The apparatus of claim 15, wherein the debugging aids include a value setter which sets heap contents to a particular value upon an deallocation operation.

18. The apparatus of claim 15, wherein the debugging aids include a reuse prohibiter for prohibiting reuse of certain heaps.

19. The apparatus of claim 15, wherein the system level memory allocation framework includes heap iterator support.

20. A method for memory allocation operations comprising: providing a system level memory allocation framework for creating and managing heap objects in a storage means; receiving memory allocation framework requests from an application; creating at least one heap object in the storage means; and interfacing with at least one memory segment using the heap object in response to the memory allocation request.

21. The method of claim 20, wherein the step of interfacing includes interfacing with a single task.

22. The method of claim 21, wherein the at least one object is a default object for the task.

23. The method of claim 21, wherein the step of interfacing includes interfacing between the task and other heaps.

24. The method of claim 20, wherein the step of interfacing includes interfacing with a shared heap shared by more than one task.

25. The method of claim 24, including storing one or more objects within the shared heap.

26. The method of claim 24, including creating a shared object by a task, and determining write permission with respect to the shared heap by the task which created the object.

27. The method of claim 20, including providing at least one heap object having special purpose memory allocation features.

28. The method of claim 20, including a step of allocating memory associated with the heaps using the heap objects.

29. The method of claim 20, including a step of deleting associated with the heaps using the heap objects.

30. The method of claim 20, including a step of reallocating associated with the heaps using the heap objects.

31. The method of claim 20, including a step of determining a pointer to a heap.

32. The method of claim 20, including a step of determining accessible heaps.

33. The method of claim 20, including providing debugging aids for debugging of the memory.

34. The method of claim 33, including a step of setting heap contents to a particular value upon an allocation operation.

35. The method of claim 33, including a step of setting heap contents to a particular value upon a deallocation operation.

36. The method of claim 33, including a step of prohibiting reuse of certain heaps.

37. The method of claim 20, including a step of iterating through the heaps.