Object surrogate with active computation and probablistic counter

OBJECT SURROGATE WITH ACTIVE
COMPUTATION AND PROBABILISTIC
COUNTER

BACKGROUND OF THE INVENTION 5

This invention relates generally to referencing objects in a programming environment and more specifically to an object surrogate that manages references and active computations on the object.

J lu

BACKGROUND

Two common problems which occur in object oriented programming languages such as C++, are memory leaks and dangling pointers. A memory leak occurs when memory 15 space is allocated for an object but never released after use. A dangling pointer points to a destroyed object or freed memory region. After an object is dynamically destroyed, any subsequent attempt to reference the destroyed object using the dangling pointer can have unpredictable and often 20 disastrous results. For instance, if a reference to a destroyed object is used, the memory space can become corrupt and potentially cause the computer program, and perhaps the computer itself, to crash. These problems become even more pronounced in multi-threaded applications, particularly 25 applications where an object has "suicide" methods (methods where an object will delete itself).

It is difficult to dynamically determine whether a pointer or reference refers to a destroyed or invalid object. In the prior art, other programming languages use garbage collec- 30 tion to prevent memory leaks and dangling pointers. Garbage collection automatically reclaims any storage not referenced within the program. Such routines are unsuitable for C++ for several reasons. First, garbage collection is not an explicit feature of the C++ language and must therefore be 35 implemented by a library or non-portable extension. As a stack based language, C++ is particularly unsuited to librarybased garbage collection because of the inability to identify all currently active pointers. Second, effective garbage collection routines are difficult to write and tend to restrict 40 objects to heap-based allocation which can introduce unacceptable memory and performance overhead.

Within the C++ language, one commonly used prior art technique for addressing the dangling pointer problem is to put the burden on the programmer to structure the logic of the program to avoid references to destroyed objects. This is extremely error-prone especially in multi-threaded applications.

Another prior art technique uses a reference count to keep 50 track of existing references to each object. The reference count is updated whenever a pointer to the object is created, copied or deleted. When the reference count goes to zero, the object itself is deleted. Unfortunately, reference counting cannot be used to reclaim regions of memory formed by 55 chains of objects forming circular dependencies. In addition, reference counted objects are generally restricted to be allocated on the heap.

Another prior art technique embeds a list of "backpointers" within each object. Each backpointer points to an go external pointer which refers back to that object. When the object is destroyed, all references pointed to by the object's backpointer are invalidated. However, backpointers impose a large memory overhead and a substantial performance penalty. 65

In a multi-threaded environment, undefined program behavior can occur when an object is destroyed in one thread

45

while another thread continues to reference the object. This situation is particularly problematic when the second referencing thread is executing within a method defined within the destroyed object. One prior art technique for solving this problem uses a mutual exclusion ("mutex") mechanism to ensure that only one thread of control at a time is executing within the object. Obviously this limits the amount of parallelism that can be achieved.

In multi-threaded environments, all of the foregoing mechanisms rely on mutual exclusion mechanisms for correctness. Locking and unlocking such mutexes (without underlying hardware support) can pose an unacceptable performance penalty in time-critical sections of code.

Accordingly, a need remains for a fast and efficient technique with low overhead for preventing dangling pointers while ensuring mutual exclusion in potentially multithreaded environments.

SUMMARY OF THE INVENTION

To prevent dangling pointers, an object is annotated with a reference counted Object Surrogate which will outlive the object and which knows whether the referenced object is valid or not. Rather than directly referring to the underlying object, long lived external pointers (those which exist outside of an active computation) are maintained as pointers to the object surrogate.

The object surrogate maintains a count of the number of active computations executing within the object. While there are active computations executing within the object, the object surrogate will not allow the object to be destroyed. The object may ask its surrogate to consider the object invalid to prevent new active computations from starting. This is done within the object's destructor. To allow an object to delete itself (potentially within an active computation) rather than deleting itself explicitly, the object requests of its object surrogate that the object be deleted when the number of active computations hits zero.

Active computations are counted using techniques that ensure accurate results particularly in multi-threaded programming environments. One technique, uses a mutex to protect the active computation counter. This counter is incremented when an active computation begins executing on an object and is decremented when the active computation completes.

In another technique, the active computation count comprises multiple counters. One of the multiple counters is selected pseudo-randomly and incremented when a new active computation begins executing on the object. A token referring to the selected counter is passed to the caller initiating the new computation. The token is passed back to the object surrogate to allow the appropriate counter to be decremented when the active computation completes. The count of active computations is considered to be zero only when all counters equal zero.

In a variation of the previous technique, the counter that was decremented does not necessarily have to be the counter that was incremented. The counter can be chosen randomly or sequentially. The count of active computations is considered to be the sum of the multiple counters, any of which may be negative. An invariant on the object surrogate class ensures that such a sum will be accurate when it would be zero.

To ensure accurate tracking of the correct number of computations in the face of exceptions and returns, the maintenance of the count of active computations is encapsulated within the constructor and destructor of an object which is placed on the stack. C++ semantics ensure that the destructor is called (and the count decremented) when the enclosing block is exited.

The foregoing and other objects, features and advantages of the invention will become more readily apparent from the 5 following detailed description of a preferred embodiment of the invention which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a temporal diagram showing the lifetime of an 10 active computation.

FIG. 2 is a schematic diagram showing the use of an object surrogate class in a programming environment according to the invention.

FIG. 3 is a use diagram showing the interactions of the

components in a mark for delete invocation, according to

the invention.

FIG. 4 is a schematic diagram of an index counter and multiple computation counters for tracking active computa- 2o tions on an object.

FIG. 5 is a block diagram of an object surrogate located in memory of a computer system.

DETAILED DESCRIPTION

25

Referring to FIG. 1, an active computation is a temporally bounded region (X5 or X6) of a thread of control (XI or X2) relating to one or more uses (X3A-C or X4A-C) of an object 14. It is important that the object 14 not be destroyed within the active computation region X5 or X6. 30

FIG. 2 is a schematic diagram showing the use of an object surrogate class in a programming environment 12 according to the invention. Preferably, the programming environment 12 supports objects 14 (one shown in FIG. 1) such as in the C++ programming language, although other programming languages, especially object-oriented languages, would be equally suitable. The object surrogate class is loaded into a memory 54 of a computer system 56 (FIG. 5).

Each such object 14 is annotated with an instance of an 40 object surrogate class 16 (hereinafter "object surrogate" or "surrogate") using a pointer 13b. Any reference 24 logically to the object 14 except those within an active computation X5 or X6 (FIG. 1) will instead refer to the object surrogate 16 (this includes references kept on a stack or in other data 45 structures). Other references may also be given the privileged status of holding the direct reference, for example those which have explicit knowledge of the lifetime of the object. Such an optimization should be done with extreme care. In the preferred embodiment, an object's surrogate 16 50 is not created until an external reference to the object is required. This is strictly an optimization removing the need to create surrogates for objects that are never exposed.

The object surrogate 16 is a reference counted object. The count includes all references to the object surrogate includ- 55 ing the one 13b from the object 14. It is important that this count be maintained correctly. In a multi-threaded program this may imply the use of a mutual-exclusion mechanism. Because the object surrogate 16 is reference counted, it is guaranteed to remain valid as long as there are any refer- 60 ences to it.

The object surrogate 16 is a surrogate for a particular object 14 and holds a reference to that object as a pointer 13a. When the object becomes invalid, the object surrogate's 16 invalidate method is called and thereafter the 65 object surrogate 16 is considered to not refer to any valid object.

It is important that the pointer 13a from the object surrogate 16 to its referenced object 14 is not considered a counted reference for purposes of determining the object's lifetime. If this were not the case, a circular reference would occur between the object surrogate 16 and the object 14 and neither would be deleted using normal reference counting semantics. One manner for controlling deletion of the object surrogate is by using a garbage collection routine.

When a thread of control XI (FIG. 1) is within an active computation X5, the thread of control will need to make calls directly on an object 14. Within the region of active computation X5, the thread XI may ask the object surrogate 16 for a pointer which refers directly to the object 14 by means of a valid object( )method in the object surrogate.

If the object surrogate 16 refers to valid object 14 it will return a pointer 13a to the object 14 otherwise it will return a NULL pointer. In an alternative embodiment, instead of returning a NULL pointer an exception may be raised.

The object 14 presents an exposed interface which consists of a set of functions which may be invoked using the pointer to the object returned by the object surrogates valid object( ) method.

If within an active computation X5, an object surrogate's

16 valid object( ) method returned a non-null pointer to a

valid object 14, it is important that said object is not destroyed before the end of the active computation X5. To guarantee this invariant, before the object's 14 destructor preforms any action (such as releasing memory or other resources) which would render the object incapable of supporting a function on an exposed interface. The object 14 must call its object surrogate's invalidate( ) method. This method will not return as long as there are any active computations currently executing on the object. This guarantees that during an active computation the pointer returned

by valid object( ) will not be a dangling pointer. This

invariant allows objects 14 to be allocated on the stack. If the block enclosing a stack based object 14 is exited, the thread will block until all active computations X5 on the object are completed.

In order to determine when there are no active computations on an object 14, the object's surrogate 16 maintains a count of the number of active computations. This count (#

computations in FIG. 2.) is incremented by a call to add

computation( ) and decremented by a call to delete

computation( ). To ensure that the count is maintained correctly even in the face of exceptions or returns, the existence of an active computation X5 is indicated by the lifetime of an ActiveComputation object (18,20,22). This ActiveComputation object maintains a reference to the object surrogate 16 and the ActiveComputation's (18,20,22)

constructor and destructor call the surrogate's add

computation( ) and delete computation( ) methods respectively. ActiveComputation objects (18,20,22) are normally instantiated on the stack. In this manner, normal C++ semantics can be used to guarantee that an active computation X5 is maintained from the creation of the ActiveComputation object (18,20,22) to the end of the enclosing block.

A particularly tricky case to handle in a multi-threaded system is that of an object which wants to destroy itself (in C++ this is done by calling delete this). If such a call were made in the system described above and the current thread was in an active computation X5 on the object 14 which is attempting to delete itself, this would lead to an immediate deadlock. The object's 14 destructor will call the surrogate's 16 invalidate( ) method. The invalidate( ) method will block until there are no active computations on the object 14. 5

However, since one of the active computations is the current blocked thread, the number of active computations will never reach zero.

To handle this situation, objects 14 are forbidden to delete themselves unless they can guarantee that the current thread 5 is the only active computation (or there are no active computations on the object). Instead, of calling delete( ), the

object calls its object surrogate's mark for delete( )

method. The mark for delete( ) method will cause the

object surrogate 16 to consider the object 14 it refers to as 1° invalid. Note, this cannot be accomplished by calling the invalidate( ) method as this would lead to the deadlock

which the mark for delete( ) method prevents. The object

surrogate 16 also sets a flag within itself (delete on exit in

FIG. 2). When the count of active computations reaches :5

zero, if the delete on exit flag is set, the object 14 is

deleted.

FIG. 3 shows a trace of a use of mark for deleteo within

an active computation. In step 26, thread X I creates an ActiveComputation object 18 (FIG. 2) on the stack. In step 20 28, the ActiveComputation object's 18 constructor calls the

surrogate's 16 add computation( ) method. The add

computation( ) method increments the number of active computations marking the beginning of an active computation X5 (FIG. 1). In step 30, sometime later, but within the 25 lifetime of the ActiveComputation object 18 (i.e., the current

block), thread XI invokes the object surrogate's 16 valid

object( ) method which returns a pointer to the object 14. Step 32, still later, but again within the lifetime of the ActiveComputation object 18, thread XI invokes a 30 "suicide"( ) method in object 14. The suicide s method is an example of a method in which the object 14 will destroy itself. In step 34, within the suicide method, the object 14

calls its surrogate's 16 mark for delete( ) method. Since

there is at least one active computation X5, the object 14 35 cannot be deleted yet.

Instead, the surrogate 16 records the request and returns. The implementation must ensure that a subsequent call to

valid object( ) will not return a pointer to the object 14. The 4Q

"suicide( )" method then returns in step 36. In step 38, the block enclosing the ActiveComputation object 18 is exited. This causes the ActiveComputation's 18 destructor to fire

which calls the surrogate's 16 delete computation( )

method in step 40. This ends this active computation X5. 4J Assuming this was the only active computation at this point, the surrogate's 16 count of active computations will now be zero. Since the object 14 had requested that it be deleted, the surrogate 16 will now do so in step 42 and clear its flag to ensure that the object is not deleted twice should another 5Q computation be created and destroyed. Deleting the object will invoke the object's destructor which in step 44 will call the surrogate's 16 invalidate( ) method. Since there are no active computations executing, the invalidate( ) method will return. 55

If there had been other active computations on the object 14 in step 40, then the count would not have gone to zero and the surrogate 16 would not have deleted the object 14. The deletion would be postponed until the final active computation had completed and the count had gone to zero. 60

In a multi-threaded environment correctness is dependent on the accuracy of the reference count and active computation count. Traditionally, such accuracy is achieved by bracketing the operations on the count with the lock and unlock of a mutual exclusion object. In practice, a mutex 65 guarded counter may impose performance penalties which are unacceptable for some time- critical applications.

6

An alternative to a mutex guarded counter is a probabilistic counter. While this cannot guarantee that the count is accurate, the likelihood of it being inaccurate can be made arbitrarily small. In one embodiment, as shown in FIG. 4 a probabilistic 49 counter is implemented as an array 52 of non-negative integers (or equivalent data structures). These integers are initialized to zero. To increment the probabilistic counter, an index of the array is selected randomly (or pseudo- randomly) and the associated integer is incremented. The increment method returns to its caller an opaque token containing the index which was used. To decrement the probabilistic counter, the original token is handed back and the associated integer is decremented. The value of the probabilistic counter is considered the sum of the integers. In most multi-threaded environments, the sum cannot be performed atomically without requiring some additional mutual exclusion mechanism (which is what the probabilistic counter is trying to avoid).

For the purpose of maintaining an object's surrogate's 16 count of active computations X5, however, five simplifying assumptions can be made. First, the only requirement on the counter is that it be eventually detectable that it has hit zero. Second, the only time that the value of the counter is

checked is on an invalidate( ) call or on a delete

computation( ) when the mark for delete flag has been set.

Third, a thread XI cannot request valid object( ) until it has

completed calling add computation( ). Fourth, once the

surrogate 16 has flagged its object 14 as invalid, the surrogate will never refer to a valid object again. Fifth, when

mark for delete( ) and invalidate( ) are called, they first

cause the surrogate 16 to consider its associated object invalid. These assumptions are sufficient to guarantee correctness in the absence of thread swap causing an incorrect addition in one of the underlying integers.

Consider the situation in which mark for delete( ) has

previously been called on a surrogate 16. By assumption 3

and 4, threads which call valid object( ) on this surrogate

16 will always receive a null pointer. If there is currently exactly one active computation X5, all but one of the integers will be zero and the remaining integer will have a

value of 1. When delete computation( ) is called, three

situations must be considered. In scenario 1, the call to

delete computation( ) completes without an intervening

add computation( ). In this case, the summation of the

integers within delete computation( ) will discover that the

integers are all zero and the object 14 will be deleted.

In scenario 2, during delete computation( ), add

computation( ) is called by another thread X2 and the integer chosen to increment has not yet been considered as part of

the sum being computed by the delete computation( ). In

this case, the delete computation( ) will consider that there

is still one active computation and will not consider the sum 0. Thus the object 14 will not deleted until this new computation X6 calls delete computation( ).

In scenario 3, during delete computation( ), another

thread X2 calls add computation( ) and the integer chosen

to be incremented has already been considered in the summation in delete computation( ). In this case, the count will

be considered to be 0, and the object 14 will be deleted. This does not cause problems because given the assumptions (3 & 4) it is impossible for the new computation X6 to obtain a pointer to the deleted object 14. It is imperative, however, that the surrogate 16 be implemented to not attempt to delete the object 14 when this new computation concludes. This

can be accomplished by clearing the mark for delete flag

or clearing the pointer 13a.

In an alternative embodiment, the integers 52 need not be non-negative integers and the integer chosen for add