Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS6125434 A
Publication typeGrant
Application numberUS 09/081,359
Publication dateSep 26, 2000
Filing dateMay 19, 1998
Priority dateMay 19, 1998
Fee statusPaid
Also published asDE69909021D1, DE69909021T2, EP0959409A1, EP0959409B1
Publication number081359, 09081359, US 6125434 A, US 6125434A, US-A-6125434, US6125434 A, US6125434A
InventorsBrian Alan Willard, Ophir Frieder
Original AssigneeNorthorp Grumman Corporation
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Dynamic memory reclamation without compiler or linker assistance
US 6125434 A
Abstract
A method of dynamic memory reclamation for reclaiming memory leaks is disclosed, in which inaccessible heap segments are reclaimed without recompilation or relinkage of an application. The method comprises intercepting a call from an application to allocate or deallocate a heap segment, forwarding the call to the memory manager, passing the memory allocation and deallocation information from the memory manager to a file, performing a conservative garbage collection process using the memory allocation and deallocation information in the file to detect inaccessible heap segments, and calling to the memory manager from the file to deallocate the inaccessible heap segments. These steps are repeated periodically.
Images(2)
Previous page
Next page
Claims(7)
What is claimed is:
1. A method for dynamic memory reclamation in a computer having a memory containing a heap, and at least one of an operating system with a dynamic memory manager, and a language runtime environment with a dynamic memory manager, wherein an application program sends requests for memory allocation and deallocation to the dynamic memory manager, said method comprising the steps of:
a) emulating the interfaces of the dynamic memory manager by an interface module, the interface module being disposed separate from and operating independent of the application program;
b) intercepting a request for memory allocation or deallocation from the application to the dynamic memory manager by the interface module;
c) generating a request that is transmitted from the interface module to the memory manager, as if sent directly from the application, which then performs the application's requested memory allocation or deallocation, wherein memory allocation/deallocation information is created;
d) communicating the memory allocation/deallocation information to the interface module;
e) maintaining a list of allocated heap memory segments from the allocation/deallocation information in the interface module;
f) performing a conservative garbage collection process, without rebuilding the application program, using the list of allocated heap memory segments in the interface module to detect inaccessible heap memory segments;
g) receiving a request for memory deallocation from a reclamation module by the interface module;
h) generating a request that is transmitted from the interface module to the memory manager, as if sent directly from the reclamation module to deallocate the inaccessible heap segments;
i) deallocating the heap segments in the dynamic memory manager, wherein memory allocation/deallocation information is created;
j) communicating the memory allocation/deallocation information back to the interface module; and
k) updating the list of allocated heap memory segments in the interface module.
2. The method of claim 1 wherein the garbage collection process is performed periodically.
3. The method of claim 1 wherein the conservative garbage collection process comprises a conservative mark/sweep garbage collection process.
4. The method of claim 3 wherein the conservative mark/sweep garbage collection process comprises the steps of:
a) locating memory locations that contain values that correspond to addresses of allocated heap memory segments, wherein each address conservatively identifies an accessible allocated heap memory segment;
b) marking each accessible allocated heap memory segment on the list of allocated heap memory segments;
c) scanning the list of allocated heap memory segments; and
d) identifying unmarked heap memory segments as inaccessible heap memory segments.
5. A dynamic memory reclamation system in a computer having a memory, and at least one of an operating system with a dynamic memory manager and a language runtime environment with a dynamic memory manager, wherein an application program sends request to the dynamic memory manger to allocate and deallocate heap segments, said reclamation system comprising:
a) an interface module that intercepts the requests from an application and forwards the request to the dynamic memory manager, the interface module being disposed separate from and operating independent of the application program;
b) memory allocation and deallocation information generated by the dynamic memory manager in response to the requests, the memory allocation and deallocation information being sent to the interface module and to the application;
c) a list of allocated heap segments maintained in the interface module;
d) a reclamation module, which performs a conservative garbage collection process using the list of allocated heap segments to detect inaccessible heap segments, and sends a deallocation request to the interface module to deallocate the inaccessible heap segments, wherein the interface module forwards the deallocation request to the dynamic memory manager, the dynamic memory manager communicates back to the interface module, the allocation/deallocation information, and the interface module then updates the list of allocated heap segments, whereby the inaccessible heap segments are reclaimed without rebuilding the application program.
6. The dynamic memory management system of claim 5 wherein the conservative garbage collection process comprises a conservative mark/sweep garbage collector.
7. The dynamic memory management system of claim 5 wherein the reclamation module performs the conservative garbage collection process periodically.
Description
FIELD OF THE INVENTION

This invention relates generally to a method for dynamic memory management in a computer, and more particularly to a method of dynamic memory reclamation that detects and reclaims memory leaks without recompiling or relinking an application.

BACKGROUND OF THE INVENTION

Computer systems may manage computer memory dynamically. Dynamic memory management refers to the process by which blocks of memory are allocated temporarily for a specific purpose and then deallocated when no longer needed for that purpose. Deallocated blocks are available for reallocation for another purpose. The process that dynamically manages the memory is referred to as the memory manager. The memory that the memory manager manages is referred to as a "heap." When an application program needs a block of memory to store data, the program sends a request to the memory manager. The memory manager allocates a block of memory in the heap to satisfy the request and sends a pointer to the block of memory to the program. The program can then access the block of memory through the pointer.

In the case of programs written in certain languages, such as C++, blocks of memory can be allocated automatically or dynamically. Automatic memory blocks are automatically allocated when a procedure is entered and automatically deallocated when the procedure is exited. Conversely, dynamic memory blocks are allocated by an explicit call to the memory manager and deallocated by either an explicit call to the memory manager or automatically through a memory reclamation technique known as garbage collection. Typically, automatically allocated memory blocks are stored in a stack and dynamically allocated memory blocks are stored in a heap.

A program can only access a dynamic memory block through a pointer. A pointer is a memory location that contains the address of an allocated (or used) heap segment. If the program overwrites a pointer, then the corresponding heap segment becomes "inaccessible" to the program. An allocated heap segment may be pointed to by several pointers, located on the stack or in another allocated heap segment. Only when all the pointers are overwritten, or are part of another inaccessible heap segment, does the heap segment become inaccessible. A program cannot retrieve data from or write data to an inaccessible heap segment. These inaccessible allocated heap segments are known as memory leaks.

For efficient memory usage, inaccessible heap segments must be "reclaimed" so that they can be reallocated. The identification and reclaiming of inaccessible heap segments is known as garbage collection. A system or method for performing garbage collection is referred to as a garbage collector. The first garbage collector developed was the reference counting algorithm. It is based on counting the number of active references to dynamically allocated objects to determine which objects are inaccessible. The mark/sweep algorithm was developed at about the same time. Mark/sweep is a tracing algorithm and relies on global traversal of all allocated objects to determine the inaccessible objects.

Another garbage collector is the copying algorithm. This collector divides the heap equally into two parts. One part contains current data and the other old data. The algorithm traverses all active objects in the current data part, copies them to the other part, leaving the inactive objects uncopied. After all active objects have been traced, the roles of the two parts are swapped. Generational and incremental garbage collectors are designed to improve the performance of garbage collection, making it feasible in real-time applications. The idea behind generational garbage collection is that most objects die young. The algorithm segregates objects by age in two or more generations of heap, and concentrates effort on reclaiming those objects most likely to be garbage, i.e., young objects. Incremental algorithms decrease the length of garbage collection pauses by interleaving small amounts of collection with the real-time application program's execution. Many different embodiments of these collectors can be found in the prior art. However, implementing these collectors requires recompiling or relinking the application. Thus there is a need for a system and method for dynamic memory reclamation without recompiling or relinking the application program.

Servers in large scale information retrieval systems cannot long endure even small memory leaks because of their massive input/output demands. Memory leaks are significantly enhanced because information retrieval systems demand massive caching of massive data. A small memory leak per transaction could exhaust the available memory in a matter of days. Many existing information retrieval systems are implemented in C or C++. These languages do not automatically reclaim dynamically allocated memory, and some level of memory leaks inevitably go undetected despite high quality, meticulous programming. Thus, there is a need for a system and method for reclaiming memory leaks without programmer assistance.

There are many available tools to perform memory reclamation in the prior art. These tools require at least one of the following: compiler assistance, source code instrumentation, add-on utilities that must be linked with the application, and replacing elements in the language memory manager. Compiler assistance and source code instrumentation can be very effective in garbage collectors, however, source code and/or a build environment is often not available for a particular application. Relinking applications to include add-on utilities may change the execution of an application, asking previously manifest defects or introducing new ones. Thus, there is a need for a system and method for reclaiming memory leaks without recompiling or relinking an application program.

SUMMARY OF THE INVENTION

A method of dynamic memory reclamation for reclaiming memory leaks is disclosed, in which inaccessible heap segments are reclaimed without recompilation or relinkage of an application. The method comprises intercepting a call from an application to allocate or deallocate a heap segment, forwarding the call to the memory manager, passing the memory allocation and deallocation information from the memory manager to a file, performing a conservative garbage collection process using the memory allocation and deallocation information in the file to detect inaccessible heap segments, and calling to the memory manager from the file to deallocate the inaccessible heap segments. These steps are repeated periodically.

In the preferred embodiment, the conservative garbage collection process comprises a conservative mark/sweep garbage collector. A list of allocated heap segments is maintained in the file. The application stops when garbage collection tarts. Heap segments are conservatively scanned to locate pointers, values corresponding to addresses of allocated heap segments. The heap segments pointed to by pointers are marked on the list as accessible. The list is scanned and all unmarked heap segments on the list are considered inaccessible. The memory manager is instructed to deallocate the unmarked, inaccessible heap segments. The marked heap segments on the list are cleared, the deallocated heap segments are removed from the list, and the application resumes.

It is an object of the present invention to provide a method for dynamic memory management without recompiling or relinking to the application.

It is a further object of the present invention to provide a method for dynamic memory management in large scale information retrieval systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 represents an embodiment of the memory reclamation system of the present invention while an application program is running.

FIG. 2 is a further representation of an embodiment of the system of the present invention while a conservative garbage collection process is running.

FIG. 3 is a flow diagram that represents the preferred embodiment of the memory reclamation method of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In a computer system, an application which dynamically allocates memory will send a request to the memory manager when it needs to allocate something to a heap segment, or to deallocate a heap segment. Referring to FIG. 1, in an embodiment of the system 10 of the present invention, this request 12 is intercepted by an interface module 7 that emulates the interfaces of the memory manager 5. The application performs just as it would if the request was not intercepted. The interface module 7 forwards the request 14 to the memory manager 5, which performs the requested allocation or deallocation. The memory manager 5 performs just as it would if the request came directly from the application.

When the allocation or deallocation is completed, the memory manager 5 sends allocation/deallocation information 16 to the interface module 7 and to the application 3. The allocation/deallocation information 16 comprises the address and length of the heap segment. The interface module 7 uses the allocation/deallocation information to update a list of allocated heap segments 11. Allocated heap segments are added to the list and deallocated heap segments are removed from the list. The list is continuously updated while the application is running.

In a computer running an OpenVMS operating system, the memory manager would normally send the allocation/deallocation information to a module called the Heap Analyzer. The Heap Analyzer is a tool that presents application memory allocations to a programmer to identify areas where memory usage and performance can be improved. When the system of the present invention is implemented in OpenVMS, the interface module 7 replaces the Heap Analyzer and receives the allocation/deallocation information 16 from the memory manager 5. The system of the present invention may be implemented in a computer running a different operating system, e.g., Unix or Windows NT, by creating an interface module containing procedures that intercept all the memory manager routines.

A signal from the operating system scheduler tells the garbage collection algorithm to begin and the application program halts while the garbage collector runs. Referring now to FIG. 2, the garbage collection process is performed by the reclamation module 9. The process detects inaccessible heap segments using the list of allocated heap segmenst 11 maintained by the interface module 7. The reclamation module 9 sends a request 20 to the memory manager 5 to deallocate the inaccessible heap segments. The memory manager 5 performs this function and sends the deallocation information 22 to the interface module 7. The interface module 7 then removes the deallocated heap segments from the list 11. Once this process is complete, the application 3 resumes and the system operates as described in reference to FIG. 1. Thus inaccessible heap segments are reclaimed without recompiling or relinking the application, since the application is blind to the garbage collection process and that process is conservative.

Halting an application for periods of garbage collection works well for applications with soft deadlines, e.g. information retrieval systems. However, real-time applications with hard deadlines cannot permit garbage collection in one action preempting application execution. To be suitable for real-time applications, the system may interleave small units of garbage collection with small units of application execution. Such an design choice is within the scope of the present invention.

Referring now to FIG. 3, the preferred embodiment of the method of the present invention is described. While an application program 3 is running, it sends out allocation and deallocation requests 2. In the present method, these requests 2 are intercepted by an interface module 7. This module forwards the request 2a to the dynamic memory manager 5. The memory manager 5 performs the requested allocation or deallocation, and sends the resulting allocation/deallocation information 4 to the application 3 and back to the interface module 7. The interface module 7 maintains this information in a list of allocated heap segments 11. Allocated heap segments are added to the list and deallocated heap segments are removed from the list. These steps continue until the operating system scheduler signals the start of the garbage collection process and the halt of the application.

In the preferred embodiment of the present method, the garbage collection process comprises a conservative mark/sweep process. The mark/sweep process of the present invention differs from the traditional mark/sweep method by not delaying reclamation until all available heap storage is exhausted, nor does it reclaim garbage immediately. Instead, the process operates on a periodic reclamation cycle. The mark/sweep process has two main steps. The mark step partitions all allocated heap segments into two sets, accessible heap segments and inaccessible heap segments. The sweep step then frees all inaccessible heap segments for reuse by the application.

At a signal from the operating system scheduler 1, the process begins with the mark step, in which the reclamation module 9 scans the user stack, statically allocated memory, and accessible allocated heap segments for pointers. The reclamation module only scans these three areas of memory because it is assumed that pointers reside in memory that is accessible to the active application. Accessible allocated heap segments are scanned because they may contain pointers to other allocated heap segments. Each memory location in these areas is checked to determine if its value corresponds to an address within the bounds of an allocated heap segment, i.e. whether the value could be a pointer. The scan is conservative, in that the reclamation module receives no assistance from the compiler to determine whether a value is a pointer. Any word that could be a pointer (value equal to an address of an allocated heap segment) is treated like a pointer. An allocated heap segment that is pointed to by a pointer is considered accessible. Since the scan is conservative, it is possible that some inaccessible locations will be marked as accessible. Even so, the conservative scan works well since in practice the likelihood of properly aligned values having bit patterns of pointers is low.

Each accessible allocated heap segment is marked as such on the list of allocated heap segments 11. In the preferred embodiment, the list comprises a red-black binary tree structure that has a node for each allocated heap segment. Each node contains information about a heap segment including address, size, and a liveness mark if the heap segment is accessible.

The reclamation module then performs the sweep step, which frees the inaccessible heap segments. In the preferred embodiment the sweep step separates the marked and unmarked nodes in the binary tree, wherein the unmarked nodes correspond to inaccessible heap segments. Each node is visited in turn, and the addresses of all of the unmarked nodes are pushed onto the stack and the marked nodes are cleared. After all the nodes have been visited, the addresses of the unmarked heap segments are popped off the stack and the reclamation module sends a request 6 to the interface module to deallocate these inaccessible heap segments, thus reclaiming the memory leaks without rebuilding (recompiling or relinking) the application. The interface module forwards this request to the dynamic memory manager. It is unknown to the memory manager from where it is invoked, so it operates as if the application had called it to deallocate heap segments. The deallocation information generated by the memory manager is sent to the interface module. The nodes corresponding to the deallocated heap segments are removed from the list of allocated heap segments, the garbage collection process halts, and the application resumes.

During the garbage collection process, the reclamation module records accessible and inaccessible heap segments that are detected. At the start of the process, the reclamation module records a time stamp in a log file. During the mark step, as pointers are found, an entry is made in the log file which records the accessible heap segment address, size, and mark, the pointer value and the program counter of the instruction in the application that allocated the heap segment.

During the sweep step, as inaccessible heap segments are identified, an entry is made in the log file which records the inaccessible heap segment address, size, and mark, the start address of the heap segment and the program counter of the instruction in the application that allocated the heap segment. At the end of the garbage collection process, the reclamation module records the number of inaccessible heap segments detected during the process.

The time cost of the mark step of the garbage collection process is proportional to the number of memory locations in the stack, statically allocated data, and accessible allocated heap segments, since each location must be scanned for pointers. The time cost of the sweep step is proportional to the total number of allocated heap segments, since each allocated heap segment has a node on the list that must be visited. The total time cost is the sum of the costs of the mark and the sweep steps, and depends on the processing speed of the computer.

In the preferred embodiment, the garbage collection process is performed periodically, for example every 10 seconds. During initialization the reclamation module requests the operating system to schedule the garbage collection process every 10 seconds. The periodicity of the garbage collection process may be adjusted without going beyond the scope of the present invention.

It is to be understood that the described embodiments are merely illustrative of the many specific embodiments which represent applications of the present invention. Other embodiments may be readily devised by those skilled in the art without departing from the spirit and scope of the present invention.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4755939 *Nov 24, 1986Jul 5, 1988International Computers LimitedGarbage collection in a computer system
US5136706 *Apr 30, 1987Aug 4, 1992Texas Instruments IncorporatedAdaptive memory management system for collection of garbage in a digital computer
US5355483 *Jul 18, 1991Oct 11, 1994Next ComputersAsynchronous garbage collection
US5485613 *Mar 17, 1994Jan 16, 1996At&T Corp.Method for automatic memory reclamation for object-oriented systems with real-time constraints
US5535390 *Jul 22, 1994Jul 9, 1996Hildebrandt; Thomas H.In a computer system
US5560003 *Dec 21, 1992Sep 24, 1996Iowa State University Research Foundation, Inc.System and hardware module for incremental real time garbage collection and memory management
US5561785 *Oct 29, 1992Oct 1, 1996International Business Machines CorporationSystem for allocating and returning storage and collecting garbage using subpool of available blocks
US5572730 *Apr 18, 1995Nov 5, 1996Ricoh Company, Ltd.Storage management method in an information processing system
US5604902 *Feb 16, 1995Feb 18, 1997Hewlett-Packard CompanyHole plugging garbage collection for a data storage system
US5652883 *May 23, 1995Jul 29, 1997Microsoft CorporationComputer method and system for conservative-stack and generational heap garbage collection
US5687368 *Jul 22, 1994Nov 11, 1997Iowa State University Research Foundation, Inc.CPU-controlled garbage-collecting memory module
US5689707 *Dec 4, 1995Nov 18, 1997Ncr CorporationMethod and apparatus for detecting memory leaks using expiration events and dependent pointers to indicate when a memory allocation should be de-allocated
Non-Patent Citations
Reference
1"A garbage collector for C and C++", ftp://parcftp.xerox.com/pub/gc/gc.htmal.
2"C Interface", GC library,http://reality.sgi.com.boehm-- mti/gcinterface.html.
3"Large Scale Information Retrieval Systems: Resolving Memory Leaks in Non-Cooperative Server Applications", Brian A. Williard, Ph.D. charts from thesis defense dated Feb. 16, 1998, Florida Institute of Technology, pp. 1-62.
4"Large Scale Information Retrieval Systems: Resolving Memory Leaks in Non-Cooperative Server Applications", Brian Willard and Ophir Frieder, Jan. 6, 1998, pp. 1-36.
5 *A garbage collector for C and C , ftp://parcftp.xerox.com/pub/gc/gc.htmal.
6 *C Interface , GC library,http://reality.sgi.com.boehm mti/gcinterface.html.
7 *Large Scale Information Retrieval Systems: Resolving Memory Leaks in Non Cooperative Server Applications , Brian A. Williard, Ph.D. charts from thesis defense dated Feb. 16, 1998, Florida Institute of Technology, pp. 1 62.
8 *Large Scale Information Retrieval Systems: Resolving Memory Leaks in Non Cooperative Server Applications , Brian Willard and Ophir Frieder, Jan. 6, 1998, pp. 1 36.
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US6510504 *Jun 29, 1998Jan 21, 2003Oracle CorporationMethods and apparatus for memory allocation for object instances in an object-oriented software environment
US6560773 *Oct 7, 1999May 6, 2003International Business Machines CorporationMethod and system for memory leak detection in an object-oriented environment during real-time trace processing
US6581077 *Dec 12, 2000Jun 17, 2003Sun Microsystems, Inc.Method and apparatus for storing short-lived objects in a virtual machine
US6598141Mar 8, 2001Jul 22, 2003Microsoft CorporationManipulating interior pointers on a stack during garbage collection
US6681234 *Dec 12, 2000Jan 20, 2004Sun Microsystems, Inc.Method and apparatus for storing long-lived objects in a virtual machine
US6782462 *Feb 25, 2002Aug 24, 2004International Business Machines CorporationSystem and method for tracking memory leaks
US6898611Jun 4, 2001May 24, 2005Microsoft CorporationDeclarative pinning
US7010555 *Oct 17, 2002Mar 7, 2006International Business Machines CorporationSystem and method for compacting a computer system heap
US7013454 *Oct 22, 2001Mar 14, 2006Sun Microsystems, Inc.Thread suspension system and method using trapping instructions
US7047213Oct 3, 2001May 16, 2006International Business Machines CorporationMethod for purging abandoned shopping carts from an electronic commerce web site
US7107428 *Jul 1, 2005Sep 12, 2006Microsoft CorporationMemory-usage tracking tool
US7293142 *Apr 19, 2004Nov 6, 2007Cisco Technology, Inc.Memory leak detection system and method using contingency analysis
US7302542 *Nov 14, 2003Nov 27, 2007Sun Microsystems, Inc.Mechanism for dynamically-allocated variables in an arbitrary-context tracing framework
US7433862Jun 10, 2004Oct 7, 2008Microsoft CorporationDeclarative pinning
US7454447Jan 12, 2005Nov 18, 2008Microsoft CorporationDeclarative pinning
US7472144 *Jul 28, 2003Dec 30, 2008International Business Machines CorporationMethod and system for resolving memory leaks and releasing obsolete resources from user session data
US7533123Jun 10, 2004May 12, 2009Microsoft CorporationDeclarative pinning
US7548940 *Jun 10, 2005Jun 16, 2009International Business Machines CorporationGenerational real-time garbage collection
US7549152 *May 26, 2006Jun 16, 2009Microsoft CorporationMethod and system for maintaining buffer registrations in a system area network
US7730449Mar 19, 2003Jun 1, 2010Toshiba CorporationAuto reference counting pointer for C++ objects with ability to re-cast and lookup from a free pointer
US7765375 *Oct 31, 2007Jul 27, 2010Hitachi, Ltd.Memory management method, information processing apparatus, and memory management program
US7827538 *Jul 20, 2006Nov 2, 2010International Business Machines CorporationMemory leak detection
US7831961Mar 13, 2006Nov 9, 2010Oracle America, Inc.Cooperative preemption mechanism for garbage-collected multi-threaded computation
US7882158May 12, 2009Feb 1, 2011Microsoft CorporationDeclarative pinning
US7921143May 12, 2009Apr 5, 2011Microsoft CorporationDeclarative pinning
US8176291 *Mar 10, 2010May 8, 2012Marvell Israel (Misl) Ltd.Buffer management architecture
US8195908 *Jul 15, 2007Jun 5, 2012International Business Machines CorporationSystem and method of squeezing memory slabs empty
US8423718 *Jun 21, 2011Apr 16, 2013Oracle America, Inc.Low-overhead run-time memory leak detection and recovery
US8423744Feb 17, 2012Apr 16, 2013International Business Machines CorporationSystem and method of squeezing memory slabs empty
US8521972Jun 30, 2010Aug 27, 2013Western Digital Technologies, Inc.System and method for optimizing garbage collection in data storage
US8549503 *Apr 17, 2012Oct 1, 2013International Business Machines CorporationDetecting dangling pointers and memory leaks within software
US8661223May 7, 2012Feb 25, 2014Marvell Israel (M.I.S.L.) Ltd.Buffer management architecture
US8706985Jul 23, 2013Apr 22, 2014Western Digital Technologies, Inc.System and method for optimizing garbage collection in data storage
US8788778Jun 4, 2012Jul 22, 2014Western Digital Technologies, Inc.Garbage collection based on the inactivity level of stored data
US20110252276 *Jun 21, 2011Oct 13, 2011Oracle America, Inc.Low-overhead run-time memory leak detection and recovery
US20120054746 *Jul 12, 2011Mar 1, 2012Vmware, Inc.System software interfaces for space-optimized block devices
US20120204165 *Apr 17, 2012Aug 9, 2012International Business Machines CorporationDetecting Dangling Pointers And Memory Leaks Within Software
US20130054925 *Aug 24, 2011Feb 28, 2013Microsoft CorporationMemory allocation tracking
Classifications
U.S. Classification711/170, 711/E12.009, 707/999.206, 707/999.202
International ClassificationG06F12/02
Cooperative ClassificationY10S707/99957, Y10S707/99953, G06F12/0253, G06F2212/702
European ClassificationG06F12/02D2G
Legal Events
DateCodeEventDescription
Mar 22, 2012FPAYFee payment
Year of fee payment: 12
Jan 7, 2011ASAssignment
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTHROP GRUMMAN CORPORATION;REEL/FRAME:025597/0505
Owner name: NORTHROP GRUMMAN SYSTEMS CORPORATION, CALIFORNIA
Effective date: 20110104
Mar 20, 2008FPAYFee payment
Year of fee payment: 8
Mar 26, 2004FPAYFee payment
Year of fee payment: 4
Jun 29, 1998ASAssignment
Owner name: NORTHROP GRUMMAN CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WILLARD, BRIAN ALAN;FRIEDER, OPHIR;REEL/FRAME:009281/0317;SIGNING DATES FROM 19980601 TO 19980609