US20070169051A1 - Identifying Code that Wastes Time Performing Redundant Computation - Google Patents

Identifying Code that Wastes Time Performing Redundant Computation Download PDF

Info

Publication number
US20070169051A1
US20070169051A1 US11/164,105 US16410505A US2007169051A1 US 20070169051 A1 US20070169051 A1 US 20070169051A1 US 16410505 A US16410505 A US 16410505A US 2007169051 A1 US2007169051 A1 US 2007169051A1
Authority
US
United States
Prior art keywords
counter
memory address
code
access
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US11/164,105
Other versions
US7698690B2 (en
Inventor
Kirk Krauss
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/164,105 priority Critical patent/US7698690B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KRAUSS, KIRK J.
Priority to CNB2006101444787A priority patent/CN100440163C/en
Publication of US20070169051A1 publication Critical patent/US20070169051A1/en
Application granted granted Critical
Publication of US7698690B2 publication Critical patent/US7698690B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs
    • G06F11/3612Software analysis for verifying properties of programs by runtime analysis

Definitions

  • the present invention relates to the field of software development and, more particularly, to software development tools for performing runtime analysis on computer programs.
  • redundancy One type of inefficiency found in computer program code is referred to as redundancy. While some redundancy is regarded as a normal aspect of application development, other forms of redundancy are not. For example, computer program code responsible for functions such as loop control, memory block initialization, and the like, require a certain degree of redundancy to function properly. This redundancy is regarded as necessary and useful.
  • redundancy in computer program code that is not necessary is regarded as useless.
  • Useless redundancy can, and often does, result in degraded program performance as noted above. Detecting instances in which computer program code is responsible for performing useless redundant computation, however, can be difficult. This is particularly true with modern computer programs that rely upon complex relationships among threads and functions that may, and often do, share common computing resources.
  • One embodiment of the present invention can include a method of runtime analysis of a computer program.
  • the method can include incrementing a counter associated with a memory address after each access of a first type to the memory address and comparing the counter associated with a memory address with a threshold after each access of a second type to the memory address.
  • the method further can include identifying at least one memory address having a counter that exceeds the threshold and determining a portion of code of the computer program that is responsible for accessing the memory address associated with the counter that exceeds the threshold.
  • Another embodiment of the present invention can include a method of runtime analysis of a computer program.
  • the method can include comparing a value previously stored in a memory address with a value that is written to the memory address for each write access to a memory address, and if the value previously stored is the same as the value that is written, incrementing a counter associated with the memory address.
  • the method further can include identifying a portion of code of the computer program that is responsible for accessing a memory address having an associated counter that conforms with an established criterion.
  • Another embodiment of the present invention can include a machine readable storage, having stored thereon, a computer program having a plurality of code sections executable by a machine for causing the machine to perform the various steps and methods disclosed herein.
  • FIG. 1 is a flow chart illustrating a method of identifying portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention.
  • FIG. 2 is a flow chart illustrating a method of indicating portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention.
  • FIG. 3 is a flow chart illustrating a method of identifying portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention.
  • FIG. 4 is a flow chart illustrating a method of indicating portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention.
  • FIG. 5 is a flow chart illustrating a method of identifying portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention.
  • FIG. 6 is a flow chart illustrating a method of indicating portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention.
  • the embodiments disclosed herein provide a solution for detecting redundant, also referred to as useless, computation performed by computer program code. More particularly, the embodiments disclosed herein can detect instances in which memory locations are needlessly read and/or written. In general, the embodiments discussed herein track read and write accesses to memory locations performed by a computer program during runtime. The records of the read and/or write accesses can be analyzed to determine which portions of the computer program code are responsible for one or more instances of redundant computation and/or processing.
  • access can refer to either a read operation involving a memory address and/or a write operation involving a memory address.
  • examples of redundant and/or useless computations that involve memory can include, but are not limited to, repeated writes to a memory address involving unchanging values that are stored in the memory address, multiple writes to a memory address with no intervening reads from that memory address, and/or repeated reads from a memory address that involve unchanging values.
  • the various functions described herein can be implemented using a software analysis tool.
  • the various functions described herein can be implemented as extensions of one or more members of the Rational PurifyPlus family of software analysis tools which are commercially available from International Business Machines Corporation of Armonk, N.Y. (IBM).
  • PurifyPlus is a family of computer programs that provides runtime analysis functionality to software developers and testers. In general, runtime analysis refers to the practice of understanding application behavior using data collected during execution of the application, also referred to as the computer program under test.
  • the present invention further can include functionality for generating call graphs via runtime analysis.
  • a tool called Quantify for example, which is a member of the PurifyPlus product family, can produce call graphs for a computer program under test.
  • a call graph refers to a diagram that identifies the functions, methods, and/or modules in a system or computer program and shows which functions, methods, and/or modules invoke one another.
  • a call graph also can be referred to as a call tree or a tier chart, which comprises nodes representing various portions of computer code, i.e. functions, methods, and/or modules.
  • redundancy records can be maintained and/or stored along with call chain information to indicate the particular computer program code responsible for the unnecessary memory address access(es).
  • a redundancy record is a collection of one or more attributes that is used to monitor activity relating to access(es) of a memory address.
  • the redundancy records are created and/or maintained by the runtime analysis tool and/or code inserted into a computer program under test by such a tool. Accordingly, each redundancy record can be associated with a particular memory address.
  • Examples of the attributes maintained by a redundancy record can include, but are not limited to, the virtual memory address that is accessed, the value of the program counter, which is a pointer to the current instruction as of the time of access to the memory location, a count of the number of write accesses that did not change the value at that memory address, a threshold serving as a “high water mark” for the count of write accesses that did not change the value at the memory address, a count of the number of the write accesses that have the same program counter value and that did not change the value at memory addresses, as well as a threshold serving as a “high water mark” for the count of the number of write accesses that have the same program counter value and that did not change the value at memory addresses.
  • Redundancy records further can include a count of the number of read accesses that did not correspond to write accesses, a count of the number of read accesses that did not correspond to write accesses that have the same program counter, as well as a threshold serving as a “high water mark” for each of these counts.
  • the redundancy records further can include one or more pointers to data representing a call graph for the methods that made the redundant memory accesses.
  • the runtime analysis tool can execute in conjunction with the computer program under test.
  • the runtime analysis tool can execute at the same time as, and cooperatively with, the computer program under test. Accordingly, the runtime analysis tool can intercept read and/or write operations, as the case may be, to track memory access activity as discussed herein.
  • the runtime analysis tool can insert within, or instrument, the computer program under test with appropriate code for performing the various steps described herein.
  • the runtime analysis tool does not actually execute in conjunction with the computer program under test. Rather, the computer program under test executes in a modified form which includes the inserted code from the runtime analysis tool. Still, it can be said that the runtime analysis tool “performs” the various steps described herein.
  • FIG. 1 is a flow chart illustrating a method 100 of identifying portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention.
  • Method 100 illustrates an embodiment of the present invention that detects instances of wasteful write accesses where a value is written to a memory address that is the same as the value that was already, or previously, stored in that memory address. Accordingly, method 100 can begin in step 105 where the software analysis tool can begin monitoring for write accesses to memory locations that are performed by the computer program under test during runtime and detect such an access.
  • step 110 the current value of the program counter can be stored.
  • step 115 the contents of the memory address that was accessed can be stored locally. Further, in step 115 , a determination can be made by the analysis tool as to whether the new value being stored in the memory address that was accessed is the same as the value that was already stored in the memory address, i.e. prior to the detected write operation. If so, the method can proceed to step 120 . If not, the method can proceed to step 180 , where the computer program under test continues to execute until such time that another access to a memory address is detected and/or occurs.
  • the redundancy record for the accessed, or current, memory address can be selected. If a redundancy record for the current memory address does exist, the method can proceed to step 130 . If not, the method can continue to step 155 . In step 130 , a reference to the call graph node(s) associated with the program counter value stored in step 110 can be stored in the current redundancy record.
  • a write access redundancy count for the current redundancy record, and thus the current memory address can be incremented.
  • the write access redundancy count can be a count of the number of write accesses that did not change the value at the target memory address. Because each redundancy record can maintain such a count, each memory address may have an associated count.
  • step 140 a determination can be made as to whether the value of the program counter stored in step 110 is the same as the prior value of the program counter, for example the program counter value that was previously stored in the current redundancy record. That is, the current value of the program counter can be compared with the value of the program counter that was stored during the last time the method tracked through the branch including step 140 . If so, the method can proceed to step 145 where a counter that tracks the number of write accesses that have a matching program counter value and that did not change the value at the target memory address is incremented. If not, the method can continue to step 150 . In step 150 , the value of the program counter stored in step 110 can be copied into the current redundancy record to be used in subsequent program counter comparisons. After step 150 , the method can proceed to step 180 , where the computer program under test continues to execute.
  • a redundancy record for the current memory address can be added and/or created.
  • the write access redundancy count for the current redundancy record can be set and/or initialized to “1”.
  • the value of the program counter stored in step 110 can be copied into the current redundancy record to be used in subsequent program counter comparisons.
  • the program counter redundancy count for the current redundancy record can be set and/or initialized to “1”.
  • a reference to the call graph node(s) associated with the program counter value stored in step 110 can be stored in the current redundancy record.
  • the computer program under test can continue to run.
  • FIG. 2 is a flow chart illustrating a method 200 of indicating portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention.
  • Method 200 can provide results determined from implementation of the method illustrated in FIG. 1 . As such, it can be performed upon detection of a report condition.
  • a report condition can be any of a variety of conditions which indicate that results from monitoring accesses to memory addresses are to be provided in one form or another. For example, such conditions can include, but are not limited to, termination of the computer program under test, a user request for report data, a count exceeding a threshold, whether that threshold is determined by the analysis tool or specified by the user, or the like.
  • a report condition can be detected.
  • the address(es) having a redundancy record indicating the highest write access redundancy count can be selected.
  • a determination can be made as to whether more than one address was selected. If so, the method can proceed to step 220 . If not, the method can continue to step 225 .
  • step 220 of the memory addresses selected in step 210 , a subset of such memory address(es) having a redundancy record specifying the highest program counter redundancy can be selected. Other memory addresses originally selected in step 210 , but not included in the subset defined in step 220 can be deselected.
  • the portions of code responsible for accessing the selected memory address(es) can be indicated.
  • the call graph nodes corresponding to the responsible portions of code can be highlighted or otherwise indicated to the user. Such information can be obtained from the redundancy records corresponding to the selected memory address(es).
  • FIG. 3 is a flow chart illustrating a method 300 of identifying portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention.
  • Method 300 can detect instances in which values have been written to memory addresses without intervening read accesses of those memory addresses. Accordingly, method 300 can begin in step 302 where the occurrence of a memory access, whether a read or a write, has been detected. If the access is a write, the method can proceed to step 304 . If the access is a read, the method can continue to step 360 .
  • step 304 the value of the current program counter can be stored.
  • step 306 the redundancy record for the current memory address, i.e. the memory address that was accessed as detected in step 302 , can be selected. If no redundancy record exists for the current memory address, the method can proceed to step 310 . If a redundancy record does exist, the method can proceed to step 330 .
  • a redundancy record in the case where a redundancy record does not exist for the current memory address, a redundancy record can be created.
  • a count of writes with no corresponding reads can be set and/or initialized to “0” in step 315 .
  • a count of writes with no corresponding reads that have a matching program counter value can be set and/or initialized to “0”.
  • step 330 in the case where a redundancy record does exist for the current memory address, the count of writes with no corresponding reads can be incremented.
  • step 335 a determination can be made as to whether the value of the program counter stored in step 304 is the same as the previous value of the program counter, i.e. the program counter stored in the current redundancy record. If so, the method can continue to step 340 where a counter of writes with no corresponding reads that have the same program counter value can be incremented.
  • step 345 a reference to the call graph node(s) associated with the program counter value stored in step 304 can be stored in the current redundancy record.
  • step 350 the value of the program counter stored in step 304 can be copied into the current redundancy record to be used in subsequent program counter comparisons.
  • step 355 the computer program under test can continue to run.
  • step 360 where the detected memory access in step 302 was a read access, a determination can be made as to whether a redundancy record exists for the current memory address. If not, the method can continue to step 355 where the computer program under test continues to execute. If a redundancy record does exist, that redundancy record can be selected in step 365 .
  • the value of threshold_ 1 wr can be established as the “high water mark”, meaning a marker or indication of the highest count of write accesses with no corresponding read accesses of each redundancy record. If the count exceeds threshold_ 1 wr , the value of the count of writes with no reads can be stored as the new value of threshold_ 1 wr in step 375 . If not, the method can proceed to step 380 .
  • the value of threshold_ 2 wr can be established as a “high water mark” in that it is a marker or indication of the highest count of writes with no corresponding reads that have the same program counter value for a particular redundancy record. Thus, if the count of writes with no corresponding reads that have a matching program counter value exceeds the value of threshold_ 2 wr , that count can be stored as the new value of threshold_ 2 wr in step 385 .
  • step 380 or step 385 the counter for writes with no corresponding reads can be reset and/or initialized to “0” in step 390 .
  • step 395 the count of writes with no reads that have the same program counter value also can be reset and/or initialized to “0”.
  • FIG. 4 is a flow chart illustrating a method 400 of indicating portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention.
  • Method 400 can provide results determined from implementation of the method illustrated in FIG. 3 , for example in response to the detection of a report condition.
  • a report condition can be detected.
  • the address(es) having a redundancy record indicating the highest count of writes without corresponding reads can be selected.
  • a determination can be made as to whether more than one address was selected in step 410 . If so, the method can proceed to step 420 . If not, the method can continue to step 425 .
  • step 420 of the memory addresses selected in step 410 , a subset of those address(es) having the highest program counter redundancy can be selected. Memory addresses originally selected in step 410 that are not included in the subset defined in step 420 can be deselected.
  • the portions of code responsible for accessing the selected memory address(es) can be indicated.
  • the call graph nodes corresponding to the responsible portions of code can be highlighted or otherwise indicated to the user.
  • FIG. 5 is a flow chart illustrating a method 500 of identifying portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention.
  • Method 500 can detect instances in which values have been read from a memory address multiple times without intervening write operations. This condition indicates that a read operation has been performed only to read an unchanged value from a memory address. Accordingly, method 500 can begin in step 502 where the occurrence of a memory access, whether a read or a write, has been detected. If the access is a read, the method can proceed to step 504 . If the access is a write, the method can continue to step 555 .
  • step 504 the value of the current program counter can be stored.
  • step 506 a redundancy record for the current memory address, i.e. the memory address that was accessed as detected in step 502 , can be selected. If no redundancy record exists for the current memory address, the method can proceed to step 508 . If a redundancy record does exist, the method can proceed to step 525 .
  • a redundancy record can be created.
  • a count of reads with no corresponding writes can be set and/or initialized to “0” in step 510 .
  • a count of reads with no corresponding writes having a matching program counter value can be set and/or initialized to “0”.
  • a threshold value, referred to as threshold_ 1 rw of reads with no corresponding writes can be set and/or initialized to “0”. The value of threshold_ 1 rw can be established as the “high water mark” or the highest count of read accesses with no corresponding write accesses of each redundancy record.
  • threshold_ 2 rw a threshold of reads with no corresponding writes having a same program counter value
  • threshold_ 2 rw can be set and/or initialized to “0”.
  • Threshold_ 2 rw can serve as a “high water mark” for the highest count of read accesses with no corresponding write accesses having a same program counter value.
  • step 525 in the case where a redundancy record does exist for the current memory address, the count of reads with no corresponding writes within the current redundancy record can be incremented.
  • step 530 a determination can be made as to whether the program counter value stored in step 504 is the same as the previous value of the program counter stored in the current redundancy record. If so, the method can continue to step 535 where a counter of reads with no corresponding writes that have the same program counter can be incremented.
  • a reference to the call graph node(s) associated with the program counter value stored in step 504 can be stored in the current redundancy record.
  • the value of the program counter stored in step 504 can be copied into the current redundancy record to be used in subsequent program counter comparisons.
  • the computer program under test can continue to run.
  • step 555 where the detected memory access in step 502 was a write access, a determination can be made as to whether a redundancy record exists for the current memory address. If not, the method can proceed to step 550 to continue to run. If a redundancy record does exist, the redundancy record can be selected as the current redundancy record in step 560 . In step 565 , a determination can be made as to whether the count of reads with no corresponding writes exceeds the current value of threshold_ 1 rw . If so, the value of the count of reads with no writes can be stored as the new value of threshold_ 1 rw in step 570 . If not, the method can proceed to step 575 .
  • step 575 a determination can be made as to whether the count of reads with no corresponding writes having a matching program counter value exceeds the current value of threshold_ 2 rw . If so, the count of reads with no corresponding writes can be stored as the new value of threshold_ 2 rw in step 580 .
  • the method can proceed to step 585 where the counter for reads with no corresponding writes can be set and/or initialized to “0”.
  • the counter for reads with no corresponding writes that have a matching program counter value can be reset and/or initialized to “0”. After step 590 , the method can proceed to step 550 .
  • FIG. 6 is a flow chart illustrating a method 600 of indicating portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention.
  • Method 600 can provide results determined from implementation of the method illustrated in FIG. 5 , for example in response to the detection of a report condition.
  • a report condition can be detected.
  • the address(es) having a redundancy record indicating the highest count of reads without corresponding writes can be selected.
  • a determination can be made as to whether more than one memory address was selected in step 610 . If so, the method can proceed to step 620 . If not, the method can continue to step 6250 .
  • step 620 of the memory addresses selected in step 610 , a subset of such memory address(es) that have a highest program counter redundancy can be selected. Memory addresses originally selected in step 610 that are not included in the subset defined in step 620 can be deselected.
  • the portions of code responsible for accessing the selected memory address(es) can be indicated.
  • the call graph nodes corresponding to the responsible portions of code can be highlighted or otherwise indicated to the user.
  • FIGS. 1-6 illustrate various techniques for identifying portions of code that are responsible for unnecessary processing and/or computation within computer programs.
  • the details and steps described herein are provided for purposes of illustration and are not intended to limit the present invention in any way.
  • portions of code responsible for a number of instances of redundant processing that exceeds a user specified threshold can be identified.
  • a plurality of portions of code can be identified rather than a portion of code responsible for the largest number of instances of redundant processing.
  • Other variations also are within the scope of the present invention such as varying the conditions upon which report information is provided to a user.
  • the present invention can be realized in hardware, software, or a combination of hardware and software.
  • the present invention can be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited.
  • a typical combination of hardware and software can be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
  • the present invention also can be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods.
  • a computer program means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
  • a computer program can include, but is not limited to, a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system.
  • the terms “a” and “an”, as used herein, are defined as one or more than one.
  • the term “plurality”, as used herein, is defined as two or more than two.
  • the term “another”, as used herein, is defined as at least a second or more.
  • the terms “including” and/or “having”, as used herein, are defined as comprising (i.e., open language).
  • the term “coupled”, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically, i.e. communicatively linked through a communication channel or pathway.

Abstract

A method of runtime analysis of a computer program can include, after each access of a first type to a memory address, incrementing a counter associated with the memory address and, after each access of a second type to a memory address, comparing the counter associated with the memory address with a threshold. The method further can include identifying at least one memory address having a counter that exceeds the threshold and determining a portion of code responsible for accessing the memory address associated with the counter that exceeds the threshold.

Description

    FIELD OF THE INVENTION
  • The present invention relates to the field of software development and, more particularly, to software development tools for performing runtime analysis on computer programs.
  • DESCRIPTION OF THE RELATED ART
  • Application developers generally try to write efficient computer program code. Inefficient computer program code can suffer a decrease in performance in that the execution time of the resulting program typically increases. One type of inefficiency found in computer program code is referred to as redundancy. While some redundancy is regarded as a normal aspect of application development, other forms of redundancy are not. For example, computer program code responsible for functions such as loop control, memory block initialization, and the like, require a certain degree of redundancy to function properly. This redundancy is regarded as necessary and useful.
  • By comparison, redundancy in computer program code that is not necessary is regarded as useless. Useless redundancy can, and often does, result in degraded program performance as noted above. Detecting instances in which computer program code is responsible for performing useless redundant computation, however, can be difficult. This is particularly true with modern computer programs that rely upon complex relationships among threads and functions that may, and often do, share common computing resources.
  • Presently, useless redundancy of the sort described herein cannot be corrected in an automatic fashion through the use of improved compilation. It would be beneficial to provide a mechanism and/or technique for identifying instances of useless redundancy and/or unnecessary computation within computer program code.
  • SUMMARY OF THE INVENTION
  • The embodiments disclosed herein provide methods and articles of manufacture relating to the identification of portions of code of a computer program that are responsible for unnecessary computation. One embodiment of the present invention can include a method of runtime analysis of a computer program. The method can include incrementing a counter associated with a memory address after each access of a first type to the memory address and comparing the counter associated with a memory address with a threshold after each access of a second type to the memory address. The method further can include identifying at least one memory address having a counter that exceeds the threshold and determining a portion of code of the computer program that is responsible for accessing the memory address associated with the counter that exceeds the threshold.
  • Another embodiment of the present invention can include a method of runtime analysis of a computer program. The method can include comparing a value previously stored in a memory address with a value that is written to the memory address for each write access to a memory address, and if the value previously stored is the same as the value that is written, incrementing a counter associated with the memory address. The method further can include identifying a portion of code of the computer program that is responsible for accessing a memory address having an associated counter that conforms with an established criterion.
  • Another embodiment of the present invention can include a machine readable storage, having stored thereon, a computer program having a plurality of code sections executable by a machine for causing the machine to perform the various steps and methods disclosed herein.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • There are shown in the drawings, embodiments which are presently preferred; it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.
  • FIG. 1 is a flow chart illustrating a method of identifying portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention.
  • FIG. 2 is a flow chart illustrating a method of indicating portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention.
  • FIG. 3 is a flow chart illustrating a method of identifying portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention.
  • FIG. 4 is a flow chart illustrating a method of indicating portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention.
  • FIG. 5 is a flow chart illustrating a method of identifying portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention.
  • FIG. 6 is a flow chart illustrating a method of indicating portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • While the specification concludes with claims defining the features of the invention that are regarded as novel, it is believed that the invention will be better understood from a consideration of the description in conjunction with the drawings. As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention, which can be embodied in various forms. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present invention in virtually any appropriately detailed structure. Further, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of the invention.
  • The embodiments disclosed herein provide a solution for detecting redundant, also referred to as useless, computation performed by computer program code. More particularly, the embodiments disclosed herein can detect instances in which memory locations are needlessly read and/or written. In general, the embodiments discussed herein track read and write accesses to memory locations performed by a computer program during runtime. The records of the read and/or write accesses can be analyzed to determine which portions of the computer program code are responsible for one or more instances of redundant computation and/or processing.
  • There are several possible indicators of computational redundancy. As noted, some of these indicators involve accesses to memory. The term “access”, as used herein, can refer to either a read operation involving a memory address and/or a write operation involving a memory address. In any case, examples of redundant and/or useless computations that involve memory can include, but are not limited to, repeated writes to a memory address involving unchanging values that are stored in the memory address, multiple writes to a memory address with no intervening reads from that memory address, and/or repeated reads from a memory address that involve unchanging values.
  • The various functions described herein can be implemented using a software analysis tool. In one embodiment, for example, the various functions described herein can be implemented as extensions of one or more members of the Rational PurifyPlus family of software analysis tools which are commercially available from International Business Machines Corporation of Armonk, N.Y. (IBM). PurifyPlus is a family of computer programs that provides runtime analysis functionality to software developers and testers. In general, runtime analysis refers to the practice of understanding application behavior using data collected during execution of the application, also referred to as the computer program under test.
  • The present invention further can include functionality for generating call graphs via runtime analysis. A tool called Quantify, for example, which is a member of the PurifyPlus product family, can produce call graphs for a computer program under test. In general, a call graph refers to a diagram that identifies the functions, methods, and/or modules in a system or computer program and shows which functions, methods, and/or modules invoke one another. A call graph also can be referred to as a call tree or a tier chart, which comprises nodes representing various portions of computer code, i.e. functions, methods, and/or modules.
  • The products discussed within this specification are intended to provide a basis for teaching one skilled in the art to better understand the embodiments disclosed herein. As such, it should be appreciated that the embodiments disclosed herein can be implemented as a standalone application, as a component or “plug-in” that is used as part of a larger application, or in virtually any appropriately detailed structure, computer program, and/or portion thereof.
  • In any case, using the runtime analysis tool, records of memory address accesses can be collected and reviewed to identify unnecessary computational redundancy. The records, referred to as redundancy records, can be maintained and/or stored along with call chain information to indicate the particular computer program code responsible for the unnecessary memory address access(es). As used herein, a redundancy record is a collection of one or more attributes that is used to monitor activity relating to access(es) of a memory address. The redundancy records are created and/or maintained by the runtime analysis tool and/or code inserted into a computer program under test by such a tool. Accordingly, each redundancy record can be associated with a particular memory address.
  • Examples of the attributes maintained by a redundancy record can include, but are not limited to, the virtual memory address that is accessed, the value of the program counter, which is a pointer to the current instruction as of the time of access to the memory location, a count of the number of write accesses that did not change the value at that memory address, a threshold serving as a “high water mark” for the count of write accesses that did not change the value at the memory address, a count of the number of the write accesses that have the same program counter value and that did not change the value at memory addresses, as well as a threshold serving as a “high water mark” for the count of the number of write accesses that have the same program counter value and that did not change the value at memory addresses.
  • Redundancy records further can include a count of the number of read accesses that did not correspond to write accesses, a count of the number of read accesses that did not correspond to write accesses that have the same program counter, as well as a threshold serving as a “high water mark” for each of these counts. The redundancy records further can include one or more pointers to data representing a call graph for the methods that made the redundant memory accesses.
  • In one embodiment, the runtime analysis tool can execute in conjunction with the computer program under test. In that case, the runtime analysis tool can execute at the same time as, and cooperatively with, the computer program under test. Accordingly, the runtime analysis tool can intercept read and/or write operations, as the case may be, to track memory access activity as discussed herein.
  • In another embodiment, the runtime analysis tool can insert within, or instrument, the computer program under test with appropriate code for performing the various steps described herein. In that case, the runtime analysis tool does not actually execute in conjunction with the computer program under test. Rather, the computer program under test executes in a modified form which includes the inserted code from the runtime analysis tool. Still, it can be said that the runtime analysis tool “performs” the various steps described herein.
  • FIG. 1 is a flow chart illustrating a method 100 of identifying portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention. Method 100 illustrates an embodiment of the present invention that detects instances of wasteful write accesses where a value is written to a memory address that is the same as the value that was already, or previously, stored in that memory address. Accordingly, method 100 can begin in step 105 where the software analysis tool can begin monitoring for write accesses to memory locations that are performed by the computer program under test during runtime and detect such an access.
  • In step 110, the current value of the program counter can be stored. In step 115, the contents of the memory address that was accessed can be stored locally. Further, in step 115, a determination can be made by the analysis tool as to whether the new value being stored in the memory address that was accessed is the same as the value that was already stored in the memory address, i.e. prior to the detected write operation. If so, the method can proceed to step 120. If not, the method can proceed to step 180, where the computer program under test continues to execute until such time that another access to a memory address is detected and/or occurs.
  • Continuing with step 120, the redundancy record for the accessed, or current, memory address can be selected. If a redundancy record for the current memory address does exist, the method can proceed to step 130. If not, the method can continue to step 155. In step 130, a reference to the call graph node(s) associated with the program counter value stored in step 110 can be stored in the current redundancy record.
  • In step 135, a write access redundancy count for the current redundancy record, and thus the current memory address, can be incremented. The write access redundancy count can be a count of the number of write accesses that did not change the value at the target memory address. Because each redundancy record can maintain such a count, each memory address may have an associated count.
  • In step 140, a determination can be made as to whether the value of the program counter stored in step 110 is the same as the prior value of the program counter, for example the program counter value that was previously stored in the current redundancy record. That is, the current value of the program counter can be compared with the value of the program counter that was stored during the last time the method tracked through the branch including step 140. If so, the method can proceed to step 145 where a counter that tracks the number of write accesses that have a matching program counter value and that did not change the value at the target memory address is incremented. If not, the method can continue to step 150. In step 150, the value of the program counter stored in step 110 can be copied into the current redundancy record to be used in subsequent program counter comparisons. After step 150, the method can proceed to step 180, where the computer program under test continues to execute.
  • Continuing with step 155, in the case where no redundancy record exists for the current memory address, a redundancy record for the current memory address can be added and/or created. In step 160, the write access redundancy count for the current redundancy record can be set and/or initialized to “1”. In step 165, the value of the program counter stored in step 110 can be copied into the current redundancy record to be used in subsequent program counter comparisons. In step 170, the program counter redundancy count for the current redundancy record can be set and/or initialized to “1”. In step 175, a reference to the call graph node(s) associated with the program counter value stored in step 110 can be stored in the current redundancy record. In step 180, the computer program under test can continue to run.
  • FIG. 2 is a flow chart illustrating a method 200 of indicating portions of computer code responsible for performing redundant computation in accordance with one embodiment of the present invention. Method 200 can provide results determined from implementation of the method illustrated in FIG. 1. As such, it can be performed upon detection of a report condition. A report condition can be any of a variety of conditions which indicate that results from monitoring accesses to memory addresses are to be provided in one form or another. For example, such conditions can include, but are not limited to, termination of the computer program under test, a user request for report data, a count exceeding a threshold, whether that threshold is determined by the analysis tool or specified by the user, or the like.
  • In step 205, a report condition can be detected. In step 210, the address(es) having a redundancy record indicating the highest write access redundancy count can be selected. In step 215, a determination can be made as to whether more than one address was selected. If so, the method can proceed to step 220. If not, the method can continue to step 225. In step 220, of the memory addresses selected in step 210, a subset of such memory address(es) having a redundancy record specifying the highest program counter redundancy can be selected. Other memory addresses originally selected in step 210, but not included in the subset defined in step 220 can be deselected.
  • In step 225, the portions of code responsible for accessing the selected memory address(es) can be indicated. For example, in one embodiment, the call graph nodes corresponding to the responsible portions of code can be highlighted or otherwise indicated to the user. Such information can be obtained from the redundancy records corresponding to the selected memory address(es).
  • FIG. 3 is a flow chart illustrating a method 300 of identifying portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention. Method 300 can detect instances in which values have been written to memory addresses without intervening read accesses of those memory addresses. Accordingly, method 300 can begin in step 302 where the occurrence of a memory access, whether a read or a write, has been detected. If the access is a write, the method can proceed to step 304. If the access is a read, the method can continue to step 360.
  • In step 304, the value of the current program counter can be stored. In step 306, the redundancy record for the current memory address, i.e. the memory address that was accessed as detected in step 302, can be selected. If no redundancy record exists for the current memory address, the method can proceed to step 310. If a redundancy record does exist, the method can proceed to step 330.
  • Continuing with step 310, in the case where a redundancy record does not exist for the current memory address, a redundancy record can be created. A count of writes with no corresponding reads can be set and/or initialized to “0” in step 315. In step 320, a count of writes with no corresponding reads that have a matching program counter value can be set and/or initialized to “0”.
  • In step 330, in the case where a redundancy record does exist for the current memory address, the count of writes with no corresponding reads can be incremented. In step 335, a determination can be made as to whether the value of the program counter stored in step 304 is the same as the previous value of the program counter, i.e. the program counter stored in the current redundancy record. If so, the method can continue to step 340 where a counter of writes with no corresponding reads that have the same program counter value can be incremented.
  • Continuing from either step 320 or step 340, in step 345, a reference to the call graph node(s) associated with the program counter value stored in step 304 can be stored in the current redundancy record. In step 350, the value of the program counter stored in step 304 can be copied into the current redundancy record to be used in subsequent program counter comparisons. In step 355, the computer program under test can continue to run.
  • In step 360, where the detected memory access in step 302 was a read access, a determination can be made as to whether a redundancy record exists for the current memory address. If not, the method can continue to step 355 where the computer program under test continues to execute. If a redundancy record does exist, that redundancy record can be selected in step 365.
  • In step 370, a determination can be made as to whether the count of writes with no corresponding reads exceeds a threshold value, referred to as threshold_1 wr. The value of threshold_1 wr can be established as the “high water mark”, meaning a marker or indication of the highest count of write accesses with no corresponding read accesses of each redundancy record. If the count exceeds threshold_1 wr, the value of the count of writes with no reads can be stored as the new value of threshold_1 wr in step 375. If not, the method can proceed to step 380.
  • In step 380, a determination can be made as to whether the count of writes with no corresponding reads having a matching program counter value exceeds a threshold value referred to as threshold_2 wr. The value of threshold_2 wr can be established as a “high water mark” in that it is a marker or indication of the highest count of writes with no corresponding reads that have the same program counter value for a particular redundancy record. Thus, if the count of writes with no corresponding reads that have a matching program counter value exceeds the value of threshold_2 wr, that count can be stored as the new value of threshold_2 wr in step 385.
  • After step 380 or step 385, the counter for writes with no corresponding reads can be reset and/or initialized to “0” in step 390. In step 395, the count of writes with no reads that have the same program counter value also can be reset and/or initialized to “0”.
  • FIG. 4 is a flow chart illustrating a method 400 of indicating portions of computer code responsible for performing redundant computation in accordance with another embodiment of the present invention. Method 400 can provide results determined from implementation of the method illustrated in FIG. 3, for example in response to the detection of a report condition.
  • Thus, in step 405 a report condition can be detected. In step 410, the address(es) having a redundancy record indicating the highest count of writes without corresponding reads can be selected. In step 415, a determination can be made as to whether more than one address was selected in step 410. If so, the method can proceed to step 420. If not, the method can continue to step 425. In step 420, of the memory addresses selected in step 410, a subset of those address(es) having the highest program counter redundancy can be selected. Memory addresses originally selected in step 410 that are not included in the subset defined in step 420 can be deselected.
  • In step 425, the portions of code responsible for accessing the selected memory address(es) can be indicated. As noted, for example, the call graph nodes corresponding to the responsible portions of code can be highlighted or otherwise indicated to the user.
  • FIG. 5 is a flow chart illustrating a method 500 of identifying portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention. Method 500 can detect instances in which values have been read from a memory address multiple times without intervening write operations. This condition indicates that a read operation has been performed only to read an unchanged value from a memory address. Accordingly, method 500 can begin in step 502 where the occurrence of a memory access, whether a read or a write, has been detected. If the access is a read, the method can proceed to step 504. If the access is a write, the method can continue to step 555.
  • In step 504, the value of the current program counter can be stored. In step 506, a redundancy record for the current memory address, i.e. the memory address that was accessed as detected in step 502, can be selected. If no redundancy record exists for the current memory address, the method can proceed to step 508. If a redundancy record does exist, the method can proceed to step 525.
  • Continuing with step 508, in the case where a redundancy record does not exist for the current memory address, a redundancy record can be created. A count of reads with no corresponding writes can be set and/or initialized to “0” in step 510. In step 512, a count of reads with no corresponding writes having a matching program counter value can be set and/or initialized to “0”. In step 515, a threshold value, referred to as threshold_1 rw, of reads with no corresponding writes can be set and/or initialized to “0”. The value of threshold_1 rw can be established as the “high water mark” or the highest count of read accesses with no corresponding write accesses of each redundancy record. Similarly, a threshold of reads with no corresponding writes having a same program counter value, referred to as threshold_2 rw, can be set and/or initialized to “0”. Threshold_2 rw can serve as a “high water mark” for the highest count of read accesses with no corresponding write accesses having a same program counter value.
  • In step 525, in the case where a redundancy record does exist for the current memory address, the count of reads with no corresponding writes within the current redundancy record can be incremented. In step 530, a determination can be made as to whether the program counter value stored in step 504 is the same as the previous value of the program counter stored in the current redundancy record. If so, the method can continue to step 535 where a counter of reads with no corresponding writes that have the same program counter can be incremented.
  • Continuing with step 540 from either step 515 or step 535, a reference to the call graph node(s) associated with the program counter value stored in step 504 can be stored in the current redundancy record. In step 545, the value of the program counter stored in step 504 can be copied into the current redundancy record to be used in subsequent program counter comparisons. In step 550, the computer program under test can continue to run.
  • In step 555, where the detected memory access in step 502 was a write access, a determination can be made as to whether a redundancy record exists for the current memory address. If not, the method can proceed to step 550 to continue to run. If a redundancy record does exist, the redundancy record can be selected as the current redundancy record in step 560. In step 565, a determination can be made as to whether the count of reads with no corresponding writes exceeds the current value of threshold_1 rw. If so, the value of the count of reads with no writes can be stored as the new value of threshold_1 rw in step 570. If not, the method can proceed to step 575.
  • In step 575, a determination can be made as to whether the count of reads with no corresponding writes having a matching program counter value exceeds the current value of threshold_2 rw. If so, the count of reads with no corresponding writes can be stored as the new value of threshold_2 rw in step 580. After either of steps 575 or 580, the method can proceed to step 585 where the counter for reads with no corresponding writes can be set and/or initialized to “0”. In step 590, the counter for reads with no corresponding writes that have a matching program counter value can be reset and/or initialized to “0”. After step 590, the method can proceed to step 550.
  • FIG. 6 is a flow chart illustrating a method 600 of indicating portions of computer code responsible for performing redundant computation in accordance with yet another embodiment of the present invention. Method 600 can provide results determined from implementation of the method illustrated in FIG. 5, for example in response to the detection of a report condition.
  • Thus, in step 605, a report condition can be detected. In step 610, the address(es) having a redundancy record indicating the highest count of reads without corresponding writes can be selected. In step 615, a determination can be made as to whether more than one memory address was selected in step 610. If so, the method can proceed to step 620. If not, the method can continue to step 6250. In step 620, of the memory addresses selected in step 610, a subset of such memory address(es) that have a highest program counter redundancy can be selected. Memory addresses originally selected in step 610 that are not included in the subset defined in step 620 can be deselected.
  • In step 625, the portions of code responsible for accessing the selected memory address(es) can be indicated. As noted, for example, the call graph nodes corresponding to the responsible portions of code can be highlighted or otherwise indicated to the user.
  • The embodiments disclosed herein and discussed with reference to FIGS. 1-6 illustrate various techniques for identifying portions of code that are responsible for unnecessary processing and/or computation within computer programs. The details and steps described herein are provided for purposes of illustration and are not intended to limit the present invention in any way. For example, it should be appreciated that in another embodiment, portions of code responsible for a number of instances of redundant processing that exceeds a user specified threshold can be identified. In such an embodiment, a plurality of portions of code can be identified rather than a portion of code responsible for the largest number of instances of redundant processing. Other variations also are within the scope of the present invention such as varying the conditions upon which report information is provided to a user.
  • The present invention can be realized in hardware, software, or a combination of hardware and software. The present invention can be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software can be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. The present invention also can be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods.
  • The terms “computer program”, “software”, “application”, variants and/or combinations thereof, in the present context, mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form. For example, a computer program can include, but is not limited to, a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system.
  • The terms “a” and “an”, as used herein, are defined as one or more than one. The term “plurality”, as used herein, is defined as two or more than two. The term “another”, as used herein, is defined as at least a second or more. The terms “including” and/or “having”, as used herein, are defined as comprising (i.e., open language). The term “coupled”, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically, i.e. communicatively linked through a communication channel or pathway.
  • This invention can be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.

Claims (20)

1. A method of runtime analysis of a computer program comprising:
after each access of a first type to a memory address, incrementing a counter associated with the memory address;
after each access of a second type to a memory address, comparing the counter associated with the memory address with a threshold;
identifying at least one memory address having a counter that exceeds the threshold; and
determining a portion of code of the computer program responsible for accessing the memory address associated with the counter that exceeds the threshold.
2. The method of claim 1, further comprising if the counter exceeds the threshold, storing the counter as a new threshold for subsequent comparisons and resetting the counter.
3. The method of claim 1, wherein the access of a first type is a write access, the access of a second type is a read access, and the counter stores a count of write accesses with no corresponding read accesses.
4. The method of claim 1, wherein the access of a first type is a read access, the access of a second type is a write access, and the counter stores a count of read accesses with no corresponding write accesses.
5. The method of claim 1, further comprising, for each access of a first type, storing a current value of the program counter.
6. The method of claim 5, further comprising:
comparing the current value of the program counter with a prior value of the program counter; and
incrementing a count of a redundant program counter for the memory address accessed by the access of the first type if the current value of the program counter is equal to the prior value of the program counter.
7. The method of claim 6, further comprising identifying a portion of code responsible for accessing a memory address that is associated with a redundant program counter having a highest count of all redundant program counters.
8. A machine readable storage having stored thereon a computer program having a plurality of code sections for causing a machine to perform runtime analysis of a computer program, said machine readable storage comprising:
code for comparing a value previously stored in a memory address with a value that is written to the memory address for each write access to a memory address, and if the value previously stored is the same as the value that is written, incrementing a counter associated with the memory address; and
code for identifying a portion of code of a computer program under test that is responsible for accessing a memory address having an associated counter that conforms with an established criterion.
9. The machine readable storage of claim 8, wherein the established criterion is whether the counter for a memory address exceeds a threshold.
10. The machine readable storage of claim 9, further comprising code for storing the counter as a new threshold for subsequent comparisons if the counter exceeds the threshold.
11. The machine readable storage of claim 8, further comprising:
code for, if the value previously stored is equal to the value that is written, first determining whether a redundancy record exists for the memory address that is accessed; and
code for, if no redundancy record exists, creating a redundancy record for the memory address that is accessed.
12. The machine readable storage of claim 8, further comprising code for storing a value of the program counter for each instance in which the value previously stored is equal to the value that is written to the memory address.
13. The machine readable storage of claim 12, further comprising code for comparing a current value of the program counter with a prior value of the program counter, and incrementing a count of a redundant program counter if the current value of the program counter is equal to the prior value of the program counter.
14. The machine readable storage of claim 13, further comprising code for identifying a portion of code responsible for accessing a memory address that is associated with a redundant program counter that conforms to a different established criterion.
15. A machine readable storage having stored thereon a computer program having a plurality of code sections for causing a machine to perform runtime analysis of a computer program, said machine readable storage comprising:
code for, after each access of a first type to a memory address, incrementing a counter associated with the memory address;
code for, after each access of a second type to a memory address, comparing the counter associated with the memory address with a threshold;
code for identifying a memory address having a counter that exceeds the threshold; and
code for determining a portion of code of a computer program under test that is responsible for accessing the memory address associated with the counter that exceeds the threshold.
16. The machine readable storage of claim 15, further comprising code for, if the counter exceeds the threshold, storing the counter as a new threshold for subsequent comparisons and resetting the counter.
17. The machine readable storage of claim 15, wherein the access of a first type is a write access, the access of a second type is a read access, and the counter stores a count of write accesses with no corresponding read accesses.
18. The machine readable storage of claim 15, wherein the access of a first type is a read access, the access of a second type is a write access, and the counter stores a count of read accesses with no corresponding write accesses.
19. The machine readable storage of claim 15, further comprising:
code for, for each access of a first type, storing a current value of the program counter;
comparing the current value of the program counter with a prior value of the program counter; and
incrementing a count of a redundant program counter if the current value of the program counter is equal to the prior value of the program counter.
20. The machine readable storage of claim 19, further comprising code for identifying a portion of code responsible for accessing a memory address that is associated with a redundant program counter having a highest count of all redundant program counters.
US11/164,105 2005-11-10 2005-11-10 Identifying code that wastes time performing redundant computation Expired - Fee Related US7698690B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/164,105 US7698690B2 (en) 2005-11-10 2005-11-10 Identifying code that wastes time performing redundant computation
CNB2006101444787A CN100440163C (en) 2005-11-10 2006-11-08 Method and system for analysis processing of computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/164,105 US7698690B2 (en) 2005-11-10 2005-11-10 Identifying code that wastes time performing redundant computation

Publications (2)

Publication Number Publication Date
US20070169051A1 true US20070169051A1 (en) 2007-07-19
US7698690B2 US7698690B2 (en) 2010-04-13

Family

ID=38082847

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/164,105 Expired - Fee Related US7698690B2 (en) 2005-11-10 2005-11-10 Identifying code that wastes time performing redundant computation

Country Status (2)

Country Link
US (1) US7698690B2 (en)
CN (1) CN100440163C (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070150878A1 (en) * 2005-12-23 2007-06-28 Sas Institute Inc. System and method for detecting redundant subroutine calls
US20080178161A1 (en) * 2007-01-23 2008-07-24 Sas Institute Inc. System and method for determining execution path difference in program
US20090210750A1 (en) * 2008-02-19 2009-08-20 Sas Institute Inc. Systems And Methods For Identifying Memory Leaks In A Computer System
US20090254821A1 (en) * 2008-04-04 2009-10-08 Sas Institute Inc. Systems And Methods For Interactions With Software Probes
US7904754B2 (en) 2009-03-18 2011-03-08 Sas Institute Inc. Systems and methods for automated determination of out of memory handling
US20110119661A1 (en) * 2009-05-01 2011-05-19 Telcordia Technologies, Inc. Automated Determination of Quasi-Identifiers Using Program Analysis
US8276020B2 (en) 2009-03-18 2012-09-25 Sas Institute Inc. Systems and methods for automated determination of error handling
US20140019944A1 (en) * 2008-10-29 2014-01-16 International Business Machines Corporation Automated Identification of Redundant Method Calls
US20140067445A1 (en) * 2012-09-03 2014-03-06 Fujitsu Limited Storage medium storing analysis program, analysis method and analysis apparatus
US20190102310A1 (en) * 2017-10-02 2019-04-04 Arm Ltd Method and apparatus for control of a tiered memory system
US10691580B1 (en) * 2017-11-29 2020-06-23 Xilinx, Inc. Diagnosing applications that use hardware acceleration through emulation

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9697107B2 (en) 2012-04-26 2017-07-04 Hewlett Packard Enterprise Development Lp Testing applications
JP6544054B2 (en) * 2015-06-02 2019-07-17 富士通株式会社 INFORMATION PROCESSING APPARATUS, EXECUTION INFORMATION RECORDING PROGRAM, AND EXECUTION INFORMATION RECORDING METHOD

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339431A (en) * 1989-10-16 1994-08-16 Hewlett-Packard Company Software compiler and linker with improved line-number table
US5347654A (en) * 1992-02-03 1994-09-13 Thinking Machines Corporation System and method for optimizing and generating computer-based code in a parallel processing environment
US6243864B1 (en) * 1997-07-17 2001-06-05 Matsushita Electric Industrial Co., Ltd. Compiler for optimizing memory instruction sequences by marking instructions not having multiple memory address paths
US20010054165A1 (en) * 2000-06-16 2001-12-20 Fujitsu Limited Memory device having redundant cells
US6397379B1 (en) * 1999-01-28 2002-05-28 Ati International Srl Recording in a program execution profile references to a memory-mapped active device
US20030023961A1 (en) * 2001-07-30 2003-01-30 International Business Machines Corporation Method and apparatus for displaying compiler-optimizated code
US6681387B1 (en) * 1999-12-01 2004-01-20 Board Of Trustees Of The University Of Illinois Method and apparatus for instruction execution hot spot detection and monitoring in a data processing unit
US6745384B1 (en) * 1998-05-29 2004-06-01 Microsoft Corporation Anticipatory optimization with composite folding
US20070118832A1 (en) * 2005-11-18 2007-05-24 Huelsbergen Lorenz F Method and apparatus for evolution of custom machine representations
US7373637B2 (en) * 2003-09-30 2008-05-13 International Business Machines Corporation Method and apparatus for counting instruction and memory location ranges

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5937437A (en) * 1996-10-28 1999-08-10 International Business Machines Corporation Method and apparatus for monitoring address translation performance
US20040003375A1 (en) * 2002-06-28 2004-01-01 George Jini S. Method and system for combining dynamic instrumentation and instruction pointer sampling
US7062684B2 (en) * 2002-12-19 2006-06-13 International Business Machines Corporation Enabling tracing of a repeat instruction
US7526757B2 (en) * 2004-01-14 2009-04-28 International Business Machines Corporation Method and apparatus for maintaining performance monitoring structures in a page table for use in monitoring performance of a computer program

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339431A (en) * 1989-10-16 1994-08-16 Hewlett-Packard Company Software compiler and linker with improved line-number table
US5347654A (en) * 1992-02-03 1994-09-13 Thinking Machines Corporation System and method for optimizing and generating computer-based code in a parallel processing environment
US6243864B1 (en) * 1997-07-17 2001-06-05 Matsushita Electric Industrial Co., Ltd. Compiler for optimizing memory instruction sequences by marking instructions not having multiple memory address paths
US6745384B1 (en) * 1998-05-29 2004-06-01 Microsoft Corporation Anticipatory optimization with composite folding
US6397379B1 (en) * 1999-01-28 2002-05-28 Ati International Srl Recording in a program execution profile references to a memory-mapped active device
US7111290B1 (en) * 1999-01-28 2006-09-19 Ati International Srl Profiling program execution to identify frequently-executed portions and to assist binary translation
US6681387B1 (en) * 1999-12-01 2004-01-20 Board Of Trustees Of The University Of Illinois Method and apparatus for instruction execution hot spot detection and monitoring in a data processing unit
US20010054165A1 (en) * 2000-06-16 2001-12-20 Fujitsu Limited Memory device having redundant cells
US20030023961A1 (en) * 2001-07-30 2003-01-30 International Business Machines Corporation Method and apparatus for displaying compiler-optimizated code
US7373637B2 (en) * 2003-09-30 2008-05-13 International Business Machines Corporation Method and apparatus for counting instruction and memory location ranges
US20070118832A1 (en) * 2005-11-18 2007-05-24 Huelsbergen Lorenz F Method and apparatus for evolution of custom machine representations

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7721269B2 (en) * 2005-12-23 2010-05-18 Sas Institute Inc. System and method for detecting redundant subroutine calls
US20070150878A1 (en) * 2005-12-23 2007-06-28 Sas Institute Inc. System and method for detecting redundant subroutine calls
US20080178161A1 (en) * 2007-01-23 2008-07-24 Sas Institute Inc. System and method for determining execution path difference in program
US7810079B2 (en) 2007-01-23 2010-10-05 Sas Institute Inc. System and method for determining execution path difference in program
US20090210750A1 (en) * 2008-02-19 2009-08-20 Sas Institute Inc. Systems And Methods For Identifying Memory Leaks In A Computer System
US20090254821A1 (en) * 2008-04-04 2009-10-08 Sas Institute Inc. Systems And Methods For Interactions With Software Probes
US8566796B2 (en) 2008-04-04 2013-10-22 Sas Institute Inc. Systems and methods for interactions with software probes
US8904360B2 (en) * 2008-10-29 2014-12-02 International Business Machines Corporation Automated identification of redundant method calls
US9996447B2 (en) * 2008-10-29 2018-06-12 International Business Machines Corporation Automated identification of redundant method calls
US20150089482A1 (en) * 2008-10-29 2015-03-26 International Business Machines Corporation Automated Identification of Redundant Method Calls
US20140019944A1 (en) * 2008-10-29 2014-01-16 International Business Machines Corporation Automated Identification of Redundant Method Calls
US8276020B2 (en) 2009-03-18 2012-09-25 Sas Institute Inc. Systems and methods for automated determination of error handling
US7904754B2 (en) 2009-03-18 2011-03-08 Sas Institute Inc. Systems and methods for automated determination of out of memory handling
US8661423B2 (en) * 2009-05-01 2014-02-25 Telcordia Technologies, Inc. Automated determination of quasi-identifiers using program analysis
US20110119661A1 (en) * 2009-05-01 2011-05-19 Telcordia Technologies, Inc. Automated Determination of Quasi-Identifiers Using Program Analysis
US20140067445A1 (en) * 2012-09-03 2014-03-06 Fujitsu Limited Storage medium storing analysis program, analysis method and analysis apparatus
US20190102310A1 (en) * 2017-10-02 2019-04-04 Arm Ltd Method and apparatus for control of a tiered memory system
US10866899B2 (en) * 2017-10-02 2020-12-15 Arm Ltd Method and apparatus for control of a tiered memory system
US10691580B1 (en) * 2017-11-29 2020-06-23 Xilinx, Inc. Diagnosing applications that use hardware acceleration through emulation

Also Published As

Publication number Publication date
US7698690B2 (en) 2010-04-13
CN1963783A (en) 2007-05-16
CN100440163C (en) 2008-12-03

Similar Documents

Publication Publication Date Title
US7698690B2 (en) Identifying code that wastes time performing redundant computation
US9274923B2 (en) System and method for stack crawl testing and caching
US7774761B2 (en) Use of memory watch points and a debugger to improve analysis of runtime memory access errors
US8195720B2 (en) Detecting memory leaks
US8938729B2 (en) Two pass automated application instrumentation
JP5523872B2 (en) Program dynamic analysis method and apparatus
US20050091646A1 (en) Statistical memory leak detection
US8095921B2 (en) Identifying code that wastes time switching tasks
US8418149B2 (en) Differential comparison system and method
US9183114B2 (en) Error detection on the stack
US10459704B2 (en) Code relatives detection
KR19990077479A (en) A method and apparatus for structured memory analysis of data processing systems and applications
KR19990077480A (en) A method and apparatus for structured memory analysis of data processing systems and applications
US20080276129A1 (en) Software tracing
CN110741354A (en) Presenting differences between code entity invocations
KR101979329B1 (en) Method and apparatus for tracking security vulnerable input data of executable binaries thereof
US20160188441A1 (en) Testing multi-threaded applications
CN111625833A (en) Efficient method and device for judging reuse vulnerability after software program release
CN109542341B (en) Read-write IO monitoring method, device, terminal and computer readable storage medium
US8756580B2 (en) Instance-based field affinity optimization
US20220335135A1 (en) Vulnerability analysis and reporting for embedded systems
CN112527677B (en) Application program protection method and electronic equipment
US11816092B2 (en) System and method for automatic application log messages grouping using logging framework code instrumentation
CN116136800A (en) Operating system deadlock static detection method and related equipment
Wilén Throughput Analysis of Safepoint-attached Barriers in a Low-latency Garbage Collector: Analysis of a Compiler Optimization in the HotSpot JVM

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KRAUSS, KIRK J.;REEL/FRAME:016763/0579

Effective date: 20051108

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION,NEW YO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KRAUSS, KIRK J.;REEL/FRAME:016763/0579

Effective date: 20051108

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20140413