Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
1999-10-07
2003-05-06
Chaki, Kakali (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C707S793000
Reexamination Certificate
active
06560773
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for optimizing performance in a data processing system. Still more particularly, the present invention provides a method and apparatus for a software program development tool for enhancing performance of a software program through software profiling.
2. Description of Related Art
In analyzing and enhancing performance of a data processing system and the applications executing within the data processing system, it is helpful to know which software modules within a data processing system are using system resources. Effective management and enhancement of data processing systems requires knowing how and when various system resources are being used. Performance tools are used to monitor and examine a data processing system to determine resource consumption as various software applications are executing within the data processing system. For example, a performance tool may identify the most frequently executed modules and instructions in a data processing system, or may identify those modules which allocate the largest amount of memory or perform the most I/O requests. Hardware performance tools may be built into the system or added at a later point in time. Software performance tools also are useful in data processing systems, such as personal computer systems, which typically do not contain many, if any, built-in hardware performance tools.
One known software performance tool is a trace tool. A trace tool may use more than one technique to provide trace information that indicates execution flows for an executing program. One technique keeps track of particular sequences of instructions by logging certain events as they occur, so-called event-based profiling technique. For example, a trace tool may log every entry into, and every exit from, a module, subroutine, method, function, or system component. Typically, a time-stamped record is produced for each such event. Corresponding pairs of records similar to entry-exit records also are used to trace execution of arbitrary code segments, starting and completing I/O or data transmission, and for many other events of interest.
In order to improve performance of code generated by various families of computers, it is often necessary to determine where time is being spent by the processor in executing code, such efforts being commonly known in the computer processing arts as locating “hot spots.” Ideally, one would like to isolate such hot spots at the instruction and/or source line of code level in order to focus attention on areas which might benefit most from improvements to the code.
Another trace technique involves program sampling to identify certain locations in programs in which the programs appear to spend large amounts of time. This technique is based on the idea of interrupting the application or data processing system execution at regular intervals, so-called sample-based profiling. At each interruption, information is recorded for a predetermined length of time or for a predetermined number of events of interest. For example, the program counter of the currently executing thread, which is a process that is part of the larger program being profiled, may be recorded during the intervals. These values may be resolved against a load map and symbol table information for the data processing system at post-processing time, and a profile of where the time is being spent may be obtained from this analysis.
For example, isolating such hot spots to the instruction level permits compiler writers to find significant areas of suboptimal code generation at which they may thus focus their efforts to improve code generation efficiency. Another potential use of instruction level detail is to provide guidance to the designer of future systems. Such designers employ profiling tools to find characteristic code sequences and/or single instructions that require optimization for the available software for a given type of hardware.
Another runtime statistic that may be analyzed by software developers is memory allocation. A trace tool may log an allocation requester and the amounts of memory allocated for each memory allocation request. Memory allocation information may allow a software developer to analyze memory leakage problems. As an application executes, it stores and retrieves data in a variety of static and dynamic data structures. Statically allocated data structures are declared within the source code, and the compiler allocates storage space for the static data structure. When the application is loaded into memory, the static data structure has a predetermined amount of memory reserved for it, and the application cannot dynamically deallocate this memory. In some programming languages, arrays are statically allocated.
Other data structures can be dynamically allocated within memory when requested either by the application or by the runtime environment. A portion of memory is dynamically provided for the data structure or data object, and after the application is finished using the data structure, the memory space for the data structure is dynamically deallocated.
A memory leak occurs when the dynamically allocated memory space is not properly deallocated; either the application or the runtime environment may lose its pointer or memory reference to the dynamically allocated memory space, and once lost, the pointer or memory reference may not be retrieved. However, the memory allocation mechanism, which may be the operating system, will not reallocate the memory space because it was not deallocated, and a portion of memory is no longer being utilized. If one considers a newly initialized system as having a “full” memory, then the memory may slowly lose portions of its allocable space until a “low” memory condition occurs in which no more memory may be allocated, which usually causes the system to crash soon after this condition arises. Memory leaks are extremely difficult to find as the first and only symptom of a memory leak may be a system crash, which may occur significantly after the “leaky” code has executed. Using an object oriented language like Java, the JVM may allocate memory from a “Java Heap” where the memory heap allocations and deallocations are hidden from the Java programmer. The allocations are performed by the JVM when new objects are specified, such as, “String ABC=“ABC”. The JVM uses the implied new constructor in this case as it allocates the string “ABC”. The deallocations are done by the JVM asynchronously at Garbage collection (GC) time when there are no longer any reverences to the ABC string, that is, the object is no longer referenced. Because these allocations and deallocations are done by the JVM, the Java programmer is usually not aware of the cost associated with the objects created and may not take care to eliminate references to objects that are not required. In the case of Java, the memory leaks will also cause more frequent GCs, which in turn reduce performance.
Therefore, it would be advantageous to provide a method and system for accurate memory leak detection in an object-oriented environment, and it would be particularly advantageous to provide memory leak detection during real-time trace processing.
SUMMARY OF THE INVENTION
A method and system for detecting memory leaks in an object-oriented environment during real-time trace processing is provided. During the profiling of a program executing in a data processing system, a profiler processes events caused by the execution of the program, and the profiler maintains a profile data structure containing execution-related metrics for the program. The execution-related metrics may include object allocation and deallocation metrics that are associated with object processing initiated on behalf of an executing method. An object allocator allocates objects during the execution of the program and modifies object allocation metrics in the profile data structure. An object deallocator, such as a gar
Alexander, III William Preston
Howard John Day
Levine Frank Eliot
Reynolds William Robert
Urquhart Robert J.
Chaki Kakali
Chavis John Q.
VanLeeuwen Leslie A.
Yee Duke W.
LandOfFree
Method and system for memory leak detection in an... 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 system for memory leak detection in an..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for memory leak detection in an... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3017738