Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-02-04
2002-08-13
Beausoleil, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C702S186000
Reexamination Certificate
active
06434714
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to performance analysis and more specifically to methods for providing a multi-dimensional view of performance data associated with an application program.
BACKGROUND
Multi-threading is the partitioning of an application program into logically independent “threads” of control that can execute in parallel. Each thread includes a sequence of instructions and data used by the instructions to carry out a particular program task, such as a computation or input/output function. When employing a data processing system with multiple processors, i.e., a multiprocessor computer system, each processor executes one or more threads depending upon the number of processors to achieve multi-processing of the program.
A program can be multi-threaded and still not achieve multi-processing if a single processor is used to execute all threads. While a single processor can execute instructions of only one thread at a time, the processor can execute multiple threads in parallel by, for example, executing instructions corresponding to one thread until reaching a selected instruction, suspending execution of that thread, and executing instructions corresponding to another thread, until all threads have completed. In this scheme, as long as the processor has started executing instructions for more than one thread during a given time interval all executing threads are said to be “running” during that time interval.
Multiprocessor computer systems are typically used for executing application programs intended to address complex computational problems in which different aspects of a problem can be solved using portions of a program executing in parallel on different processors. A goal associated with using such systems to execute programs is to achieve a high level of performance, in particular, a level of performance that reduces the waste of the computing resources. Computer resources may be wasted, for example, if processors are idle (i.e., not executing a program instruction) for any length of time. Such a wait cycle may be the result of one processor executing an instruction that requires the result of a set of instructions being executed by another processor.
It is thus necessary to analyze performance of programs executing on such data processing systems to determine whether optimal performance is being achieved. If not, areas for improvement should be identified.
Performance analysis in this regard generally requires gathering information in three areas. The first considers the processor's state at a given time during program execution. A processor's state refers to the portion of a program (for example, set of instructions such as a subprogram, loop, or other code block) that the processor is executing during a particular time interval. The second considers how much time a processor spends in transition from one state to another. The third considers how close a processor is to executing at its peak performance. These three areas do not provide a complete analysis, however. They fail to address a fourth component of performance analysis, namely, precisely what a processor did during a particular state (e.g., computation, input data, output data, etc.).
When considering what a processor did while in a particular state, a performance analysis tool can determine the affect of operations within a state on the performance level. Once these factors are identified, it is possible to synchronize operations that have a significant impact on performance with operations that have a less significant impact, and achieve a better overall performance level. For example, a first thread may perform an operation that uses significant resources while another thread scheduled to perform a separate operation in parallel with the first thread sits idle until the first thread completes its operation. It may be desirable to cause the second thread to perform a different operation that does not require the first thread to complete its operation, thus eliminating the idle period for the second thread. By changing the second thread's schedule in this way the operations performed by both threads are better synchronized.
When a performance analysis tool reports a problem occurring in a particular state, but fails to relate the problem to other events occurring in an application (for example, operations of another state), the information reported is relatively meaningless. To be useful a performance analysis tool must assist a developer in determining how performance information relates to a program's execution. Therefore, allowing a developer to determine the context in which a performance problem occurs, provides insight into diagnosing the problem.
The process of gathering this information for performance analysis is referred to as “instrumentation.” Instrumentation generally requires adding instructions to a program under examination so that when the program is executed the instructions generate data from which the performance information can be derived.
Current performance analysis tools gather data in one of two ways: subprogram level instrumentation and bucket level instrumentation. A subprogram level instrumentation method of performance analysis tracks the number of subprogram calls by instrumenting each subprogram with a set of instructions that generate data reflecting calls to the subprogram. It does not allow a developer to track performance data associated with the operations performed by each subprogram or a specified portion of the subprogram, for example, by specifying data collection beginning and ending points within a subprogram.
A bucket level instrumentation performance analysis tool divides the executable code into evenly spaced groups, or buckets. Performance data tracks the number of times a program counter was in a particular bucket at the conclusion of a specified time interval. This method of gathering performance data essentially takes a snapshot of the program counter at the specified time interval. This method fails to provide comprehensive performance information because it only collects data related to a particular bucket during the specified time interval.
The current performance analysis methods fail to provide customized collection or output of performance data. Generally, performance tools only collect a pre-specified set of data to display to a developer.
SUMMARY OF THE INVENTION
Methods, systems, and articles of manufacture consistent with the present invention overcome the shortcomings of the prior art by facilitating performance analysis of multi-threaded programs executing in a data processing system. Such methods, systems, and articles of manufacture analyze performance of threads executing in a data processing system by receiving data reflecting a state of each thread executing during a measurement period, and displaying a performance level corresponding to the state of each thread during the measurement period.
REFERENCES:
patent: 4675832 (1987-06-01), Robinson et al.
patent: 4812996 (1989-03-01), Stubbs
patent: 5079707 (1992-01-01), Bird et al.
patent: 5325499 (1994-06-01), Kummer et al.
patent: 5325533 (1994-06-01), McInerney et al.
patent: 5463775 (1995-10-01), DeWitt
patent: 5485574 (1996-01-01), Bolosky
patent: 5499349 (1996-03-01), Nikhil et al.
patent: 5500881 (1996-03-01), Levin et al.
patent: 5519866 (1996-05-01), Lawrence et al.
patent: 5530816 (1996-06-01), Holt
patent: 5553235 (1996-09-01), Chen
patent: 5613063 (1997-03-01), Eustace et al.
patent: 5636374 (1997-06-01), Rodgers et al.
patent: 5673387 (1997-09-01), Chen
patent: 5675790 (1997-10-01), Walls
patent: 5675802 (1997-10-01), Allen et al.
patent: 5689712 (1997-11-01), Heisch
patent: 5724262 (1998-03-01), Ghahramani
patent: 5742793 (1998-04-01), Sturges et al.
patent: 5748961 (1998-05-01), Hanna et al.
patent: 5784698 (1998-07-01), Brady et al.
patent: 5787480 (1998-07-01), Scales et al.
patent: 5805795 (1998-09-01), Whitten
patent: 5835705 (1998-11-01), Larsen et al.
patent: 5850554 (1998-12-01), Carver
patent: 5864867 (1999-01-
Boucher Michael
Dennie Shaun
Lewis Bradley
Week Jeremy
Beausoleil Robert
Bonzo Bryce P.
Finnegan Henderson Farabow Garrett & Dunner LLP
Sun Microsystems Inc.
LandOfFree
Methods, systems, and articles of manufacture for analyzing... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods, systems, and articles of manufacture for analyzing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods, systems, and articles of manufacture for analyzing... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2897716