|Publication number||US7987453 B2|
|Application number||US 10/803,663|
|Publication date||Jul 26, 2011|
|Filing date||Mar 18, 2004|
|Priority date||Mar 18, 2004|
|Also published as||US20050210454|
|Publication number||10803663, 803663, US 7987453 B2, US 7987453B2, US-B2-7987453, US7987453 B2, US7987453B2|
|Inventors||Jimmie Earl Dewitt, Jr., Frank Eliot Levine, Christopher Michael Richardson, Robert John Urquhart|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (89), Non-Patent Citations (24), Referenced by (12), Classifications (12), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention is related to the following applications entitled “APPARATUS AND METHOD FOR AUTONOMIC HARDWARE ASSISTED THREAD STACK TRACKING”, Ser. No. 10/703,658, filed on Nov. 6, 2003; “APPARATUS AND METHOD FOR CATALOGING SYMBOLIC DATA FOR USE IN PERFORMANCE ANALYSIS OF COMPUTER PROGRAMS”, Ser. No. 09/613,190, filed on Jul. 10, 2000. Both related applications are assigned to the same assignee and are incorporated herein by reference.
1. Technical Field
The present invention relates generally to an improved data processing system and, in particular, to a method and system for processing performance data in a data processing system. Still more particularly, the present invention relates to a method, apparatus, and computer instructions for determining computer program flows autonomically using hardware assisted thread stack tracking and cataloged symbolic data.
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 require 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.
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, a 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. Alternately, a trace tool may log the requester and the amounts of memory allocated for each memory allocation request. 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.
Another trace technique involves periodically sampling a program's execution flows to identify certain locations in the program in which the program appears to spend large amounts of time. This technique is based on the idea of periodically 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 an executable portion 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.
Currently, determining execution flows of a computer program is often performed using software, such as trace tools described above. However, software performance trace tools are often less efficient in performance and require a larger memory footprint. A large memory footprint requires longer loading time and reduces operating efficiency of the system.
In addition, current data processing system applications or computer programs are typically built with symbolic data and may even be shipped to client devices with symbolic data still present in the modules. Symbolic data is, for example, alphanumeric representations of application module names, subroutine names, function names, variable names, and the like.
An application is comprised of modules written as source code in a symbolic language, such as FORTRAN or C++, and then converted to a machine code through compilation of the source code. The machine code is the native language of the computer. In order for a program to run, it must be presented to the computer as binary-coded machine instructions that are specific to that CPU model or family.
Machine language tells the computer what to do and where to do it. When a programmer writes: total=total+subtotal, that statement is converted into a machine instruction that tells the computer to add the contents of two areas of memory where TOTAL and SUBTOTAL are stored.
Since the application is executed as machine code, performance trace data of the executed machine code, generated by the trace tools, is provided in terms of the machine code, i.e. process identifiers, addresses, and the like. Thus, it may be difficult for a user of the trace tools to identify the modules, instructions, and such, from the pure machine code representations in the performance trace data. Therefore, the trace data must be correlated with symbolic data to generate trace data that is easily interpreted by a user of the trace tools.
The symbolic data with which the trace data must be correlated may be distributed amongst a plurality of files. For example, the symbolic data may be present in debug files, map files, other versions of the application, and the like. In the known performance tool systems, in order to correlate the symbolic data with the performance trace data, the performance tool must know the locations of one or more of the sources of symbolic data and have a complex method of being able to handle redundancies in the symbolic data.
In addition, such correlation is typically performed during post-processing of the performance trace data. Thus, an additional separate step is required for converting performance trace data into symbolic representations that may be comprehended by a performance analyst.
The conversion of performance trace data into symbolic representations is performed at a time that may be remote to the time that the performance trace is performed. As a result, the symbolic data may not be consistent with the particular version of the computer program executed during the trace. This may be due to the fact that, for example, a newer version of the application was executed during the trace and the symbolic data corresponds to an older version of the application.
This may be especially true for applications whose symbolic data is maintained at a supplier's location with the machine code being distributed to a plurality of clients. In such a case, the supplier may continue to update the symbolic data, i.e. create new versions of the application, but fail to provide the newest version of the application to all of the clients. In this scenario, if a performance trace were to be performed, the symbolic data maintained by the supplier may not be the same version as the machine code on which the performance trace is performed.
Therefore, it would be advantageous to have an improved method, apparatus, and computer instructions for determining computer program flows that requires a smaller memory footprint and provides user readable results using correlated symbolic data.
The present invention provides a method, apparatus, and computer instructions for determining computer program flows autonomically using hardware assisted thread stack tracking and cataloged symbolic data. When a new or existing thread is dispatched during execution of a computer program, the present invention provides hardware control registers that assist in allocating or identifying a thread work area where call stack entries are stored for the particular thread.
With the present invention, microcode is programmed with instructions for establishing thread work areas and monitoring the execution of instructions to determine how to update the thread tracking information in the thread work area. In one mode of operation, when tracing occurs, call stack data is written to entries of the thread work area continuously. When the call stack is full, call stack data is copied by the operating system to a consolidated buffer. Thus, a full trace of the thread operation is performed.
In another mode of operation, herein referred to as the call stack mode, when a call operation is detected, call stack data is written by microcode of the processor to the entries of the thread work area. However, when a return operation is detected, call stack data is removed from the stack. Entries are pushed onto and popped from the call stack as the thread is executing. In the call stack mode, the trace application wakes up periodically to instruct the operating system or the device driver to copy call stack data from the thread work area to the consolidated buffer. Thus, only a sample trace of the thread operation is performed.
During or after the tracing phase, the trace application or the post-processing application may perform post-processing of the call stack data. The trace application or the post-processing application reads from the consolidated buffer. The operating system, the device driver, or a performance monitoring application then maps each thread to a process to which the thread belongs. When requested by the trace application or post-processing application, symbolic data is obtained from an indexed database matching the mapped process and address of the method/routine that is called or returned for each thread. Using the symbolic data and the call stack data, a call sequence is generated. After generating a call sequence, the trace application or post-processing application autonomically determines the corresponding computer program flow.
These and other features and advantages of the present invention will be described in, or will become apparent to those of ordinary skill in the art in view of, the following detailed description of the preferred embodiments.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
The present invention provides a method, apparatus, and computer instructions for determining computer program flows autonomically using hardware assisted thread stack tracking and cataloged symbolic data. The present invention may be implemented in a stand-alone computing device or in a network based computing device. For example, the present invention may be implemented in a personal computer, a network computer, a server, or the like. Thus, the following diagrams in
With reference now to the figures, and in particular with reference to
In the depicted example, a server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 also are connected to a network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. For purposes of this application, a network computer is any computer, coupled to a network, which receives a program or other application from another computer coupled to the network. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Distributed data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, distributed data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the TCP/IP suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational, and other computer systems, that route data and messages. Of course, distributed data processing system 100 also may be implemented as a number of different types of networks, such as, for example, an Intranet or a local area network.
With reference now to
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A modem 218 may be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108-112 in
Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, server 200 allows connections to multiple network computers. A memory mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
An operating system runs on processor 252 and is used to coordinate and provide control of various components within data processing system 250 in
Those of ordinary skill in the art will appreciate that the hardware in
As described in “APPARATUS AND METHOD FOR AUTONOMIC HARDWARE ASSISTED THREAD STACK TRACKING”, incorporated by reference above, a method is provided to store thread tracking information automatically through the use of an allocated thread work area. A trace application or post-processing application may use the thread tracking information to obtain performance information for the trace of a computer program. In addition, the thread tracking information may be used to determine computer program flow during execution of the program in combination with cataloged symbolic data, which is described in further details in the present invention. To present a background, a brief overview of trace applications and post processing applications will be provided.
With reference now to
The trace data in buffer 304 may be subsequently stored in trace file 305 or a consolidated buffer when buffer 304 is filled for post-processing. Alternatively, the trace data may be processed in real-time. The trace data in either buffer 304 or trace file 305 is then processed by post-processor 306. Post-processor 306 processes the trace data to generate an indexed database of symbolic data for loaded modules, as described more fully hereafter.
In a non-Java environment, trace hooks may be employed that aid in the identification of modules that are used in an application under trace. With Java operating systems, trace hooks may be employed that aid in identifying loaded classes and methods.
In addition, since classes and modules may be loaded and unloaded, these changes may also be identified using trace data. This is especially relevant with “network client” data processing systems, such as those that may operate under Java OS, since classes and jitted methods may be loaded and unloaded more frequently due to the constrained memory and role as a network client. Note that class or module load and unload information are also relevant in embedded application environments, which tend to be memory constrained.
With reference now to
An initialization phase 400 is used to capture the state of the client machine at the time tracing is initiated. This trace initialization data includes trace records that identify all existing threads, all loaded classes (modules), and all methods (sections) for the loaded classes (modules). Records from trace data captured from hooks are written to indicate thread switches, interrupts, and loading and unloading of classes (modules) and “jitted” methods (sections).
Any class (module) which is loaded has trace records that indicate the name of the class (module) and its methods (sections). Numeric IDs may be used as identifiers for threads, classes, and methods. These IDs are associated with names that have been output in the trace records. A trace record is written to indicate when all of the start up information has been written.
During the profiling phase 402, trace records are written to a trace buffer or trace file. In the present invention, a trace buffer may have a combination of types of records, such as those that may originate from a trace hook executed in response to a particular type of event, e.g., a method entry or method exit, and those that may originate from a stack walking function executed in response to a timer interrupt, e.g., a stack unwind record, also called a call stack record.
For example, the following operations may occur during the profiling phase if the user of the profiling utility has requested sample-based profiling information. Each time a particular type of timer interrupt occurs, a trace record is written, which indicates the system program counter. This system program counter may be used to identify the routine that is interrupted. In the depicted example, a timer interrupt is used to initiate gathering of trace data. Of course, other types of interrupts may be used other than timer interrupts. Interrupts based on a programmed performance monitor event or other types of periodic events may be employed, for example.
In the post-processing phase 404, the data collected in the trace buffer is processed or sent to a trace file or a consolidated buffer if the trace buffer is filled for post-processing. In one configuration, the file may be sent to a server, which determines the profile for the processes on the client machine. Of course, depending on available resources, the post-processing also may be performed on the client machine.
As mentioned previously, the present invention provides a method, apparatus, and computer instructions for determining computer program flows autonomically using hardware assisted thread stack tracking and cataloged symbolic data. One embodiment of the present invention provides three hardware registers: a work area register, which includes a pointer pointing to the beginning of the allocated thread work area; a current pointer register, which includes a pointer pointing to the location of the last written call stack entry; and a work area length register, which indicates the length of the work area. Alternatively, instead of the work area length register a pointer pointing to the end of the allocated thread work area may be used.
With the present invention, the functionality of microcode currently existing in a processor is extended by programming instructions for establishing work areas and monitoring the execution of instructions to determine how to update the thread tracking information in the thread work areas. Microcode is a permanent memory that holds the elementary circuit operations a computer must perform for each instruction in its instruction set. Microcode acts as a translation layer between the instruction and the electronic level of the computer.
In a preferred embodiment, when a new thread is spawned during execution of a computer program, the operating system or the device driver of the client device, such as data processing system 250 in
As the program is executed, thread tracking information, including call stack entries, are written to the designated thread work area by microcode of the processor in a manner described in the related patent application “APPARATUS AND METHOD FOR AUTONOMIC HARDWARE ASSISTED THREAD STACK TRACKING”, which is incorporated by reference above. Upon detection of a method entry or exit, call stack entries are written to the designated thread work area in two modes. In one mode, entries are written continuously to the call stack. Alternatively, in a call stack mode, entries are pushed onto the call stack when a method entry is detected and popped off the call stack when a method exit is detected. A call stack entry includes information for a method entry/exit during execution of a spawned thread, such as a timestamp when the method is called or returned, address from which a call is made, address of the called method, and a return-to address. The operating system notifies the processor to update the pointer in the current pointer register with a new location each time a call stack entry is written.
Subsequently when a context switch occurs, meaning when a different thread is dispatched during executing of the computer program, values in the three registers are saved away by the processor in a context save area, which stores context information for a particular thread. The context save area may be within the thread work area or other location in memory. Upon reactivation of the thread by the program, the operating system or device driver instructs the processor to restore saved values from the context save area to the three registers.
Prior to writing each call stack entry, the mechanism of the present invention determines if the designated thread work area is about to overflow based on pointers stored in the work area length register and the current pointer register. An overflow may occur, for example, when the call stack is filled as entries are written to the stack. If an overflow is about to occur, the present invention sends an interrupt to the operating system or a performance monitoring application, which is an application that monitors performance of the system.
During the post-processing phase, which may occur during or after the profiling phase, a trace application or a post-processing application may utilize the call stack date for determining computer program flow. The trace application or the post-processing application may perform, in one mode of operation, a full trace of a computer program, including all executing threads, by reading stored call stack data from the consolidated buffer. The stored call stack data includes call and return operations during execution of each thread.
In this mode, the operating system, or the performance monitoring application, copies the call stack entries from the designated thread work area to a consolidated buffer when the thread work area is filled. A consolidated buffer is similar to a trace buffer except that the consolidated buffer is written to only when the stack is filled or when the data is purposely copied by the operating system or the device driver. The data in the consolidated buffer may eventually be copied to a disk or other buffer within the user space.
Alternatively, a sample trace of a computer program may be performed by a trace application in a call stack mode. In the call stack mode, entries are pushed onto and popped from the call stack as call or return operations are detected during execution of a thread. In this mode, the trace application wakes up by an interrupt, which may be a timer interrupt that expires periodically being generated. The trace application then requests the operating system to take a snapshot of the call stack entries in the thread work area in order to determine the current program flow. Similar to the above, the operating system or the device driver may then copy the call stack entries from the thread work area(s) to the consolidated buffer.
In either mode of operation, the microcode of the processor may be programmed to store additional information when writing call stack entries. Examples of additional information include time stamps and values of selected performance monitoring counters. A performance monitoring counter is a hardware counter placed inside of a processor to monitor performance of the system. The performance monitoring counters may be programmed to count various events, such as, instructions completed, cache misses, etc. By including additional information, such as instructions completed, in the call stack entries, other useful program related information may be recorded for user analysis. This additional information may be compressed or consolidated with other information in the call stack entry when the entry is written to the call stack or when the call stack entries are copied from the thread work are to the consolidated buffer during post-processing.
Turning now to
Turning now to
Next, prior to writing an entry for the call or return operation, a determination is made by the trace application as to whether an overflow occurs in the thread work area (step 516). The determination is based on the value of the current pointer register, the work area length register, and the amount of data to be written.
If an overflow is about to occur, an interrupt is sent by the trace application to the operating system or a performance monitoring application (step 518) in order to copy call stack data from the designated thread work area to the consolidated buffer and reset the current pointer register (step 520). If no overflow is about to occur, the process continues to step 522.
At step 522, the processor writes the call stack entry for the call or return operation to the designated thread work area. The trace application then sets the current pointer register pointer to the location of the last entry written in the designated work area (step 524). The operation then terminates.
When a different thread is dispatched the values of the current hardware control registers are saved away in a context save area, and previous values or new values for the current thread are restored/generated and stored in the three registers. Thus, the process repeats for the newly dispatched thread beginning at step 512. In this mode of operation, new entries for either a call or a return operation are pushed onto the stack and thus, a full trace of the computer program is performed by the trace application to capture both call and return operations.
Turning next to
If the operation is a return operation, the processor identifies the location of a designated work area for the thread using the pointer to the work area register (step 540). The processor then pops the last entry off the call stack in the designated thread work area (step 542) and the process continues to step 534.
However, if the operation is a call operation, the processor may then identify a location of the work area using the pointer to the work area register (step 526). Next, prior to writing an entry for the call operation, a determination is then made by the trace application as to whether an overflow is about to occur in the thread work area (step 528). The determination is based on the value of the current pointer register, the work area length register, and the amount of data to be written. If no overflow is about to occur, the process continues to step 534. However, if an overflow is about to occur, an interrupt is sent by the hardware to the operating system (step 530) or performance monitoring application in order to copy call stack data from the designated thread work area to the consolidated buffer and reset the pointer in the current pointer register (step 532). The process then continues to step 534.
At step 534, the processor writes the call stack entry for the call operation to the designated thread work area. The trace application then sets the pointer in the current pointer register to point to the locator of the last entry written in the designated work area (step 536). The operation then terminates.
When a different thread is dispatched the values of the current hardware control registers are saved away in a context save area and previous values or new values for the current thread are stored in the hardware control registers. Thus, the process repeats for the current beginning at step 522. In a call stack mode of operation, a sample trace of the computer program is performed to capture only call operations.
With reference now to
When a new thread is created during execution of the computer program, operating system 640 allocates a thread work area, such as thread work area 632, for the new thread in the computer program, in which the thread's call stack information is to be stored. Each thread corresponds to a thread work area. Therefore, thread work areas 632-638 corresponds to four different threads. The beginning address of the allocated thread work area is stored in work area register 614 and the length for the work area is stored in work area length register 618, both of which are part of control registers 602 of processor 610.
In addition, current pointer register 616 is provided within control registers 602. Current pointer register 616 is used to identify the location of the work area to which an entry is written. In this way, the currently active location of the thread work area may be identified.
When a different thread is created during execution of the computer program, hence when a thread context switch occurs, the values in hardware registers 614-618 may be updated. The values are first saved by the operating system 640 or device driver 642 to a context save area, which has the context of the current thread. The context save area may be within thread work area 632 or another dedicated location (not shown) in memory 630. Next, operating system 640 or device driver 642 restores previously saved values, or generates new values, for the initiated thread and saves them in hardware registers 614-618.
As described previously, the present invention extends current functionality of the microcode in a processor to include the additional functionality and operations discussed herein. For each existing thread, operating system 640 allocates a portion of memory 630 for use in storing one or more thread work areas. This portion of memory 630 has a size equal to the fixed size determined in the initialization phase. Microcode 612 then begins to monitor the instructions executed by processor 610 to determine if a new thread is spawned, if a memory overflow occurs, if a method/routine entry (call) instruction is executed, and if a method/routine exit (return) instruction is executed.
Also described above, if a new thread is spawned, a new thread work area, such as thread work area 634, in the system memory 630 may be created and a context switch may be communicated to the microcode 612 so that the values in hardware registers 614-618 identifying the last work area accessed may be updated to point to the new thread work area.
If memory overflow occurs, operating system 640 or device driver 642 may capture call stack information in the thread work area for the associated thread instead of extending the thread work area. As described in the related patent application “APPARATUS AND METHOD FOR AUTONOMIC HARDWARE ASSISTED THREAD STACK TRACKING, which is incorporated by reference above, the thread work area may be extended when an interrupt is sent from microcode 612 of processor 610 to operating system 640 in response to a thread work area overflow. Operating system 640 may extend thread work area by including an extension area. Work area register 614, current pointer register 616, and the work area length register 618 may all be impacted as a result of the extension.
However, in the present invention, instead of extending the thread work area in response to an overflow, the call stack information may be captured by operating system 640 to a new thread work area, such as trace buffer 624 or trace file 622, which is accessible by a trace application or a post-processing application.
If a method/routine entry (call) instruction is executed, then a call stack entry for the method/routine is created by the processor in the appropriate thread work area indicating the entry of a method/routine, i.e. a call stack entry is pushed onto the call stack by the processor.
If a method/routine exit (return) instruction is executed, a call stack entry for the exiting of the method/routine may be entered by the processor into the call stack of the work area in one mode of operation or popped off from the call stack in another mode of operation, which is referred to previously as the call stack mode.
If a new thread is spawned during the execution of the computer program that is being traced, and thread tracking is enabled in the processor 610 by the setting of the control bit in the processor 610, then a new thread work area is needed in order to track the thread execution. A new thread may be determined to have been spawned by the communication of a context switch by the operating system 640. Similar to the allocation of work areas during initialization, the operating system 640 may allocate a new thread work area, such as thread work area 632, for the new thread by setting work area register 614 of control registers 602 to point to the beginning of the area and designate the length of the thread work area in work area length register 618 of control registers 602.
Thereafter, when the new thread causes an event to occur, such as entry or exit of a method/routine, an entry will be written by the processor to the work area for the new thread having the necessary information for use by trace application 620 or post-processing program 628. Current pointer register 616 is updated by microcode 612 of processor 610 with pointer pointing to location of the last written entry.
If a method/routine entry instruction is executed by processor 610, as determined by whether the instruction executed by the processor 610 is a “call” instruction or not, microcode 612 determines if thread tracking is enabled in the processor 610. That is, microcode 612 determines if the control bit identifying thread tracking to be enabled is set. If the control bit is set and a method/routine entry instruction is executed by processor 610, microcode 612 determines that a call stack event has occurred that requires the creation and storage of a call stack entry in the thread work area for the associated thread.
Microcode 612 identifies the beginning address of the thread work area for the thread by retrieving the address information from work area register 614 of control registers 602 and determines if there is enough room in the thread work area to write the call stack entry for the event. This may be determined by comparing the length of the thread work area, as designated in work area length register 618, to the location of the last entry written to the call stack in the thread work area, as designated in current pointer register 616. If the thread work area has enough remaining storage, a call stack entry for the event is generated and stored in the thread work area for the thread, e.g., thread work area 632. This call stack entry may include, for example, the address of the method/routine being called.
If the thread work area for the thread, e.g., thread work area 632, does not have sufficient storage capacity for a new call stack entry, then microcode 612 identifies the condition as a work area or memory overflow. As a result, microcode 612 sends an interrupt to the trace application code 620 via operating system 640 indicating the work area overflow. In response, trace application code 620 may instruct operating system 640 to capture call stack information in the thread work area for the thread to a new thread work area, such as trace buffer 624 or trace file 622. In response to the instruction to capture the work area for the thread, operating system 640 copies the call stack information and resets values in hardware registers 614-618.
Similar to the operation above with regard to the entry of a method/routine, processor 610 may detect that a method/routine is exited by the execution of a “return” instruction in the code of the computer program. Upon the detection of a “return” instruction, the present invention may add an additional entry to the call stack designating the exit of the method/routine in one mode of operation. In this mode, every method/routine entered and excited during execution of the thread is captured.
Alternatively, the present invention may remove entries for methods/routines that are exited from the call stack in another mode of operation, referred to as call stack mode, to only capture method/routine that entered during execution of the thread.
Thus, as processor 610 executes instructions of the computer program under the trace, operating system 640 automatically allocates new thread work areas for newly spawned threads, writes call stack entries into thread work areas in response to the detection of an entry/exit method/routine event, and captures call stack information when an overflow occurs. As a result, hardware mechanisms of the present invention help to alleviate some of the burden of performing these operations entirely in software. Moreover, since the hardware may operate virtually independently of the trace application and computer program under trace, with regard to these operations, these operations may be performed regardless of the particular trace application or computer program that is executing. Furthermore, the computer program under trace need not be instrumented to obtain the call stack information since this information is automatically obtained by the processor once the trace application indicates that thread tracking is to be enabled.
It should be appreciated that the above operations of the present invention may be initiated at any time during tracing of a computer program. Thus, in one mode of operation, a trace application may wake up as a result of a filled call stack or a timer interrupt, the mechanism of the present invention is initiated to capture call stack information from the thread work area. Alternatively, in a call stack mode, a situation may be present in which the mechanism of the present invention is initiated while method calls are currently outstanding, i.e., a method call has been made and the present invention is initiated prior to the called method being exited. In other words, when in call stack mode, a return operation may be performed without a call operation having been made while the present invention is active. In these situations, such return operations are handled as a no op, that is, no operation.
As described in “APPARATUS AND METHOD FOR CATALOGING SYMBOLIC DATA FOR USE IN PERFORMANCE ANALYSIS OF COMPUTER PROGRAMS”, incorporated by reference above, a method is provided for post-processing performance trace data recorded in trace buffer 624 or trace file 622. A merged symbol file, such as merge symbol file 630, is generated for a computer program, or application, under trace. Merged symbol file 630 comprises symbolic data for modules obtained from map files, debug files, non-stripped versions of modules, and other symbolic data files. The merged symbol file contains information useful in performing symbolic resolution of address information in trace files for each instance of a module, such as checksum, timestamp, fully qualified path to the module, length of the module, etc.
During post processing of the trace information generated by a performance trace of a computer program, symbolic information stored in merged symbol file 630 is compared to the trace information stored in trace file 622. The trace information includes information identifying the modules that were called during the trace of the computer application. This trace information, which may be obtained using the hardware thread tracking mechanisms previously described, and the merged symbol file are used to produce reports. The correct symbolic information in merged symbol file 630 for the modules used in the trace is identified based on a number of validating criteria.
The correct symbolic information for the required modules may then be stored as an indexed symbolic database, for example, indexed symbolic database 626, that is indexed using process identifiers and address identifiers. The indexed database of symbolic information may be stored as a separate file or as a separate portion of a trace file for the computer application. Indexed symbolic database 626 may then be used to resolve address information into corresponding symbolic information when providing the trace information for use by a user.
As described above, the symbolic information provides symbolic data for loaded modules/processes, i.e. called module or processes, of the application under trace. As a result of the symbolic resolution, indexed symbolic database 626 for the loaded/called modules/processes is generated by either the trace application 620 or the post-processing program 628.
The indexed database entries may be indexed based on any searchable value. In a preferred embodiment, the indexed database is indexed based on the process identifier (pid) and the segment load address, however, other searchable indices may be used without departing from the spirit and scope of the present invention.
Once indexed symbolic database 626 is generated, trace application 620 or post-processing application 628 may search indexed symbolic database 626 for symbolic information that matches the process identifier (pid) and the address of the method/routine called or returned by each thread. When a match is found, a call sequence may be generated using symbolic data that represents the computer program flow.
Turning now to
As shown in
Once the symbolic data is obtained for the loaded/called modules, the symbolic data is stored as a separate section of the trace file containing only the symbolic data for the loaded modules (step 710). This symbolic data is then indexed to generate an indexed database of symbolic data for the loaded modules as a separate section of the trace file (step 712) and the process terminates thereafter.
Thus, an indexed database of symbolic data for loaded modules is obtained by gathering symbolic data from a plurality of sources into a merged symbol file, such as merged symbol file 650 in
Turning next to
The operating system 804 then allocates the new work areas for new threads (operation 816) of the computer program by allocating address ranges in memory 808 for each thread. Operating system 804 then instructs processor 806 to set the work area register to point to the beginning address and stores the length for the work area, which is initially fixed, in the work area length register (operation 818). Thereafter, as call stack events occur, processor 806 writes call stack entries to the appropriate work areas in memory 808 (operation 820).
At some time later, a wakeup of trace application 802 is caused by an interrupt (operation 822). The interrupt may be initiated when the trace buffer is filled or by a periodic timer. Trace application 802 then requests the thread call stack information (operation 824) from processor 806. Next, trace application 802 notifies processor 806 to retrieve call stack information (operation 826) via operating system 804 using the pointer stored in the current pointer register. The call stack information retrieved may be copied to a consolidated buffer that is accessible in the application space. Once the call stack entries are copied to the consolidated buffer, the operating system or the performance monitoring application maps each thread back to the process to which the thread belongs.
The call stack information for the threads of interest may then be processed by trace application 802. This is accomplished by reading the call stack entries from the consolidated buffer to identify the thread-process relationship. Typically, when a thread is created, it is created within a process. The operating system may provide an interface to identify the process and another interface to identify the thread. In addition, the thread-process information is known by the operating system at thread creation time.
Alternatively, at dispatch time, which is when a thread is dispatched and starts executing, both the process identifier and corresponding thread identifier are known to the operating system. This information is known to the operating system, because the addresses of the dispatched process and thread have fixed locations or symbolic names. When the dispatcher chooses the process and thread to dispatch, a trace record may be written by the operating system or kernel extension identifying the process and thread being dispatched. From this trace record, a process identifier and a thread identifier may be retrieved.
Thus, trace application 802 may request symbolic data (operation 828) from the indexed symbolic database 810. A search is performed by trace application 802 for symbolic data. An example of retrieved symbolic data is “C:\System\user.dll(function1)”. The search for symbolic data is based on the process identifier and address of the method calls or returns for each thread. The address of a call operation is the address to where the processor will transfer control when the call operation is executed. Typically, a “from” and a “to” address are written to the call stack in the thread work area. An example of an address is “0x80140000”. This address information may be in a compressed form when it is written to the call stack along with additional information such as time stamps and performance monitoring counter values. Alternatively, a consolidation and/or compression may be made at the time the call stack data is copied from the thread work area to the consolidated buffer.
Once the symbolic data is retrieved for the call stack information (operation 830) trace application 802 performs symbolic resolution (operation 832). Lastly, trace application 802 generates a call tree or sequence using the symbolic data (operation 834), which depicts the computer program flow.
Alternatively, the post-processing may be performed by a post-processing program after the profiling phase. Turning now to
Post-processing application 850 reads call stack data from a trace buffer or file (operation 872) retrieved by trace application 842. The trace buffer may be the consolidated buffer, which includes call stack data copied from thread work areas during execution of the program code. Once the call stack data is read from the consolidated buffer, post-processing application 850 may request symbolic data (operation 874) from indexed symbolic database 852 based on the process id and the address of method calls or returns for each thread. Once symbolic data is retrieved (operation 876), post-processing application 850 may perform symbolic resolution (operation 878) and generate a call tree or sequence of the computer program based on the symbolic data (operation 880).
Turning next to
Upon waking up, the trace application requests call stack data from the processor (step 904). The processor identifies the address of the thread work area using the pointer to the work area register. Next, the device driver in the operating system copies the call stack data to a trace buffer or file (step 906). The trace buffer may be a consolidated buffer where call stack data for each thread may be stored. When the call stack data is copied from the thread work area, other processing may occur, such as, compressing or consolidating the call stack data with additional information, such as, time stamps and performance monitoring counter values. Next, the trace application reads the call stack data in the trace buffer or consolidated buffer (step 908).
In order to retrieve symbolic data, the device driver, the operating system, or a performance monitoring application maps each thread to a process (step 910). The mapping is performed by locating a process identifier (pid) that corresponds to the thread identifier specified in the call stack data. Once the mapping is complete, the trace application searches the indexed symbolic database for symbolic data that matches process id and address of each method call or return for each thread (step 912). Based on the retrieved symbolic data, a call tree or sequence is generated by the trace application that describes the execution flows of a computer program (step 914). The operation then terminates.
In an alternative embodiment, rather than searching the indexed symbolic database, other methods may be used to retrieve the symbolic data. These methods include examining the loaded/called module itself if the address of the loaded/called module on a disk is known, examining other symbolic data in the same directory as the load/called module, and examining symbolic data in a shadow directory. A shadow directory is a directory that resides in a separated location on the same data processing system.
Turning next to
Similar to the process in
Turning next to
When a trace application wakes up or when a post-processing application requests call stack data, the operating system or device driver copies the call stack data from the thread work area to a trace or consolidated buffer. In this example, thread 1 call stack 1030 is copied. When the device driver the operating system or a performance monitoring application maps thread 1 to a process, it is mapped to pid of 1. Thread 1 call stack 1030 includes 5 entries, entries 1040. Entries 1040 are arranged in the order the method is called or returned. For example, entry 1042 is called prior to entry 1044 when thread 1 is executed. Thus, entries 1040 depict the computer program flow when thread 1 is executed.
Based on entries 1010 in indexed symbolic database 1000 and entries 1040 in thread 1 call stack 1030, trace application or post-processing application may generate call tree or sequence 1050 after symbolic resolution is performed for pid 1. In call sequence 1050, method C:\SYSTEM\foo.exe(subroutine1) 1052 is first called by pid 1. Subsequently, method C:\User\foo.dll(subroutine1) 1054 is called, followed by method C:\SYSTEM\foo.exe(subroutine2) 1056 and C:\User\foo.dll(subroutine2) 1058.
Thus, using the call stack data copied for a thread of the computer program, along with mapping of a thread to a process, the index symbolic database is searched for symbolic data that corresponds to each thread of a computer program. Hence, a call tree or sequence may be generated using the symbolic data that represents the computer program flow.
In summary, the present invention provides hardware registers necessary to manage thread work areas in memory, which store call stack information for events that occur during execution of a computer program. In addition, the present invention extends the functionality of microcode in existing processors to manage updates of the hardware registers and allocation of thread work areas. The microcode may be programmed to store additional information, such as, time stamps and values of performance monitoring counters, in call stack entries of the thread work area. By storing additional information, such as, instructions completed, the call stack data may include instructions that are completed for each subroutine that is executed in each thread of a computer program. This data provides valuable program related information to the user. These innovative mechanisms aid in determining computer program flow more efficiently without the need for a large memory footprint. Furthermore, the mechanisms of the present invention enable the integrated use of an indexed symbolic database and thread stack tracking information to generate symbolic data for the computer program flow that is readable by a user.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4291371||Jan 2, 1979||Sep 22, 1981||Honeywell Information Systems Inc.||I/O Request interrupt mechanism|
|US5103394||Dec 21, 1989||Apr 7, 1992||Hewlett-Packard Company||Software performance analyzer|
|US5555432||Aug 19, 1994||Sep 10, 1996||Intel Corporation||Circuit and method for scheduling instructions by predicting future availability of resources required for execution|
|US5590352||Apr 26, 1994||Dec 31, 1996||Advanced Micro Devices, Inc.||Dependency checking and forwarding of variable width operands|
|US5652858||May 31, 1995||Jul 29, 1997||Hitachi, Ltd.||Method for prefetching pointer-type data structure and information processing apparatus therefor|
|US5691920||Oct 2, 1995||Nov 25, 1997||International Business Machines Corporation||Method and system for performance monitoring of dispatch unit efficiency in a processing system|
|US5761103||Mar 8, 1995||Jun 2, 1998||Texas Instruments Incorporated||Left and right justification of single precision mantissa in a double precision rounding unit|
|US5774724||Nov 20, 1995||Jun 30, 1998||International Business Machines Coporation||System and method for acquiring high granularity performance data in a computer system|
|US5805879||Feb 23, 1996||Sep 8, 1998||Cyrix Corporation||In a pipelined processor, setting a segment access indicator during execution stage using exception handling|
|US5822790||Feb 7, 1997||Oct 13, 1998||Sun Microsystems, Inc.||Voting data prefetch engine|
|US5875294||Jun 30, 1995||Feb 23, 1999||International Business Machines Corporation||Method and system for halting processor execution in response to an enumerated occurrence of a selected combination of internal states|
|US5913925||Dec 16, 1996||Jun 22, 1999||International Business Machines Corporation||Method and system for constructing a program including out-of-order threads and processor and method for executing threads out-of-order|
|US5930508||Jun 9, 1997||Jul 27, 1999||Hewlett-Packard Company||Method for storing and decoding instructions for a microprocessor having a plurality of function units|
|US5937437||Oct 28, 1996||Aug 10, 1999||International Business Machines Corporation||Method and apparatus for monitoring address translation performance|
|US5938778||Nov 10, 1997||Aug 17, 1999||International Business Machines Corporation||System and method for tracing instructions in an information handling system without changing the system source code|
|US5966537||May 28, 1997||Oct 12, 1999||Sun Microsystems, Inc.||Method and apparatus for dynamically optimizing an executable computer program using input data|
|US5987250||Aug 21, 1997||Nov 16, 1999||Hewlett-Packard Company||Transparent instrumentation for computer program behavior analysis|
|US6070009||Nov 26, 1997||May 30, 2000||Digital Equipment Corporation||Method for estimating execution rates of program execution paths|
|US6073109||Dec 12, 1996||Jun 6, 2000||Action Technologies, Inc.||Computerized method and system for managing business processes using linked workflows|
|US6098169||Dec 23, 1997||Aug 1, 2000||Intel Corporation||Thread performance analysis by monitoring processor performance event registers at thread switch|
|US6101524||Oct 23, 1997||Aug 8, 2000||International Business Machines Corporation||Deterministic replay of multithreaded applications|
|US6105051 *||Oct 23, 1997||Aug 15, 2000||International Business Machines Corporation||Apparatus and method to guarantee forward progress in execution of threads in a multithreaded processor|
|US6105129||Feb 18, 1998||Aug 15, 2000||Advanced Micro Devices, Inc.||Converting register data from a first format type to a second format type if a second type instruction consumes data produced by a first type instruction|
|US6134676||Apr 30, 1998||Oct 17, 2000||International Business Machines Corporation||Programmable hardware event monitoring method|
|US6145077||May 14, 1996||Nov 7, 2000||Sgs-Thomson Microelectronics Limited||Manipulation of data|
|US6149318||Apr 15, 1997||Nov 21, 2000||Samuel C. Kendall||Link-time and run-time error detection, and program instrumentation|
|US6185671||Mar 31, 1998||Feb 6, 2001||Intel Corporation||Checking data type of operands specified by an instruction using attributes in a tagged array architecture|
|US6189141||May 4, 1998||Feb 13, 2001||Hewlett-Packard Company||Control path evaluating trace designator with dynamically adjustable thresholds for activation of tracing for high (hot) activity and low (cold) activity of flow control|
|US6192513||Nov 2, 1998||Feb 20, 2001||Hewlett-Packard Company||Mechanism for finding spare registers in binary code|
|US6199204||Sep 22, 1998||Mar 6, 2001||International Business Machines Corporation||Distribution of software updates via a computer network|
|US6202207||Aug 19, 1998||Mar 13, 2001||International Business Machines Corporation||Method and a mechanism for synchronized updating of interoperating software|
|US6206584||May 31, 1995||Mar 27, 2001||Rational Software Corporation||Method and apparatus for modifying relocatable object code files and monitoring programs|
|US6223338||Sep 30, 1998||Apr 24, 2001||International Business Machines Corporation||Method and system for software instruction level tracing in a data processing system|
|US6243804||Jul 22, 1998||Jun 5, 2001||Scenix Semiconductor, Inc.||Single cycle transition pipeline processing using shadow registers|
|US6247113||May 27, 1998||Jun 12, 2001||Arm Limited||Coprocessor opcode division by data type|
|US6256775 *||Dec 11, 1997||Jul 3, 2001||International Business Machines Corporation||Facilities for detailed software performance analysis in a multithreaded processor|
|US6286132||Jan 7, 1999||Sep 4, 2001||Matsushita Electric Industrial Co., Ltd.||Debugging support apparatus, a parallel execution information generation device, a computer-readable recording medium storing a debugging support program, and a computer-readable recording medium storing a parallel execution information generation program|
|US6324689||Sep 30, 1998||Nov 27, 2001||Compaq Computer Corporation||Mechanism for re-writing an executable having mixed code and data|
|US6330662||Feb 23, 1999||Dec 11, 2001||Sun Microsystems, Inc.||Apparatus including a fetch unit to include branch history information to increase performance of multi-cylce pipelined branch prediction structures|
|US6351844||Nov 5, 1998||Feb 26, 2002||Hewlett-Packard Company||Method for selecting active code traces for translation in a caching dynamic translator|
|US6374364||Jan 19, 1999||Apr 16, 2002||Honeywell International, Inc.||Fault tolerant computing system using instruction counting|
|US6381679||Jul 3, 2000||Apr 30, 2002||Hitachi, Ltd.||Information processing system with prefetch instructions having indicator bits specifying cache levels for prefetching|
|US6430741||Feb 26, 1999||Aug 6, 2002||Hewlett-Packard Company||System and method for data coverage analysis of a computer program|
|US6442585||Nov 26, 1997||Aug 27, 2002||Compaq Computer Corporation||Method for scheduling contexts based on statistics of memory system interactions in a computer system|
|US6446029||Jun 30, 1999||Sep 3, 2002||International Business Machines Corporation||Method and system for providing temporal threshold support during performance monitoring of a pipelined processor|
|US6460135||Oct 4, 1999||Oct 1, 2002||Nec Corporation||Data type conversion based on comparison of type information of registers and execution result|
|US6480938||Dec 15, 2000||Nov 12, 2002||Hewlett-Packard Company||Efficient I-cache structure to support instructions crossing line boundaries|
|US6539458||Apr 24, 2001||Mar 25, 2003||Telefonaktiebolaget Lm Ericsson (Publ)||Hierarchical memory for efficient data exchange control|
|US6549930||Nov 26, 1997||Apr 15, 2003||Compaq Computer Corporation||Method for scheduling threads in a multithreaded processor|
|US6598153||Dec 10, 1999||Jul 22, 2003||International Business Machines Corporation||Processor and method that accelerate evaluation of pairs of condition-setting and branch instructions|
|US6647301||Jan 12, 2000||Nov 11, 2003||Dow Global Technologies Inc.||Process control system with integrated safety control system|
|US6654781 *||Dec 11, 1998||Nov 25, 2003||International Business Machines Corporation||Enhanced thread processing|
|US6658416 *||Jul 10, 2000||Dec 2, 2003||International Business Machines Corporation||Apparatus and method for creating an indexed database of symbolic data for use with trace data of a computer program|
|US6687794||Oct 18, 2001||Feb 3, 2004||International Business Machines Corporation||Prefetching mechanism for data caches|
|US6721875||Feb 22, 2000||Apr 13, 2004||Hewlett-Packard Development Company, L.P.||Method and apparatus for implementing a single-syllable IP-relative branch instruction and a long IP-relative branch instruction in a processor which fetches instructions in bundle form|
|US6735666||Feb 22, 2000||May 11, 2004||Wind River Systems, Inc.||Method of providing direct user task access to operating system data structures|
|US6782454||Sep 29, 2000||Aug 24, 2004||Sun Microsystems, Inc.||System and method for pre-fetching for pointer linked data structures|
|US6842850||Feb 25, 2003||Jan 11, 2005||Intel Corporation||DSP data type matching for operation using multiple functional units|
|US6848029||Jan 3, 2001||Jan 25, 2005||Dirk Coldewey||Method and apparatus for prefetching recursive data structures|
|US6865666||Sep 3, 1998||Mar 8, 2005||Renesas Technology Corp.||Data processing device|
|US6871298||Nov 10, 2000||Mar 22, 2005||Obsidian Software, Inc.||Method and apparatus that simulates the execution of paralled instructions in processor functional verification testing|
|US6928521||Aug 1, 2000||Aug 9, 2005||International Business Machines Corporation||Method, system, and data structures for using metadata in updating data in a storage device|
|US6944720||Mar 27, 2003||Sep 13, 2005||Intel Corporation||Memory system for multiple data types|
|US6973417||Nov 5, 1999||Dec 6, 2005||Metrowerks Corporation||Method and system for simulating execution of a target program in a simulated target system|
|US6973542||Jul 18, 2000||Dec 6, 2005||International Business Machines Corporation||Detecting when to prefetch inodes and then prefetching inodes in parallel|
|US6988186 *||Jun 28, 2001||Jan 17, 2006||International Business Machines Corporation||Shared resource queue for simultaneous multithreading processing wherein entries allocated to different threads are capable of being interspersed among each other and a head pointer for one thread is capable of wrapping around its own tail in order to access a free entry|
|US7024668||May 11, 2001||Apr 4, 2006||Matsushita Electric Industrial Co., Ltd.||Application execution apparatus and method|
|US7035996||Aug 19, 2003||Apr 25, 2006||Raytheon Company||Generating data type token value error in stream computer|
|US7207043||Dec 31, 2002||Apr 17, 2007||International Business Machines Corporation||Programmatic response-time based workload distribution techniques|
|US7237242||Dec 31, 2002||Jun 26, 2007||International Business Machines Corporation||Dynamic thread pool tuning techniques|
|US20010032305||Feb 23, 2001||Oct 18, 2001||Barry Edwin F.||Methods and apparatus for dual-use coprocessing/debug interface|
|US20020010733 *||Mar 16, 2001||Jan 24, 2002||Yosuke Baba||Data processing device equipped with a thread switching circuit|
|US20020019976||May 25, 2001||Feb 14, 2002||Patel Mukesh K.||Java hardware accelerator using thread manager|
|US20020124237||Dec 29, 2000||Sep 5, 2002||Brinkley Sprunt||Qualification of event detection by thread ID and thread privilege level|
|US20020129309||Dec 18, 2000||Sep 12, 2002||Floyd Michael S.||Method and system for triggering a debugging unit|
|US20020147965||Feb 1, 2001||Oct 10, 2002||Swaine Andrew Brookfield||Tracing out-of-order data|
|US20020199179||Jun 21, 2001||Dec 26, 2002||Lavery Daniel M.||Method and apparatus for compiler-generated triggering of auxiliary codes|
|US20030041096||Apr 12, 2002||Feb 27, 2003||International Business Machines Corporation||Transaction processing in a distributed data processing system|
|US20030126590||Dec 28, 2001||Jul 3, 2003||Michael Burrows||System and method for dynamic data-type checking|
|US20040153612||May 21, 2002||Aug 5, 2004||Stephane Mutz||Method and system for accelerated access to a memory|
|US20040216104 *||Apr 24, 2003||Oct 28, 2004||International Business Machines Corporation||Atomic quad word storage in a simultaneous multithreaded system|
|US20040216105 *||Apr 24, 2003||Oct 28, 2004||International Business Machines Corporation||Method for resource balancing using dispatch flush in a simultaneous multithread processor|
|US20050091456||Oct 23, 2003||Apr 28, 2005||Huck Jerome C.||Determining an arrangement of data in a memory for cache efficiency|
|US20050102673 *||Nov 6, 2003||May 12, 2005||International Business Machines Corporation||Apparatus and method for autonomic hardware assisted thread stack tracking|
|US20050108483||Nov 19, 2003||May 19, 2005||Buffalo Inc.||Indicator for memory module|
|US20050177822||Feb 28, 2005||Aug 11, 2005||Microsoft Corporation||Profile-driven data layout optimization|
|US20050257092||Apr 29, 2004||Nov 17, 2005||International Business Machines Corporation||Method and apparatus for identifying access states for variables|
|JP2000029731A||Title not available|
|JP2000347863A||Title not available|
|1||"Cache Miss Director-A Means of Prefetching Cache Missed Lines", Aug. 1, 1982, IBM Technical Disclosure Bulletin, vol. 25, Issue 3A, pp. 1286.|
|2||"Method for the dynamic prediction of nonsequential memory accesses", Sep. 25, 2002, pp. 1-4, ip.com IPCOM000009888D.|
|3||"Cache Miss Director—A Means of Prefetching Cache Missed Lines", Aug. 1, 1982, IBM Technical Disclosure Bulletin, vol. 25, Issue 3A, pp. 1286.|
|4||Cohen et al., "Hardware-Assisted Characterization of NAS Benchmarks", Cluster Computing, vol. 4, No. 3, Jul. 2001, pp. 189-196.|
|5||Grunwald et al., "Whole Program Optimization for Time and Space Efficient Threads", pp. 50-59, Proceedings of the 7th International Conference on Architectural Support for Programming Languages and Operating Systems, Cambridge Massachusetts,1996.|
|6||IBM Research Disclosure Bulletin 444188, "Enable Debuggers as an Objective Performance Measurement Tool for Software Development Cost Reduction", Apr. 2001, pp. 686-688.|
|7||Iwasawa et al., "Parallelization Method of Fortran DO Loops by Parallelizing Assist System", Transactions of Information Processings Society of Japan, vol. 36, No. 8, Aug. 1995, pp. 1995-2006.|
|8||Kikuchi, "Parallelization Assist System", Joho Shori, vol. 34, No. 9, Sep. 1993, pp. 1158-1169.|
|9||Talla et al., "Evaluating Signal Processing and Multimedia Applications on SIMD, VLIW and Super Scalar Architectures", International Conference on Computer Design, Austin, Sep. 17-20, 2000, pp. 163-172.|
|10||Talla et al., "Execution Characteristics of Multimedia Applications on a Pentium II Processor", IEEE International Performance, Computing, and Communications Conference, 19th, Phoenix, Feb. 20-22, 2000, pp. 516-524.|
|11||Tanenbaum, "Structured Computer Organization", Prentice Hall, 1984, pp. 10-12.|
|12||U.S. Appl. No. 08/538,071, filed Oct. 2, 1995, Gover et al., Method and System for Selecting and Distinguishing an Event Sequence using an Effective Address in a Processing System.|
|13||U.S. Appl. No. 09/435,069 AT9-99-491, filed Nov. 4, 1999, Davidson et al., Method and Apparatus for Instruction Sampling for Performance Monitoring and Debug.|
|14||U.S. Appl. No. 10/674,604, filed Sep. 30, 2003, Levine et al., Method and Apparatus for Selectively Counting Instructions and Data Accesses.|
|15||U.S. Appl. No. 10/674,606, filed Sep. 30, 2003, Levine et al., Method and Apparatus to Autonomically Take an Exception on Specified Instructions.|
|16||U.S. Appl. No. 10/674,642, filed Sep. 30, 2003, Levine et al., Method and Apparatus to Autonomically Count Instruction Execution for Applications.|
|17||U.S. Appl. No. 10/675,721, filed Sep. 30, 2003, Levine et al., Method and Apparatus to Autonomically Select Instructions for Selective Counting.|
|18||U.S. Appl. No. 10/675,751, filed Sep. 30, 2003, DeWitt, Jr. et al., Method and Apparatus for Debug Support for Individual Instructions and Memory Locations.|
|19||U.S. Appl. No. 10/675,776, filed Sep. 30, 2008, DeWitt, Jr. et al., Method and Apparatus for Counting Execution of Specific Instructions and Accesses to Specific Data Locations.|
|20||U.S. Appl. No. 10/675,777, filed Sep. 30, 2003, DeWitt, Jr. et al., Method and Apparatus for Counting Instruction Execution and Data Accesses.|
|21||U.S. Appl. No. 10/675,778, filed Sep. 30, 2003, DeWitt, Jr. et al., Method and Apparatus for Counting Data Accesses and Instruction Executions that Exceed a Threshold.|
|22||U.S. Appl. No. 10/675,783, filed Sep. 30, 2003, Levine et al., Method and Apparatus to Autonomically Profile Applications.|
|23||U.S. Appl. No. 10/675,831, filed Sep. 30, 2003, DeWitt, Jr. et al., Method and Apparatus for Generating Interrupts Upon Execution of Marked Instructions and Upon Access to Marked Memory Locations.|
|24||U.S. Appl. No. 10/675,872, filed Sep. 30, 2003, DeWitt, Jr. et al., Method and Apparatus for Counting Instruction and Memory Location Ranges.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8381037||Oct 9, 2003||Feb 19, 2013||International Business Machines Corporation||Method and system for autonomic execution path selection in an application|
|US8539453 *||Jun 30, 2010||Sep 17, 2013||International Business Machines Corporation||Autonomic I/O tracing and performance tuning|
|US8615619||Jan 11, 2011||Dec 24, 2013||International Business Machines Corporation||Qualifying collection of performance monitoring events by types of interrupt when interrupt occurs|
|US8689190||Jan 29, 2008||Apr 1, 2014||International Business Machines Corporation||Counting instruction execution and data accesses|
|US8782664||Jan 11, 2012||Jul 15, 2014||International Business Machines Corporation||Autonomic hardware assist for patching code|
|US8938533 *||Jul 22, 2011||Jan 20, 2015||AppDynamics Inc.||Automatic capture of diagnostic data based on transaction behavior learning|
|US9015317||Nov 4, 2013||Apr 21, 2015||AppDynamics, Inc.||Conducting a diagnostic session for monitored business transactions|
|US9037707||Nov 4, 2013||May 19, 2015||AppDynamics, Inc.||Propagating a diagnostic session for business transactions across multiple servers|
|US9058421 *||Jun 16, 2009||Jun 16, 2015||Freescale Semiconductor, Inc.||Trace correlation for profiling subroutines|
|US9077610||Nov 4, 2013||Jul 7, 2015||AppDynamics, Inc.||Performing call stack sampling|
|US20100318972 *||Jun 16, 2009||Dec 16, 2010||Freescale Semiconductor, Inc.||Trace Correlation for Profiling Subroutines|
|US20120005580 *||Jun 30, 2010||Jan 5, 2012||International Business Machines Corporation||Autonomic I/O Tracing and Performance Tuning|
|U.S. Classification||717/133, 717/128, 712/227, 714/30|
|International Classification||G06F9/44, G06F9/00|
|Cooperative Classification||G06F11/3409, G06F2201/88, G06F11/3471, G06F2201/86|
|European Classification||G06F11/34C, G06F11/34T|
|May 14, 2004||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DEWITT, JR., JIMMIE EARL;LEVINE, FRANK ELIOT;RICHARDSON,CHRISTOPHER MICHAEL;AND OTHERS;REEL/FRAME:014632/0709
Effective date: 20040316
|Mar 6, 2015||REMI||Maintenance fee reminder mailed|
|Jul 26, 2015||LAPS||Lapse for failure to pay maintenance fees|
|Sep 15, 2015||FP||Expired due to failure to pay maintenance fee|
Effective date: 20150726