Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1999-12-10
2003-09-23
Dam, Tuan Q. (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S158000, C707S793000
Reexamination Certificate
active
06625808
ABSTRACT:
TECHNICAL FIELD
This invention generally relates to memory management and, in particular, to a method and apparatus for facilitating memory management among heterogeneous elements of a program.
BACKGROUND OF THE INVENTION
Legacy programming languages such as, for example, the Pascal, Fortran and C languages are well known. Developing source code using one of these legacy programming languages typically requires a programmer to embed instructions within their code to “manually” manage the memory resources of the executing computer. That is a programmer writing source code in one of these legacy languages must embed instructions within the code to allocate memory to support objects created during execution of the program, and must subsequently explicitly reclaim these resources when the stored object is no longer required. For small programs this manual memory management is an inconvenience for the programmer, but typically not overwhelming. However, as the size of a program and the number of simultaneously executing threads of a program increase, the programmer has a heightened burden to reclaim memory resources when the objects stored within such resources are no longer required by the program, i.e., “garbage” or “dead” objects.
Failure to reclaim memory allocated to dead objects may well result in the all too-familiar memory “overflow” and “out of memory” conditions leading to the premature conclusion of an executing program. Historically, the manual management of memory resources, i.e., comprising static memory, stack memory and/or the heap, depending on the data structures employed by the programming language, has been prone to error for all but the most experienced and skilled programmers.
To alleviate this burden of memory management, more advanced programming languages have been developed that include automated memory management functions. Languages such as the Java™ language by Sun Microsystems, the Standard ML (SML) language developed at Edinburgh University and implemented by Bell Laboratories (now Lucent Technologies), and the well-known LISP programming language developed at the Massachusetts Institute of Technology (MIT) each include automated memory reclamation functions within their runtime environment. In general, memory for objects (i.e., software “bundles” of variables and related methods) is explicitly allocated on the heap by the program and implicitly reclaimed by a function of the runtime environment (e.g., the Java™ Virtual Machine) when no longer needed. This process of implicitly reclaiming memory resources from dead objects is colloquially referred to as garbage collection.
Typically, the garbage collection function is implemented as an implicit function of the memory allocation function. That is to say, when a program attempts to create an object, the runtime environment accesses a “list” to ensure that adequate heap memory is available. If, while attempting to create an object it is determined that inadequate heap memory exists, the runtime environment invokes the garbage collection function to identify “dead” objects, i.e., those objects no longer reachable by the program, and reclaim such memory for use by future objects.
A number of different garbage collection techniques exist, e.g., “copying” garbage collectors, “mark-and-sweep” garbage collectors and “generational” garbage collectors to name a few. Although the techniques employed by these garbage collectors vary from one to another, they each generally employ a two-step garbage collection process of: (1) identifying dead objects on the heap; and (2) reclaiming memory associated with the dead objects.
To identify dead objects, the garbage collector performs a function colloquially referred to as “walking the stack” for each thread within a program. To walk the stack, the garbage collector analyzes the “root set”, i.e., the static registers and stack memory for each thread of a program, to identify pointers to objects stored on the heap. The garbage collector follows these pointers to the objects within the heap, and follows any pointers embedded therein to further objects. In this way, the garbage collector may traverse several layers of object pointers to identify all live objects. It stands, therefore, that all objects which are not ultimately traceable back to the root set are unreachable by the program, i.e., a dead object, and is subject to garbage collection.
To reclaim memory from dead objects, the address(es) for memory allocated to dead objects are added to the list of available heap memory. Thus, when the program attempts to create a new object and the list is accessed, the heap memory currently allocated to a dead object is overwritten with the new “live” object.
Programming languages, such as the advanced programming languages introduced above, which include automated memory management features such as, for example, garbage collection, are often referred to as garbage collected languages. In contrast, programming languages that do not include this automated garbage collection feature. e.g., the legacy programming languages introduced above, are typically referred to as non-garbage collected languages.
Typical of innovations of convenience, the prevailing thought when these advanced programming languages were first developed is that they would be so widely accepted and embraced by the development community that they would replace the legacy programming languages, rendering code developed in legacy programming languages obsolete. Indeed, the advanced programming languages were and are widely embraced in the development community. However, experience shows that it is often more convenient, and sometimes necessary, to utilize code written in legacy programming languages than to attempt to “re-write” the code using an advanced language. For example, it may be more convenient or necessary for a program written in a garbage collected language to call an application program interface (API), or dynamic linked libraries (DLL) written in C/C++. Recognizing this need, nearly every runtime environment for an advanced programming language now provides a foreign function interface to support calls to “foreign functions” (e.g., API's, DLL's and the like) written in legacy code.
Typically, the foreign function interface is an array of pointers to legacy functions, loaded as a library in the advanced programming language for the application. When making a call to a foreign function, the calling application typically provides an address to a re-entry point within the application. It must be appreciated by the developer utilizing the foreign language function call that when the call is made to the foreign function, the runtime environment for the advanced programming language is “suspended” while the foreign function executes. As a consequence, the automated memory management facilities of the advanced programming language are similarly suspended. Any memory management that is performed during execution of the foreign function is in response to explicit memory management commands embedded within the foreign function. Insofar as the foreign function employs data structures that are different from, yet occupy the same address space as, the data structures of the advanced programming language, it is probable that the manual memory management of the foreign language function will corrupt pointers to objects stored within the heap, especially if the objects are utilized or referenced by the foreign function. As described above, the garbage collection function relies on such pointers to identify live objects on the heap. At best, corruption of the pointers retards the garbage collectors ability to reclaim memory from dead objects and, at worst, the corruption of the pointers may eliminate a reference to a live object that will be needed during the subsequent execution of the program. Indeed, the foreign function may even corrupt the objects themselves as it allocates and reclaims memory in support of its execution.
Currently, none of the foreign function interfaces associated with these
Dam Tuan Q.
Lee & Hayes PLLC
Microsoft Corporation
LandOfFree
Method and apparatus for facilitating memory management in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for facilitating memory management in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for facilitating memory management in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3031047