US20050251791A1 - Systems and methods for branch profiling loops of an executable program - Google Patents
Systems and methods for branch profiling loops of an executable program Download PDFInfo
- Publication number
- US20050251791A1 US20050251791A1 US11/089,585 US8958504A US2005251791A1 US 20050251791 A1 US20050251791 A1 US 20050251791A1 US 8958504 A US8958504 A US 8958504A US 2005251791 A1 US2005251791 A1 US 2005251791A1
- Authority
- US
- United States
- Prior art keywords
- loop
- path
- path counter
- instructions
- counter array
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3644—Software debugging by instrumenting at runtime
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/865—Monitoring of software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/88—Monitoring involving counting
Definitions
- the dynamic instrumentation tool decodes the executable function and generates an intermediate representation of the given function, and generates a control flow graph from the intermediate representation.
- the dynamic instrumentation tool then performs loop recognition analysis on the control flow graph to identify loops in the given function at 150 . After the loops have been identified, the methodology proceeds to 160 .
Abstract
Systems and methods for branch profiling an executable program are disclosed. One embodiment relates to a method of branch profiling an executable program. The method may comprise inserting an integer add instruction in branches of a loop of the executable program, inserting path counter instructions after a last branch of the loop and prior to an exit point of the loop, and inserting loop counter array update instructions after the exit point of the loop.
Description
- This application is related to the following commonly assigned co-pending patent application entitled: “SYSTEMS AND METHODS FOR INSTRUMENTING LOOPS OF AN EXECUTABLE PROGRAM,” Attorney Docket No. 200313028-1, which is filed contemporaneously herewith and is incorporated herein by reference.
- Code instrumentation is a method for analyzing and evaluating program code performance. Source instrumentation modifies a program's original source code, while binary instrumentation modifies an existing binary executable. In one approach to binary code instrumentation, new instructions or probe code are added to an executable program, and consequently, the original code in the program is changed and/or relocated. Some examples of probe code include adding values to a register, moving the address of some data to some registers, and adding counters to determine how many times a function is called. The changed and/or relocated code is referred to as instrumented code, or more generally, as an instrumented process.
- One specific type of code instrumentation is referred to as dynamic binary instrumentation. Dynamic binary instrumentation allows program instructions to be changed on-the-fly. Measurements such as basic-block coverage and function invocation counting can be accurately determined using dynamic binary instrumentation. Additionally, dynamic binary instrumentation, in contrast to static instrumentation, is performed at run-time of a program and only instruments those parts of an executable that are actually executed. This minimizes the overhead imposed by the instrumentation process itself. Furthermore, performance analysis tools based on dynamic binary instrumentation require no special preparation of an executable such as, for example, a modified build or link process.
- One embodiment of the present invention may comprise a system for branch profiling an executable program. The system may comprise a branch profiler that assigns branch integers to branches in a loop and a plurality of path values that correspond to sums of the branch integers through respective execution paths in the loop. The system may also comprise a probe instrument that inserts an integer add instruction into branches of the loop, a set of path counter instructions after a last branch in the loop, and a set of loop path counter array update instructions after an exit point of the loop.
- Another embodiment may comprise a method of branch profiling of an executable program. The method may comprise inserting an integer add instruction in branches of a loop of the executable program, inserting path counter instructions after a last branch of the loop and prior to an exit point of the loop, and inserting loop counter array update instructions after the exit point of the loop.
- Another embodiment relates to a computer readable medium having computer executable instruction for performing a method. The method may comprise performing a branch profiling on at least one loop in an executable program to assign branch integers to branches and path values to execution paths in the at least one loop, inserting integer add instructions to branches of the at least one loop, inserting path counter instructions at an end of the at least one loop, and inserting loop path counter array update instructions after an exit point of the at least one loop.
- Still another embodiment may relate to a dynamic instrumentation system. The dynamic instrumentation system may comprise means for generating an intermediate representation of a function associated with an executable program, means for analyzing the intermediate representation to identify at least one loop in the function, and means for performing branch profiling on the identified at least one loop to assign branch integers to branches and path values to execution paths of the identified at least one loop. The system may further comprise means for inserting code into the identified at least one loop. The means for inserting code may insert integer add instructions into branches of the identified at least one loop, and path counter instructions at an end of the identified at least one loop. The system may also comprise means for encoding the inserted code and the intermediate representation of the function to produce an instrumented function.
-
FIG. 1 illustrates an embodiment of a dynamic instrumentation system. -
FIG. 2 illustrates an embodiment of components associated with a dynamic instrumentation tool. -
FIG. 3 illustrates an embodiment of a block diagram of contents of a portion of shared memory. -
FIG. 4 illustrates an embodiment of a loop associated with an executable program having instrumentation counters inserted therein. -
FIG. 5 illustrates an embodiment of a loop counter array update routine associated with a loop of an executable program. -
FIG. 6 illustrates another embodiment of a loop counter array update routine associated with a loop of an executable program. -
FIG. 7 illustrates a methodology for inserting instrumentation code into an executable program. -
FIG. 8 illustrates an embodiment of an alternate methodology for inserting instrumentation code in an executable program. -
FIG. 9 illustrates an embodiment of yet another alternate methodology for inserting instrumentation code in an executable program. -
FIG. 10 illustrates an embodiment of a computer system. - This disclosure relates generally to dynamic instrumentation systems and methods. Branch profiling is performed on at least one loop of an executable program. The branch profiling determines the possible paths through branches of the at least one loop. The branch profiling then assigns branch integers to branches contained within the at least one loop, and a plurality of path values for respective possible execution paths through the branches. The path values correspond to the sum of the branch integers over a respective path. Integer add instructions are inserted in respective branches. The integer add instructions sum up the branch integers of a given execution path for a given loop execution. Path counter instructions are inserted at an end of the at least one loop. Upon completion of a loop iteration, program execution is directed to the path counter instructions. The path counter instructions compare the value of an integer adder with the plurality of path values to determine which path of the plurality of execution paths has been taken during the given single loop execution. A corresponding path counter associated with the execution path that has been taken is incremented for a respective loop iteration.
- A loop path counter array update instruction is inserted after an exit point of the loop. The loop path counter array update instruction updates loop path counter entries in a loop path counter array with the number of executions for respective paths taken through the loop. One or more loops can be assigned loop path counter arrays. The loop path counter array update instructions can be embedded in a multi-thread safe set of ownership instructions, such as a spinlock operation. A spinlock operation provides a thread with ownership of the loop path counter array entries stored in memory, preventing other threads from modifying the loop path counter entries associated with the loop path counter array, until the ownership is released.
-
FIG. 1 illustrates adynamic instrumentation system 10. Thedynamic instrumentation system 10 can be a computer, a server or some other computer medium that can execute computer readable instructions. For example, the components of thesystem 10 can be computer executable components running on a computer, such as can be stored in a desired storage medium (e.g., random access memory, a hard disk drive, CD ROM, and the like). Thedynamic instrumentation system 10 includes adynamic instrumentation tool 12. Thedynamic instrumentation tool 12 interfaces with anexecutable program 14 to assign instrumentation (e.g., counters) to theexecutable program 14. - The
dynamic instrumentation tool 12 is operative to perform branch profiling on theexecutable program 14. The branch profiling includes analyzing at least one loop to assign integer values to branches within the at least one loop, and path values that correspond to unique execution paths through the at least one loop. The sum of the branch integers through an execution path is equal to a respective path value, such that an execution path through the at least one loop can be determined by decoding the path value. The branch profiling can be an algorithm (e.g., Ball-Larus algorithm) for assigning integers to branches and path values to unique execution paths. - The
dynamic instrumentation tool 12 is operative to assign instrumentation counters to at least one loop associated with theexecutable program 14. The instrumentation counters can include an integer adder that adds branch integers associated with branch executions to provide a unique path value for a given loop execution. The instrumentation counters can include path counters that maintain a count associated with a number of times a given execution path has been taken over the total loop iterations of a respective loop. Thedynamic instrumentation tool 12 is operative to assign a free register to the at least one loop for integer adding, and a plurality of free registers for path counting. - A free register can be found by analyzing the
executable program 14 to determine which registers are used for storing data by the executable program and which registers are not used. Additionally, the code can be analyzed to determine which registers are currently available for use that would not interfere with the executable program execution. It is to be appreciated that a variety of techniques can be employed to find a free register. - The
dynamic instrumentation tool 12 can load theexecutable program 14 and insert breaks at a beginning of each function under the control of a debugging interface, which is provided by the operating system (e.g., ttrace( ) on HP-UX® Operating System, ptrace( )on LINUX® Operating System, Extended Debugging Interface (eXDI) on MICROSOFT WINDOWS® Operating System). Theexecutable program 14 then is executed. The debugging interface makes it possible to transfer control from the target application to thedynamic instrumentation tool 12 whenever a break is encountered in the executable program. - As the
executable program 14 encounters the breaks corresponding to a new reached function, control is passed to thedynamic instrumentation tool 12. Thedynamic instrumentation tool 12 loads the function. Thedynamic instrumentation tool 12 then converts the function into an intermediate representation by decoding the binary code associated with the function and converting the decoded binary code via an intermediate representation instrument. A control flow graph constructor then generates a control flow graph from the intermediate representation. A loop analysis is then performed on the intermediate representation by a loop recognition algorithm. - Branch profiling can be performed on the control flow graph to identify branches and possible execution paths through the one or more loops. A branch profiling algorithm (e.g., Ball-Larus algorithm) can be employed to assign branch integers to branches and path values to execution paths through one or more loops, such that the branch integers can be summed to determine an execution path that has been taken through a given loop during a single loop execution. The branch integer sum is a unique value that corresponds to a specific execution path through a set of branches.
- The
dynamic instrumentation tool 12 can then insert one or more instrumentation counters via a probe code instrumenter. The one or more instrumentation counters include an integer adder that adds a branch integer corresponding to an executed branch to the integer adder. The integer adder can be a free register. The probe instrument can insert instructions in branches to increment the free register by the value of the branch integer when the branch is executed. At the end of the loop, the free register will provide a path value associated with execution through a set of branches corresponding to the execution path through the loop. - A path counter can be employed for each unique path through a loop iteration. A respective path counter can be incremented each time its corresponding execution path is taken by comparing the sum of the integer adder with a set of assigned path values that identify which execution path has been taken. A path counter can include a free register that is incremented if its associated path has been taken. The probe instrument can insert instructions that increment a respective path counter if the integer adder value is equal to the path value associated with the respective path counter. In this manner, a respective path counter is incremented through each loop iteration based on the execution path through the loop. Once execution of the loop has completed (e.g., after a plurality of loop iterations), the path counters will contain values indicative of the number of times a particular path through the loop has been taken for each possible execution path.
- As previously stated, a number of different techniques can be employed to generate free registers. Free registers are inherently multi-thread safe. Typically, loop counters are employed to count loop iterations by utilizing atomic memory update instructions. The atomic memory update instructions are multi-thread safe, but are substantially time intensive (e.g., about 20 clock cycles) as compared to a register add instruction (e.g., about 1 clock cycle).
- A loop path counter array update instruction is inserted after an exit point of the loop. The loop path counter array update instructions updates loop path counter entries in a loop path counter array with the number of executions for the paths taken through a respective loop associated with the executable program. The loop path counter array update instructions can be embedded in a multi-thread safe set of ownership instructions, such as a spinlock operation. A spinlock operation provides a thread with ownership of the loop path counter array stored in memory preventing other threads from modifying the loop path counter array, until the ownership is released. The loop path counter array maintains a count associated with total path executions of each possible execution path over one or more loop executions associated with a given loop. A respective loop path counter array can be assigned to respective loops for one or more loops in the
executable program 14. - The
dynamic instrumentation tool 12 then encodes the modified function code to provide an instrumented function in binary form. The instrumented function is stored in a sharedmemory 18. The original entry point of the function (where the break point was placed) is patched with a branch/jump to the instrumented version of the function. Execution is then resumed at the address of the instrumented function (e.g., resume can be an option in the debug interface). Therefore, control has been transferred back to the executable program, which continues to execute until another breakpoint at a new non-encountered function is encountered. The process then repeats for the next function until all function have been instrumented. Once theexecutable program 14 and instrumented functions have completed execution, thedynamic instrumentation tool 12 can retrieve the loop path counter entries from one or more loop path counter arrays from the sharedmemory 18. -
FIG. 2 illustrated components associated with adynamic instrumentation tool 40. Thedynamic instrumentation tool 40 includes a decoder and an intermediate representation (IR)instrument 42 that reads in the binary function, and decodes the binary function into an intermediate representation. A controlflow graph constructor 44 can configure the intermediate representation as a control flow graph with basic blocks and edges between those blocks representing possible flows of control. A loop analysis can be performed on the loop by aloop recognition algorithm 46. Theloop recognition algorithm 46 can be one of many different algorithms known for recognizing loops in a control flow graph. - The
dynamic instrumentation tool 40 includes abranch profiler 48. Thebranch profiler 48 analyzes the branches in one or more loops to identify potential execution paths through the one or more loops. Each branch is assigned a branch integer and each execution path is assigned a path value, such that the sum of branch integers through each possible execution path of a set of branches provides a unique path value. In this manner, the particular execution path taken through the branches can be determined in which paths can be reconstructed by comparing the integer sum values with the different path values. - The
dynamic instrumentation tool 40 also includes aprobe code instrumenter 50. Theprobe code instrumenter 50 can insert integer add instructions in the branches. The integer add instructions can add the corresponding branch integer to an integer adder for an executed branch. Theprobe code instrumenter 50 can insert path counter instructions that can increment respective path counters that maintain a path count for a respective execution path. The path counter instructions can be inserted at the end of a loop prior to an exit point of the loop. Theprobe code instrumenter 50 can insert loop path counter array update instructions after the exit point of a loop. The loop path counter array update instruction updates loop path counter entries of the loop path counter array to maintain path execution counts over one or more executions of a given loop. A plurality of loops can be assigned respective loop path counter arrays. - Free registers can be employed to implement the integer adder and the path counters. The
probe code instrumenter 50 can insert register initialization instruction at the loop entry point. Theprobe code instrumenter 50 can generate free registers associated with the integer add instructions and the path counter instructions for one or more loops, as long as free registers are available. If free register are no longer available, theprobe code instrumenter 50 can insert path counter instructions that store the path count values to memory. Thedynamic instrumentation tool 40 includes anencoder 50 that encodes the IR instrumented function into a binary instrumented function. Thedynamic instrumentation tool 40 includes aprocess control 52 that stores the binary instrumented function in shared memory, patches a branch/jump instruction in the executable program where the break point was placed, and passes control back to the executable program. -
FIG. 3 illustrates a block diagram of contents of a portion of sharedmemory 60 associated with branch profiling an executable program. The sharedmemory 60 retains a loop path counter array (C1) having a plurality of loop path counter entries (C1(0)-C1(N-1)). The loop path counter array maintains an updated counter for each execution path via a respective loop path counter entry for a given loop. The loop path counter array is labeled 0 to N-1, where N is an integer equal to the number of execution paths in the loop. In one embodiment, path values can be assigned to execution paths from 0 to N-1, such that the path value can be employed to readily update a corresponding loop path counter entry (e.g., C1(PV0), C1(PV1), . . . , C1(PVN-1)). The loop path counter entries correspond to the number of executed path iterations of each executed path in a given loop. The loop path counter array is updated each time the given loop completes execution in the executable program and a loop exit point is encountered. A respective loop path counter entry of the loop path counter array is updated by adding the current value of the loop path counter entry with the value of the path counter associated with the respective execution path. Since the loop path counter array resides in sharedmemory 60, the loop path counter entries are not multi-thread safe. - Therefore, the shared
memory 60 includes a loop path counter array access flag, labeled C1AF, associated with the loop path counter array. The access flag is employed to maintain ownership of the loop path counter array memory spaces by a single process at a time, so that loop path counter array integrity is maintained. For example, if a process desires to overwrite the loop path counter array, the process will request control of the loop path counter array by checking the corresponding counter access flag. If the counter access flag is not set, the process will set the flag and update the corresponding loop path counter array. The process will then reset the flag and release control of the loop path counter array, so that other processes may access the loop path counter array in sharedmemory 60. In this manner, loop path counter array integrity is maintained by being multi-thread safe. It is to be appreciated that a respective loop path counter array can be assigned to a respective loop for one or more loops in an executable program to maintain path counts for the one or more loops. - The shared
memory 60 also retains a plurality of instrumented functions, labeled 1 through K, where K is an integer greater than or equal to one. The dynamic instrumentation tool stores the encoded instrumented functions in sharedmemory 60 to provide ready access to both the instrumentation tool and the executable program. The address associated with a given instrumented function is placed before the associated function in the executable program, such that the instrumented function is executed in place of the given function via a jump or call instruction. Once the executable program is completely instrumented, a substantial portion of executable program execution occurs in sharedmemory 60 via the instrumented functions. -
FIG. 4 illustrates aloop 70 associated with an executable program having instrumentation counters inserted therein. Theloop 70 can reside in a function in the executable program. Theloop 70 can be an innermost loop, an outermost loop or an intermediary loop. The innermost loops of the executable program are loops that contain no inner loops, while the outermost loops are not nested in any outer loop. Intermediate loops are loops that are both inner loops and outer loops, such that the intermediate loop is a loop that is nested in one or more outer loops and also contain one or more inner loops nested therein. The instrumentation execution speed can be improved by generating free registers for innermost loops first, intermediate loops second, and outermost loops last, as long as free registers are available. - The
loop 70 includes instrumentation code provided by a dynamic instrumentation tool. The dynamic instrumentation tool assigns a set of free registers to theloop 70. A first register Rx is employed as an integer adder, while the remaining registers R1-RN are employed as path counters. The dynamic instrumentation tool inserts a set of register initialization instructions 72 (R1=0; R2=0; . . . ;RN=0) at lines 001-003 prior to a loop start or entry point (004) to reset the path counters. The dynamic instrumentation tool inserts an integer adder register initialization instruction (Rx=0) at lines 005 after a loop start or entry point (004) to reset the integer adder for each loop iteration. - The dynamic instrumentation tool inserts a register integer add instruction in one or more control flow branches of the
loop 70. For example, a first register integer add instruction (Rx=Rx+INT0) is inserted at line 007 within afirst branch 74 indicated as extending fromlines 006 to 008, and a second register integer add instruction (Rx=Rx+INT1) is inserted atline 009 within asecond branch 75 indicated as extending fromlines 008 to 010. If cond1 is true atline 006, thefirst branch 74 will be executed and the integer adder (Rx) will be incremented by INT0. If cond1 is false atline 006, thesecond branch 75 will be executed and the integer adder (Rx) will be incremented by INT1. - The process is repeated for B number of branches. For example, a B-2 integer add instruction (Rx=Rx+INTB-2) is inserted at
line 012 within a B-2branch 76 indicated as extending fromlines 011 to 013, and a B-1 integer add instruction (Rx=Rx+INTB-1) is inserted atline 014 within a B-1branch 77 indicated as extending fromlines 013 to 015. If condk is true atline 011, the B-2branch 76 will be executed and the integer adder (Rx) will be incremented by INTB-2. If condk is false atline 011, the B-1branch 77 will be executed and the integer adder (Rx) will be incremented by INTB-1. - A set of path counter
instructions 78 are inserted after thelast branch 77 of theloop 70 and prior to anexit point 80 of theloop 70. Theexit point 80 of theloop 70 includes a set of instructions illustrated in lines 019-021 in which a loop condition is determined from which the loop continues execution for another iteration if the loop condition is true and terminates loop execution if the loop condition is false. The set of path counterinstructions 78 are illustrated in lines 016 tolines 018 in which the integer adder value is compared with a plurality of path values associated with a unique execution path that can be taken. For example, if the value of the integer adder (Rx) is equal to the path value PV0, the value of a first path counter (R1) is incremented by one indicated that the execution path associated with the path value PV0 has been executed. If the value of the integer adder (Rx) is equal to the path value PV1, the value of a second path counter (R2) is incremented by one indicated that the execution path associated with the path value PV1 has been executed. Finally, if the value of the integer adder (Rx) is equal to the path value PVN-1, the value of a final path register RN is incremented by one indicated that the execution path associated with the path value PVN-1 has been executed, such that there are N possible unique execution paths. - The dynamic instrumentation tool also inserts a set of loop path counter
array update instructions 82 after theexit point 80 of theloop 70 beginning atline 022. Execution of the loop path counterarray update instructions 82 causes the loop path counter array entries in shared memory to be updated by adding the values of the path registers to the respective loop path counter entries of the loop path counter array in shared memory. -
FIG. 5 illustrates a set of loop path counterarray update instructions 84 as illustrated in lines 022-026. The set of loop path counterarray update instructions 84 update a loop path counter array that includes loop path counter entries. The loop path counter entries retain loop path count values corresponding to the number of executed path iterations of a respective executed path in a given loop for one or more loop executions. The loop path counter array is updated each time the given loop terminates execution in the executable program and a loop exit point is encountered. A respective loop path counter entry of the loop path counter array is updated by adding the current value of the loop path counter entry with the value of the path counter associated with the respective execution path. For example, line 023 indicates that the loop path counter entry PV0 is updated by the loop path counter R1 (C1[PV0]=C1[PV0]+R1), line 024 indicates that the loop path counter entry PV1 is updated by the loop path counter R2 (C1[PV1]=C1[PV1]+R2), andline 025 indicates that the loop path counter entry PVN-1 is updated by the loop path counter RN (C1[PVN-1]=C1[PVN-1]+RN), such that each of the N loop path counter entries in the loop path counter array are updated. - Since the loop path counter array resides in shared memory, the loop path counter entries are not multi-thread safe. Therefore, the loop path counter array update instructions are embedded in memory ownership instructions, such that ownership of the loop path counter array memory locations are requested prior to updating of the loop path counter entries. For example, a spinlock access command is a set of instructions that requests access of a loop path counter array by checking the state of a loop access flag via a set of spinlock access instructions illustrated at
line 022. The loop path counter entries are then updated by execution of the loop path counter updateinstructions 84. The loop access flag is then reset via set of spinlock release instructions illustrated atline 026, thus releasing ownership control of the memory locations associated with the loop path counter array. Although a single instruction is shown for illustrating a spinlock access instruction set, a loop path counter array update instruction and a spinlock release instruction set, a plurality of instructions can be employed to execute any of a spinlock access, a loop counter update and a spinlock release. -
FIG. 6 illustrates another set of loop path counterarray update instructions 86 illustrated in lines 027-034. The set of loop path counterarray update instructions 86 includes instructions to determine if a respective register path counter has a non-zero value. The respective loop path counter entry is only updated if its associated register path counter has a non-zero value. In this manner, unnecessary writes to memory are avoided. For example, lines 028-029 indicate that the loop path counter entry PV0 is updated by the loop path counter R1(C1[PV0]=C1[PV0]+R1) if R1 is greater than zero, lines 030-031 indicate that the loop path counter entry PV1 is updated by the loop path counter R2 (C1[PV1]=C1[PV1]+R2) if R2 is greater than zero, and lines 032-033 indicate that the loop path counter entry PVN-1 is updated by the loop path counter RN (C1[PVN-1]=C1[PVN-1]+RN) if RN is greater than zero, such that only loop path counter entries in which execution paths have been taken are updated in the loop path counter array. The set of loop path counter array update instructions are embedded in memory ownership instructions including a spinlock instruction set illustrated atline 027, and a spinlock release instruction set illustrated inline 034. - In view of the foregoing structural and functional features described above, certain methods will be better appreciated with reference to
FIGS. 7-9 . It is to be understood and appreciated that the illustrated actions, in other embodiments, may occur in different orders and/or concurrently with other actions. Moreover, not all illustrated features may be required to implement a method. It is to be further understood that the following methodologies can be implemented in hardware (e.g., a computer or a computer network as one or more integrated circuits or circuit boards containing one or more microprocessors), software (e.g., as executable instructions running on one or more processors of a computer system), or any combination thereof. -
FIG. 7 illustrates a methodology for branch profiling a loop of an executable program. The methodology begins at 100 where an executable program is analyzed and breaks are inserted before each function. The executable program then begins execution, until a breakpoint is encountered for a given function. Once a breakpoint is encountered, the methodology proceeds to 120. At 120, a determination is made as to whether the executable program has completed execution. If the executable program has completed execution (YES), the methodology proceeds to 140 to retrieve the instrumentation values. If the executable program has not completed execution (NO), the methodology proceeds to 130. - At 130, the dynamic instrumentation tool decodes the executable function and generates an intermediate representation of the given function, and generates a control flow graph from the intermediate representation. The dynamic instrumentation tool then performs loop recognition analysis on the control flow graph to identify loops in the given function at 150. After the loops have been identified, the methodology proceeds to 160.
- At 160, branch profiling is performed on one or more loops. Branch profiling can be performed on the control flow graph to identify branches and possible execution paths through the one or more loops. A branch profiling algorithm (e.g., Ball-Larus algorithm) can be employed to assign branch integers to branches and path values to execution paths through one or more loops, such that the branch integers can be summed to determine an execution path that has been taken through a given loop during a single loop execution. The methodology then proceeds to 170.
- At 170, one or more instrumentation counter instructions are inserted into one or more loops associated with the given function. The one or more instrumentation counter instructions include register initialization instructions, integer adder instructions, path counter instructions and loop path counter array update instructions for one or more respective loops. The instrumentation execution speed can be improved by generating free registers for implementing an integer adder and path counters for a given loop.
- Register initialization instructions for initializing the path counters can be inserted prior to an entry point in the loop. A register initialization instruction for initializing the integer adder can be inserted after the entry point in the loop. The one or more inserted instructions include inserting integer adder instruction in branches that increment an integer adder free register by the value of the branch integer when the branch is executed. The one or more inserted instructions include inserting path counter instructions that increment respective path counter free registers by one if the integer adder value is equal to the path value associated with the respective path counter. The path counter instructions can be inserted at an end of the loop after a last branch and prior to an exit point of a loop. In this manner, a respective path counter is incremented through each loop iteration based on the execution path through the loop. Once execution of the loop has completed (e.g., after a plurality of loop iterations), the registers will contain values indicative of the number of times a particular path through the loop has been taken for each possible execution path.
- The one or more inserted instructions include inserting loop path counter array update instructions after the exit point of a loop. The loop path counter array update instructions update loop path counter entries in a loop path counter array with the number of executions for the paths taken through a respective loop associated with the executable program. The loop path counter array update instructions can be embedded in a multi-thread safe set of ownership instructions, such as a spinlock operation. The loop path counter array maintains a count associated with total path executions of each possible execution path over one or more loop executions associated with a given loop.
- At 180, the modified instrumented executable function is encoded into a binary executable, and stored in shared memory. At 190, the break in the executable program associated with the given function is replaced with a branch/jump to the instrumented function and control is returned to the executable program. The methodology then proceeds to 200 where execution is continued at the start of the instrumented function. The methodology then returns to 110 until the next breakpoint is encountered.
-
FIG. 8 illustrates an alternate methodology for branch profiling a loop associated with an executable program. At 220, integer add instructions are inserted in branches of a loop in an executable program. At 230, path counter instructions are inserted after a last branch of the loop and prior to an exit point of the loop. At 240, loop counter array update instructions are inserted after an exit point of the loop. -
FIG. 9 illustrates yet another alternate methodology for branch profiling of an executable program. At 260, branch profiling is performed on at least one loop of an executable program to assign branch integers to branches and path values to execution paths in the at least one loop. At 270, integer add instructions are inserted in branches of the at least one loop. At 280, path counter instructions are inserted at an end of the at least one loop. At 290, loop path counter array update instructions are inserted after an exit point of the at least one loop. -
FIG. 10 illustrates acomputer system 320 that can be employed to execute one or more embodiments employing computer executable instructions. Thecomputer system 320 can be implemented on one or more general purpose networked computer systems, embedded computer systems, routers, switches, server devices, client devices, various intermediate devices/nodes and/or stand alone computer systems. - The
computer system 320 includes aprocessing unit 321, asystem memory 322, and asystem bus 323 that couples various system components including the system memory to theprocessing unit 321. Dual microprocessors and other multi-processor architectures also can be used as theprocessing unit 321. The system bus may be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 324 and random access memory (RAM) 325. A basic input/output system (BIOS) can reside in memory containing the basic routines that help to transfer information between elements within thecomputer system 320. - The
computer system 320 can includes ahard disk drive 327, amagnetic disk drive 328, e.g., to read from or write to aremovable disk 329, and anoptical disk drive 330, e.g., for reading a CD-ROM disk 331 or to read from or write to other optical media. Thehard disk drive 327,magnetic disk drive 328, andoptical disk drive 330 are connected to thesystem bus 323 by a harddisk drive interface 332, a magneticdisk drive interface 333, and anoptical drive interface 334, respectively. The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, and computer-executable instructions for thecomputer system 320. Although the description of computer-readable media above refers to a hard disk, a removable magnetic disk and a CD, other types of media which are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks and the like, may also be used in the operating environment, and further that any such media may contain computer-executable instructions. - A number of program modules may be stored in the drives and
RAM 325, including anoperating system 335, one or more executable programs 336,other program modules 337, andprogram data 338. A user may enter commands and information into thecomputer system 320 through akeyboard 340 and a pointing device, such as amouse 342. Other input devices (not shown) may include a microphone, a joystick, a game pad, a scanner, or the like. These and other input devices are often connected to theprocessing unit 321 through acorresponding port interface 346 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, a serial port or a universal serial bus (USB). Amonitor 347 or other type of display device is also connected to thesystem bus 323 via an interface, such as avideo adapter 348. - The
computer system 320 may operate in a networked environment using logical connections to one or more remote computers, such as aremote client computer 349. Theremote computer 349 may be a workstation, a computer system, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to thecomputer system 320. The logical connections can include a local area network (LAN) 351 and a wide area network (WAN) 352. - When used in a LAN networking environment, the
computer system 320 can be connected to thelocal network 351 through a network interface oradapter 353. When used in a WAN networking environment, thecomputer system 320 can include amodem 354, or can be connected to a communications server on the LAN. Themodem 354, which may be internal or external, is connected to thesystem bus 323 via theport interface 346. In a networked environment, program modules depicted relative to thecomputer system 320, or portions thereof, may be stored in the remotememory storage device 350. - What have been described above are examples of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art will recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.
Claims (30)
1. A system for branch profiling an executable program, the system comprising:
a branch profiler that assigns branch integers to branches in a loop and a plurality of path values that correspond to sums of the branch integers through respective execution paths in the loop; and
a probe instrument that inserts an integer add instruction into branches of the loop, a set of path counter instructions after a last branch in the loop, and a set of loop path counter array update instructions after an exit point of the loop.
2. The system of claim 1 , wherein the integer add instructions adds assigned branch integers of executed branches to provide a path value associated with an executed path through the loop for a single loop iteration, the set of path counter instructions increment path counters corresponding to executed paths over a plurality of loop iterations, and the set of loop path counter array update instructions update a loop path counter array that retains a count associated with executed paths over a plurality of loop executions.
3. The system of claim 1 , further comprising a shared memory that retains the loop path counter array wherein the loop path counter array includes a plurality of loop path counter entries corresponding to different execution paths through the loop.
4. The system of claim 3 , wherein the set of loop path counter array update instructions is embedded in a set of loop path counter array ownership instructions that facilitate multi-threaded safe loop path counter array integrity.
5. The system of claim 4 , wherein the shared memory retains a loop path counter array access flag associated with the loop path counter array, the set of loop path counter array ownership instructions comprising at least a first instruction for requesting access to the loop path counter array and setting the loop path counter array access flag prior to updating the loop path counter array, and at least a second instruction for resetting the loop path counter array access flag after updating the loop path counter array, such that access of the loop path counter array is controlled based on the state of the loop path counter array access flag.
6. The system of claim 1 , wherein the integer add instruction adds branch integers to a free register of the system.
7. The system of claim 1 , wherein the set of path counter instructions comprise incrementing path counter registers assigned to respective execution paths.
8. The system of claim 1 , wherein the set of path counter instructions comprise comparing a value of an integer adder associated with the integer add instructions with the plurality of path values and incrementing a corresponding path counter assigned to a respective execution path for each of a plurality of loop iterations.
9. The system of claim 1 , wherein the probe instrument inserts an initialization instruction after a loop entry point to reset an integer adder and inserts initialization instructions prior to the loop entry point to reset the set of path counters.
10. The system of claim 1 , wherein the loop path counter array update instructions update a plurality of loop path counter entries in a loop path counter array by adding the corresponding value of an associated path counter to its associated loop path counter entry.
11. The system of claim 10 , wherein the loop path counter array update instructions update loop path counter entries with associated path counters that have a non-zero value.
12. The system of claim 1 , wherein the loop is at least one of an innermost loop, an intermediary loop and an outermost loop of the executable program.
13. A method of branch profiling of an executable program, the method comprising:
inserting an integer add instruction in branches of a loop of the executable program;
inserting path counter instructions after a last branch of the loop and prior to an exit point of the loop; and
inserting loop counter array update instructions after the exit point of the loop.
14. The method of claim 13 , further comprising finding a first free register to employ as an integer adder, and a set free registers to be employed as path counters for respective execution paths through the loop.
15. The method of claim 14 , further comprising inserting initialization instruction to reset the path counters prior to an entry point of the loop, and inserting initialization instructions to reset the integer adder after the entry point of the loop.
16. The method of claim 13 , further comprising repeating the inserting an integer adder instruction, inserting path counter instructions, and inserting loop counter array update instructions for a plurality of loops in a function of the executable program.
17. The method of claim 13 , further comprising inserting the loop counter array update instructions between a loop path counter array ownership request instruction and a loop path counter array ownership release instruction, wherein a loop path counter array access flag is set when ownership of the loop path counter array is provided and reset when ownership of the loop path counter array is released.
18. The method of claim 13 , wherein the inserting an integer add instruction, inserting path counter instructions, and inserting loop counter array update instructions is performed dynamically for a given function of the executable program as functions are executed.
19. A computer readable medium having computer executable instruction for performing a method comprising:
performing a branch profiling on at least one loop in an executable program to assign branch integers to branches and path values to execution paths in the at least one loop;
inserting integer add instructions to branches of the at least one loop;
inserting path counter instructions at an end of the at least one loop; and
inserting loop path counter array update instructions after an exit point of the at least one loop.
20. The computer readable medium having computer executable instruction for performing the method claim 19 , further comprising performing loop analysis on an executable program to identify the at least one loop.
21. The computer readable medium having computer executable instruction for performing the method claim 20 , wherein the performing a loop analysis on an executable program comprises:
representing a function of the executable program as an intermediate representation;
constructing a control flow graph from the intermediate representation; and
performing a loop recognition algorithm on the control flow graph to identify at least one loop in the function.
22. The computer readable medium having computer executable instruction for performing the method claim 19 , wherein execution of the integer add instructions add a respective assigned branch integer of an executed branch to an integer add register, and execution of the path counter instructions increment a respective assigned path counter register based on a value of the integer add register after completion of an execution path of the at least one loop.
23. The computer readable medium having computer executable instruction for performing the method claim 22 , wherein execution of the loop path counter array update instruction updates loop path counter entries associated with a loop path counter array with the values of at least one loop respective path counter register.
24. The computer readable medium having computer executable instruction for performing the method claim 22 , further comprising inserting integer add register initialization instruction after a loop entry point of the at least one loop, and path counter register initialization instructions prior to a loop entry point.
25. The computer readable medium having computer executable instruction for performing the method claim 19 , further comprising encoding the inserted instructions along with the at least one loop for an associated function to generate an instrumented function, and storing the instrumented function in memory.
26. A dynamic instrumentation system comprising:
means for generating an intermediate representation of a function associated with an executable program;
means for analyzing the intermediate representation to identify at least one loop in the function;
means for performing branch profiling on the identified at least one loop to assign branch integers to branches and path values to execution paths of the identified at least one loop;
means for inserting code into the identified at least one loop, the means for inserting code inserting integer add instructions into branches of the identified at least one loop, and path counter instructions at an end of the identified at least one loop; and
means for encoding the inserted code and the intermediate representation of the function to produce an instrumented function.
27. The system of claim 26 , wherein the means for inserting code further comprising inserting loop path counter array update instructions after an exit point of the identified at least one loop.
28. The system of claim 27 , further comprising means for storing a loop path counter array associated with execution of the loop path counter array update instructions.
29. The system of claim 27 , wherein the means for inserting code into the identified at least one loop comprising embedding the loop path counter array update instructions between loop path counter array ownership instructions that facilitate multi-threaded safe loop path counter array integrity.
30. The system of claim 26 , wherein the means for inserting code into the identified at least one loop comprising inserting an integer add register initialization instruction after a loop entry point of the identified at least one loop, and path counter register initialization instructions prior to the loop entry point of the identified at least one loop.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/089,585 US20050251791A1 (en) | 2004-04-14 | 2004-04-14 | Systems and methods for branch profiling loops of an executable program |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/089,585 US20050251791A1 (en) | 2004-04-14 | 2004-04-14 | Systems and methods for branch profiling loops of an executable program |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050251791A1 true US20050251791A1 (en) | 2005-11-10 |
Family
ID=35240793
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/089,585 Abandoned US20050251791A1 (en) | 2004-04-14 | 2004-04-14 | Systems and methods for branch profiling loops of an executable program |
Country Status (1)
Country | Link |
---|---|
US (1) | US20050251791A1 (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050281202A1 (en) * | 2004-06-22 | 2005-12-22 | Intel Corporation | Monitoring instructions queueing messages |
US20060053143A1 (en) * | 2004-08-17 | 2006-03-09 | Lisa Liu | Method and apparatus for managing a data structure for multi-processor access |
US20060215567A1 (en) * | 2005-03-25 | 2006-09-28 | Arun Raghunath | Method and apparatus for monitoring path statistics |
US20070180439A1 (en) * | 2006-02-01 | 2007-08-02 | Sun Microsystems, Inc. | Dynamic application tracing in virtual machine environments |
US20080301650A1 (en) * | 2007-05-31 | 2008-12-04 | Microsoft Corporation | Static performance analysis of software |
US20090249306A1 (en) * | 2008-03-26 | 2009-10-01 | Avaya Technology Llc | Off-Line Program Analysis and Run-Time Instrumentation |
US20090327997A1 (en) * | 2008-06-25 | 2009-12-31 | Microsoft Corporation | Timing Analysis of Concurrent Programs |
US8260602B1 (en) * | 2006-11-02 | 2012-09-04 | The Math Works, Inc. | Timer analysis and identification |
US8839200B1 (en) * | 2012-07-23 | 2014-09-16 | Google Inc. | Generating profiling data |
US20140281434A1 (en) * | 2013-03-15 | 2014-09-18 | Carlos Madriles | Path profiling using hardware and software combination |
US20150277872A1 (en) * | 2014-03-31 | 2015-10-01 | International Business Machines Corporation | Transparent dynamic code optimization |
US20160062868A1 (en) * | 2014-08-27 | 2016-03-03 | Ca, Inc. | Automated instrumentation of applications |
US20160098273A1 (en) * | 2014-10-03 | 2016-04-07 | International Business Machines Corporation | Servicing multiple counters based on a single access check |
US10162966B1 (en) | 2016-10-19 | 2018-12-25 | Trend Micro Incorporated | Anti-malware system with evasion code detection and rectification |
US10698668B1 (en) * | 2018-05-29 | 2020-06-30 | Amazon Technologies, Inc. | Custom code transformations during compilation process |
US11663008B2 (en) | 2019-03-11 | 2023-05-30 | Samsung Electronics Co., Ltd. | Managing memory device with processor-in-memory circuit to perform memory or processing operation |
Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5911073A (en) * | 1997-12-23 | 1999-06-08 | Hewlett-Packard Company | Method and apparatus for dynamic process monitoring through an ancillary control code system |
US6088525A (en) * | 1997-06-19 | 2000-07-11 | Hewlett-Packard Company | Loop profiling by instrumentation |
US6164841A (en) * | 1998-05-04 | 2000-12-26 | Hewlett-Packard Company | Method, apparatus, and product for dynamic software code translation system |
US6192513B1 (en) * | 1998-11-02 | 2001-02-20 | Hewlett-Packard Company | Mechanism for finding spare registers in binary code |
US6233678B1 (en) * | 1998-11-05 | 2001-05-15 | Hewlett-Packard Company | Method and apparatus for profiling of non-instrumented programs and dynamic processing of profile data |
US6327699B1 (en) * | 1999-04-30 | 2001-12-04 | Microsoft Corporation | Whole program path profiling |
US6353924B1 (en) * | 1999-02-08 | 2002-03-05 | Incert Software Corporation | Method for back tracing program execution |
US6401240B1 (en) * | 1995-11-28 | 2002-06-04 | Hewlett-Packard Company | System and method for profiling code on symmetric multiprocessor architectures |
US6430741B1 (en) * | 1999-02-26 | 2002-08-06 | Hewlett-Packard Company | System and method for data coverage analysis of a computer program |
US20020152455A1 (en) * | 2001-04-11 | 2002-10-17 | Robert Hundt | Dynamic instrumentation of an executable program |
US6481008B1 (en) * | 1999-06-30 | 2002-11-12 | Microsoft Corporation | Instrumentation and optimization tools for heterogeneous programs |
US20030182655A1 (en) * | 2002-03-25 | 2003-09-25 | Hewlett Packard Company | Unwinding instrumented program code |
US20030212988A1 (en) * | 2002-05-09 | 2003-11-13 | Hewlett-Packard Company | Preserving program context when adding probe routine calls for program instrumentation |
US20030225996A1 (en) * | 2002-05-30 | 2003-12-04 | Hewlett-Packard Company | Prefetch insertion by correlation of cache misses and previously executed instructions |
US6848100B1 (en) * | 2000-03-31 | 2005-01-25 | Intel Corporation | Hierarchical software path profiling |
US20050071606A1 (en) * | 2003-09-30 | 2005-03-31 | Roman Talyansky | Device, system and method of allocating spill cells in binary instrumentation using one free register |
US6938249B2 (en) * | 2001-11-19 | 2005-08-30 | International Business Machines Corporation | Compiler apparatus and method for optimizing loops in a computer program |
-
2004
- 2004-04-14 US US11/089,585 patent/US20050251791A1/en not_active Abandoned
Patent Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6401240B1 (en) * | 1995-11-28 | 2002-06-04 | Hewlett-Packard Company | System and method for profiling code on symmetric multiprocessor architectures |
US6088525A (en) * | 1997-06-19 | 2000-07-11 | Hewlett-Packard Company | Loop profiling by instrumentation |
US5911073A (en) * | 1997-12-23 | 1999-06-08 | Hewlett-Packard Company | Method and apparatus for dynamic process monitoring through an ancillary control code system |
US6164841A (en) * | 1998-05-04 | 2000-12-26 | Hewlett-Packard Company | Method, apparatus, and product for dynamic software code translation system |
US6192513B1 (en) * | 1998-11-02 | 2001-02-20 | Hewlett-Packard Company | Mechanism for finding spare registers in binary code |
US6233678B1 (en) * | 1998-11-05 | 2001-05-15 | Hewlett-Packard Company | Method and apparatus for profiling of non-instrumented programs and dynamic processing of profile data |
US6353924B1 (en) * | 1999-02-08 | 2002-03-05 | Incert Software Corporation | Method for back tracing program execution |
US6430741B1 (en) * | 1999-02-26 | 2002-08-06 | Hewlett-Packard Company | System and method for data coverage analysis of a computer program |
US6327699B1 (en) * | 1999-04-30 | 2001-12-04 | Microsoft Corporation | Whole program path profiling |
US6481008B1 (en) * | 1999-06-30 | 2002-11-12 | Microsoft Corporation | Instrumentation and optimization tools for heterogeneous programs |
US6848100B1 (en) * | 2000-03-31 | 2005-01-25 | Intel Corporation | Hierarchical software path profiling |
US20020152455A1 (en) * | 2001-04-11 | 2002-10-17 | Robert Hundt | Dynamic instrumentation of an executable program |
US6938249B2 (en) * | 2001-11-19 | 2005-08-30 | International Business Machines Corporation | Compiler apparatus and method for optimizing loops in a computer program |
US20030182655A1 (en) * | 2002-03-25 | 2003-09-25 | Hewlett Packard Company | Unwinding instrumented program code |
US20030212988A1 (en) * | 2002-05-09 | 2003-11-13 | Hewlett-Packard Company | Preserving program context when adding probe routine calls for program instrumentation |
US20030225996A1 (en) * | 2002-05-30 | 2003-12-04 | Hewlett-Packard Company | Prefetch insertion by correlation of cache misses and previously executed instructions |
US20050071606A1 (en) * | 2003-09-30 | 2005-03-31 | Roman Talyansky | Device, system and method of allocating spill cells in binary instrumentation using one free register |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050281202A1 (en) * | 2004-06-22 | 2005-12-22 | Intel Corporation | Monitoring instructions queueing messages |
US20060053143A1 (en) * | 2004-08-17 | 2006-03-09 | Lisa Liu | Method and apparatus for managing a data structure for multi-processor access |
US8316048B2 (en) * | 2004-08-17 | 2012-11-20 | Hewlett-Packard Development Company, L.P. | Method and apparatus for managing a data structure for multi-processor access |
US20060215567A1 (en) * | 2005-03-25 | 2006-09-28 | Arun Raghunath | Method and apparatus for monitoring path statistics |
US20070180439A1 (en) * | 2006-02-01 | 2007-08-02 | Sun Microsystems, Inc. | Dynamic application tracing in virtual machine environments |
US7818721B2 (en) * | 2006-02-01 | 2010-10-19 | Oracle America, Inc. | Dynamic application tracing in virtual machine environments |
US8868399B1 (en) | 2006-11-02 | 2014-10-21 | The Mathworks, Inc. | Timer analysis and identification |
US8260602B1 (en) * | 2006-11-02 | 2012-09-04 | The Math Works, Inc. | Timer analysis and identification |
US20080301650A1 (en) * | 2007-05-31 | 2008-12-04 | Microsoft Corporation | Static performance analysis of software |
US8087006B2 (en) * | 2007-05-31 | 2011-12-27 | Microsoft Corporation | Static performance analysis of software |
US20090249306A1 (en) * | 2008-03-26 | 2009-10-01 | Avaya Technology Llc | Off-Line Program Analysis and Run-Time Instrumentation |
US8291399B2 (en) * | 2008-03-26 | 2012-10-16 | Avaya Inc. | Off-line program analysis and run-time instrumentation |
US8719801B2 (en) * | 2008-06-25 | 2014-05-06 | Microsoft Corporation | Timing analysis of concurrent programs |
US20090327997A1 (en) * | 2008-06-25 | 2009-12-31 | Microsoft Corporation | Timing Analysis of Concurrent Programs |
US8943479B1 (en) | 2012-07-23 | 2015-01-27 | Google Inc. | Generating profiling data |
US8839200B1 (en) * | 2012-07-23 | 2014-09-16 | Google Inc. | Generating profiling data |
US20140281434A1 (en) * | 2013-03-15 | 2014-09-18 | Carlos Madriles | Path profiling using hardware and software combination |
US20150277872A1 (en) * | 2014-03-31 | 2015-10-01 | International Business Machines Corporation | Transparent dynamic code optimization |
US9489229B2 (en) * | 2014-03-31 | 2016-11-08 | International Business Machines Corporation | Transparent dynamic code optimization |
US9594662B2 (en) * | 2014-08-27 | 2017-03-14 | Ca, Inc. | Automated instrumentation of applications |
US20160062868A1 (en) * | 2014-08-27 | 2016-03-03 | Ca, Inc. | Automated instrumentation of applications |
US20160098273A1 (en) * | 2014-10-03 | 2016-04-07 | International Business Machines Corporation | Servicing multiple counters based on a single access check |
US9760302B2 (en) * | 2014-10-03 | 2017-09-12 | International Business Machines Corporation | Servicing multiple counters based on a single access check |
US10534557B2 (en) | 2014-10-03 | 2020-01-14 | International Business Machines Corporation | Servicing multiple counters based on a single access check |
US10162966B1 (en) | 2016-10-19 | 2018-12-25 | Trend Micro Incorporated | Anti-malware system with evasion code detection and rectification |
US10698668B1 (en) * | 2018-05-29 | 2020-06-30 | Amazon Technologies, Inc. | Custom code transformations during compilation process |
US11663008B2 (en) | 2019-03-11 | 2023-05-30 | Samsung Electronics Co., Ltd. | Managing memory device with processor-in-memory circuit to perform memory or processing operation |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7202293B2 (en) | Systems, methods and devices for vertically integrated instrumentation and trace reconstruction | |
US20050251791A1 (en) | Systems and methods for branch profiling loops of an executable program | |
Alglave et al. | Partial orders for efficient bounded model checking of concurrent software | |
US8572573B2 (en) | Methods and apparatus for interactive debugging on a non-preemptible graphics processing unit | |
US7950001B2 (en) | Method and apparatus for instrumentation in a multiprocessing environment | |
US6658471B1 (en) | Method and system for zero overhead software performance measurement instrumentation | |
Gotsman et al. | Show no weakness: sequentially consistent specifications of TSO libraries | |
TW201128383A (en) | Portable executable file analysis | |
JP7209736B2 (en) | How to debug your processor | |
JP2005332387A (en) | Method and system for grouping and managing memory instruction | |
US10318261B2 (en) | Execution of complex recursive algorithms | |
US10324693B2 (en) | Optimizing multiple invocations of graphics processing unit programs in Java | |
US20050251790A1 (en) | Systems and methods for instrumenting loops of an executable program | |
US8392891B2 (en) | Technique for finding relaxed memory model vulnerabilities | |
US11366740B2 (en) | Debugging shared memory errors | |
US20130304996A1 (en) | Method and system for run time detection of shared memory data access hazards | |
US8453131B2 (en) | Method and apparatus for ordering code based on critical sections | |
Su et al. | An efficient GPU implementation of inclusion-based pointer analysis | |
Ding et al. | Hardware support to improve fuzzing performance and precision | |
US7823141B1 (en) | Using a concurrent partial inspector loop with speculative parallelism | |
Kumar et al. | Instrumentation in software dynamic translators for self-managed systems | |
Winter et al. | Observational models for linearizability checking on weak memory models | |
Brais et al. | Alleria: An advanced memory access profiling framework | |
Milewicz et al. | Lightweight runtime checking of C programs with RTC | |
Jungblut et al. | Source-to-Source Instrumentation for Profiling Runtime Behavior of C++ Containers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |