JP5572619B2 - Computer for calculating the number of trace information, method for calculating the number of trace information, and program for calculating the number of trace information - Google Patents

Description

  The present invention relates to a computer for calculating the number of trace information acquired by a tracer, a method for calculating the number of trace information acquired by the tracer, and a program for calculating the number of trace information acquired by the tracer.

  A computer system used in a company is required to have high reliability. Therefore, when a failure occurs, a system maintenance person must quickly recover the system from the failure. For this reason, system maintenance personnel use program tracer (hereinafter referred to as “tracer”), which is a support tool for grasping the program structure and behavior during program execution, to instantly find the faulty part in program execution. doing. Since the tracer outputs method call information in the execution program as a trace file, by analyzing the output trace information, it is possible to grasp the failure occurrence process without reproducing the failure occurrence.

  As in the trace information acquisition method disclosed in Patent Document 1, there is a technique for reducing overhead by using sampling and thinning out trace information to be acquired. However, since it is necessary to acquire an accurate program execution path in failure analysis, it is not preferable to apply sampling. As another overhead countermeasure, there is a method of preparing a buffer that temporarily holds trace information inside the tracer. In this method, since the external output to a file or the like can be reduced by caching in a buffer on the memory, the overhead can be reduced. However, if the trace information of the program to be traced exceeds the size of the buffer, it is necessary to perform external output or overwrite a part of the acquired information. In the former case, high overhead, in the latter case information The problem of loss occurs.

  As a method for solving the above problem, Patent Document 2 discloses a technique for adjusting the buffer size of a buffer used when executing an application program, for example, a communication control program operating in a multitask environment. . Patent Document 2 discloses a technique for recording an execution pattern of a program and an allocated buffer size when executing an application program, and allocating a buffer having a size corresponding to the recorded execution pattern when it appears again. Yes.

JP 2010-9282 A JP 10-69429 A

  In the technique disclosed in Patent Document 2, when the execution pattern of a program appears repeatedly as in normal operation, the number of trace information acquired per program execution is once after the program is executed once. Can be requested. However, when a system failure occurs, an execution pattern of a program different from the normal one appears, so the number of trace information acquired per program execution cannot be obtained. Further, since the number of pieces of trace information to be acquired cannot be obtained before executing the program, it is difficult to determine in advance the size of the buffer necessary for storing the trace information.

  According to a representative aspect of the present invention, a computer that calculates the number of trace information acquired by a tracer, the computer having a control unit that identifies an element that controls a flow of a program, the control The unit specifies the number of elements before execution of the program, and calculates the number of pieces of trace information to be acquired based on the specified number of elements.

  According to the present invention, the number of pieces of trace information acquired by the tracer can be calculated before executing the program.

It is a figure which shows the whole structure of the computer in 1st Embodiment which is one embodiment to which this invention is applied. It is a flowchart which shows the outline | summary of the process which the computer in 1st Embodiment to which this invention is applied performs. It is a flowchart which shows operation | movement of the static analysis data generation process in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the execution program in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the component tree of the execution program shown to FIG. 4A in 1st Embodiment of the computer to which this invention is applied. It is a flowchart which shows operation | movement of the node production | generation process in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the execution program which contains a recursive method in the program in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the program component tree of the execution program shown to FIG. 6A in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the execution program which contains several recursive methods in the program in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the program component tree of the execution program shown to FIG. 7A in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the execution program which contains a loop in the program in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the program component tree of the execution program shown to FIG. 8A in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the execution program which contains a conditional branch in the program in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the program component tree of the execution program shown to FIG. 9A in 1st Embodiment of the computer to which this invention is applied. It is a flowchart which shows operation | movement of the current node change process in 1st Embodiment of the computer to which this invention is applied. It is a flowchart which shows operation | movement of the current node restoration process in 1st Embodiment of the computer to which this invention is applied. It is a flowchart which shows the operation | movement of the buffer size calculation process in 1st Embodiment of the computer to which this invention is applied. It is a flowchart which shows the operation | movement of the program rewriting process in 1st Embodiment of the computer to which this invention is applied. It is an example of the program before probe insertion in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the program image after the probe insertion in 1st Embodiment of the computer to which this invention is applied. It is a flowchart which shows operation | movement of the trace information acquisition process in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the execution program in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the buffer storage example of the trace information acquired from the execution program shown to FIG. 17B in 1st Embodiment of the computer to which this invention is applied. It is an example of the trace output in 1st Embodiment of the computer to which this invention is applied. It is a figure which shows the execution program in 1st Embodiment of the computer to which this invention is applied. It is an output example of trace information when a failure occurs during execution of the execution program shown in FIG. 19A in the first embodiment of the computer to which the present invention is applied. It is a figure which shows the whole structure of the computer in 2nd Embodiment which is one Embodiment to which this invention is applied. It is a figure which shows the execution program in 2nd Embodiment to which this invention is applied. It is a figure which shows an example of the execution history data of the execution program shown to FIG. 21A in 2nd Embodiment to which this invention is applied. It is a figure which shows an example of the user execution data in 2nd Embodiment to which this invention is applied. It is a flowchart which shows the outline | summary of the process which the computer in 2nd Embodiment to which this invention is applied. It is a flowchart which shows the operation | movement of the expansion buffer size calculation process in 2nd Embodiment to which this invention is applied. It is a flowchart which shows the operation | movement of the buffer size calculation process by the execution probability in 2nd Embodiment to which this invention is applied. It is a figure which shows an example of the display screen which shows the execution probability table | surface of each node of the execution program in 2nd Embodiment to which this invention is applied. The program component tree selected based on the execution probability table | surface shown to FIG. 26A in 2nd Embodiment to which this invention is applied is shown. It is a flowchart which shows the operation | movement of the buffer reallocation process in 2nd Embodiment to which this invention is applied.

[First Embodiment]
In the first embodiment of the computer system to which the present invention is applied, in the tracer used for program failure analysis, the number of program components that can be executed in one execution of the program on the target system is obtained from the source program and binary. The method will be described. Here, the program component is an element that controls the flow of the program. Specifically, it refers to variable access such as method, loop, conditional branch, recursion, argument / return value, and local variable. Although this embodiment will be described for a system described in Java (registered trademark), it is also effective for systems described in other languages. Further, in the following description, the term “program” refers to Java bytecode (binary). However, in the case of description using a specific example of the program, the program is expressed in the form of source code for easy explanation.

  In general, in a loop and recursion in a program to be traced, the execution of program components such as method calls is remarkably increased. For this reason, in order to obtain information on all program components in the loop and recursion, it is necessary to secure the buffer size in proportion to the number of acquisitions. There is a possibility that it cannot be done.

  In the present embodiment, a program component tree is generated from a Java program to be traced. Then, based on the program component tree, the number of program components per program execution is obtained, and the size of the buffer storing the trace information is calculated. In addition, even if a failure occurs in the loop or recursion process, the "History of loop or recursion execution" or "Loop or recursion repeat count" required to identify the cause of the failure without reproducing the failure. "And" Last execution history of element group constituting repetition "are stored in the buffer. As a result, even if a loop or recursion is executed in the program, it is not necessary to acquire all trace information associated with the execution of the loop or recursion. Can be used.

Hereinafter, the configuration and processing flow of the present embodiment will be described in detail with reference to the drawings.
FIG. 1 shows the overall configuration of a computer 101 according to the first embodiment to which the present invention is applied.
The computer 101 has a CPU 102 and a memory 103. The CPU 102 executes the Java virtual machine 104. The Java virtual machine 104 includes a program reading unit 105, a static analysis data generation unit 106, a static analysis data reading unit 107, a buffer size calculation unit 108, a program rewriting unit 109, a program execution unit 110, a trace information acquisition unit 111, and a trace. An information output unit 112 is included. The functional unit described above is realized by the cooperation of the CPU 102 and the program 113.
The memory 103 has a buffer 116 that holds a program 113, an extension program 114, static analysis data 115, and trace information 117. Note that the program 113, the extended program 114, and the static analysis data 115 may be stored in the external storage device 118 instead of on the memory 103. In the present embodiment, the buffer 116 is described as being provided in the memory 103, but the buffer 116 may be provided in the CPU 102.

The program reading unit 105 reads the program 113 stored in the memory 103.
The static analysis data generation unit 106 generates static analysis data 115 of the read program 113. The static analysis data 115 is information indicating the execution order of program components. In the present embodiment, it is assumed that the static analysis data 115 is composed of a tree having program components as nodes (hereinafter referred to as “program component tree”).
The static analysis data reading unit 107 reads the static analysis data 115 generated by the static analysis data generation unit 106 from the memory 103.
The buffer size calculation unit 108 calculates a buffer size from the read static analysis data 115, and generates a buffer 116 having the calculated buffer size on the memory 103.
The program rewriting unit 109 inserts a probe for acquiring the trace information 117 into the program 113 and arranges the extended program 114 into which the probe is inserted in the memory 103.
The program execution unit 110 reads the extension program 114 from the memory 103 and executes it.
The trace information acquisition unit 111 acquires the trace information 117 from the executed extension program 114 and stores the acquired trace information 117 in the buffer 116.
The trace information output unit 112 outputs the trace information 117 stored in the buffer 116 to the external storage device 118. Since the trace information 117 is acquired every time the program 113 is executed, the usage amount of the buffer 116 and the load on the memory 103 can be reduced by outputting the acquired trace information 117 to the external storage device 118. .

FIG. 2 is a flowchart showing the overall flow of processing executed by the computer 101 of this embodiment.
First, in S <b> 201, the program reading unit 105 reads the program 113 stored on the memory 103.
Next, in S202, the static analysis data generation unit 106 checks whether the static analysis data 115 has not been generated. If the static analysis data 115 has not been generated (S202: Yes), the static analysis data generation unit 106 generates the static analysis data 115 from the program 113 on the memory 103 and places it in the memory 103 in S203. (Static analysis data generation processing). When the static analysis data 115 has been generated (S202: No), the static analysis data reading unit 107 reads the static analysis data 115 from the memory 103 (static analysis data reading process) in S204.
In step S <b> 205, the buffer size calculation unit 108 calculates the buffer size based on the static analysis data 115 and generates the buffer 116 having the calculated buffer size on the memory 103 (buffer size calculation processing).
Next, in S206, the program rewriting unit 109 inserts a probe for acquiring the trace information 117 into the read program 113, and arranges the program into which the probe has been inserted in the memory 103 as the expansion program 114 (program rewriting process). ).
Next, in S207, the program execution unit 110 reads the extension program 114 from the memory 103, and acquires the trace information 117 while executing the read extension program 114 (program execution process). At this time, it is confirmed whether or not a failure has occurred in the acquired trace information 117. The failure occurrence means that the Java virtual machine 104 or a thread (Java thread) operating on the Java virtual machine 104 terminates illegally, a failure in which an arbitrary or specific exception occurs, and an illegal operation as a result. Refers to a failure that occurs.
Next, in S208, the trace information acquisition unit 111 stores the acquired trace information 117 in the buffer 116 (trace information acquisition process).
Finally, in S209, the trace information output unit 112 outputs the trace information 117 stored in the buffer 116 to a screen or an external output device (not shown) when a system failure occurs (trace information output process).

Hereinafter, each process shown in FIG. 2 will be described in more detail.
FIG. 3 is a flowchart showing the flow of the static analysis data generation process (S203 in FIG. 2) performed by the static analysis data generation unit 106. In the static analysis data generation process, a program component tree is generated based on the program 113. In the program component tree, program components are handled as nodes. In addition, a component existing in a body part (actual processing part in a loop or conditional branch) such as a loop or conditional branch is a parent node of a component (loop node, conditional branch node, or recursive node) that contains them. Treat as a child node.

First, in S301, a control flow analysis is executed for the program 113 to be traced. Control flow analysis refers to extracting the program flow when the program 113 is executed in units of program components.
Next, in S302, a start point method is searched from the program 113, and a node corresponding to the searched start point method is generated. The starting point method is a method that becomes a starting point of processing such as a main method in Java, a run method of thread programming, and a doGet method of a servlet. Note that the start point method can be arbitrarily specified by the user.
Next, in S303, the generated node is set as the current node. The current node means a parent node when a child node is added to the program component tree.
Next, in S304, the next program component that becomes a child node is searched for in the program belonging to the set current node.
In step S305, it is checked whether the searched program component is the last program component corresponding to the current node. That is, if the parent node is a method node, it is confirmed whether it is the last element constituting the method, and if it is a loop node, it is the last element constituting the loop body.

If it is not the last program component corresponding to the set current node (S305: No), the program component extracted in S301 is read in the order of control flow in S306.
In step S307, it is confirmed whether the read program component is a node generation target. Here, if it is a node generation target (S307: Yes), node generation processing is performed in S308. If it is not a node generation target (S307: No), the process returns to S305 (node generation processing).
Next, in S309, the current node is changed to a new node generated from the current current node (current node changing process). Then, the process returns to S305 to check whether it is the last program component corresponding to the current node.

On the other hand, if the set current node is the last program component (S305: Yes), it is checked in S310 whether the current node is the last program component of the start method.
If the current node is not the last program component of the start point method (S310: No), the current node currently set as the current node is set as the parent node in S311 (current node restoration process).
On the other hand, if the current node is the last program component of the start method (S310: Yes), the generated program component tree is output to the memory 103 as the static analysis data 115 in S312 and the node generation process is terminated. To do.

The static analysis data generation process described above will be described in more detail using a specific example. FIG. 4A shows a program 401 as an example of the program 113 executed by the computer. FIG. 4B shows a program component tree when the node generation process is executed for the program 401 shown in FIG. 4A.
First, a control flow analysis is performed on the program 401 (S301 in FIG. 3). Then, the main method 402 that is the program start point method is searched from the program 401, and a node 405 of the main method 402 is generated (S302). Next, the node 405 is set as the current node (S303), and the next program component in the main method 402 is searched (S304). As a result, the program component of methodA403 in the main method 402 is extracted, and since methodA403 is not the last program component (S305: No), and is a program that is a node generation target (S307: Yes), the node of methodA403 406 is generated (S308). Then, a current node change process is performed (S309), methodB404 is extracted as the next program component in methodA403, and node 408 of methodB404 is generated.

FIG. 5 is a flowchart showing a process flow of the node generation process (S308 in FIG. 3) performed by the static analysis data generation unit 106. The node generation process generates nodes (method nodes, recursive nodes, loop nodes, conditional branch nodes, etc.) determined as node generation targets in S308 of FIG. Note that the result of the control flow analysis obtained in S301 of FIG.
First, in S501, it is confirmed whether or not the program component that is a node generation target is a program component that calls a method. If it is a program component that calls a method (S501: Yes), in S502, it is determined whether or not the program component is a recursive method. If the method is a recursive method (S502: Yes), a recursive method node is generated in S503. If it is not a recursive method (S502: No), a method node is generated in S504.

  For example, FIG. 6A shows a program 601 that includes a recursive method 602. The program component tree of the program 601 is expressed as 603 or 608 in FIG. 6B. methodB is a recursive method that calls its own method as in 602, and is expressed as a node 606 in the program component tree 603. The number shown in the node 606 is a recursion ID uniquely assigned to the recursive node. Further, the recursive method may be handled as one node like the recursive node 611 of the program component tree 608. In the case of a recursive call that extends over a plurality of methods like the program 701 shown in FIG. 7A, the program component tree is expressed in FIG. 7B.

  Next, when the program component that is a node generation target is not a program component that calls a method (S501: No), in S505, it is determined whether or not the program component is a program component that indicates a loop. If it is a program component indicating a loop (S505: Yes), a loop node is generated in S506.

  For example, a program component tree for program 801 including the loop shown in FIG. 8A is shown in FIG. 8B. A portion 802 indicating a loop is shown as a for loop node 807 in FIG. 8B as a loop node. The number in the for loop node 807 represents the loop ID. A group of method calls in the loop indicated by 803 and 804 are shown as child nodes 808 and 809 of the for loop node 807. 8 illustrates the description of only the for loop, but the while loop and the do while loop may also be indicated as a while loop node and a do while loop node, respectively, similarly to the for loop.

  Next, when the program component to be generated is not a program component indicating a loop (S505: No), it is determined in S507 whether the program component is a program component indicating a conditional branch. If it is a program component indicating a conditional branch (S507: Yes), a conditional branch node is generated in S508. If it is not a program component indicating a conditional branch (S507: No), the node generation process is terminated.

  For example, the program component tree of the program 901 including the conditional branch shown in FIG. 9A is shown in FIG. 9B. The portions indicating the conditional branches 902 and 903 are represented by conditional branch nodes 906 and 909 on the program component tree. The else if statement of 903 is expressed as a child node of the conditional branch node 906 generated by the if statement of 902, and the else statement of 904 is expressed as a child node of the conditional branch node 909 generated by the else if statement of 903. . The numbers in the conditional branch nodes 906 and 909 represent the conditional branch ID.

FIG. 10 is a flowchart showing the flow of the current node change process (S309 in FIG. 3) performed by the static analysis data generation unit 106. In the current node changing process, each node generated in the node generating process (S308 in FIG. 3) is set in order as the current node.
First, in S1001, it is confirmed whether or not the node generated in the node generation process (S308 in FIG. 3) is a method node.
If the generated node is a method node (S1001: Yes), in S1002, the position of the component to be read next is set as the head of the call destination method.
In step S1003, the node generated by the node generation process is set as the current node, and the current node change process ends.
If the generated node is not a method node (S1001: No), S1003 is executed, and the current node change process is terminated.

FIG. 11 is a flowchart showing the flow of the current node restoration process (S312 in FIG. 3) performed by the static analysis data generation unit 106. In the current node restoration process, the current node is set as a parent node of the current node.
First, in S1101, it is confirmed whether or not the last program component is a method. If the last program component is a method (S1101: Yes), in S1102, the method is moved to a location where the method call source is located in the program 113, and the current node restoration process is resumed.
In step S1103, the node currently set as the current node is set as the parent node of the current node, and the current node restoration process is terminated.
If the last program component is not a method (S1101: No), S1103 is executed and the current node restoration process is terminated.
The above is the flow of the static analysis data generation process.

FIG. 12 is a flowchart showing the flow of the buffer size calculation process. In the buffer size calculation process, the buffer size is calculated based on the number of nodes of the program component tree in the static analysis data 115, and the buffer 116 having the obtained buffer size is secured.
First, in S1201, the total number of nodes in the program component tree is acquired from the static analysis data 115. For example, the total number of nodes in the program component tree shown in FIG. 9B is 8 from 905 to 912.
In step S1202, the buffer size is calculated based on the total number of nodes. In this embodiment, the buffer size is obtained from “buffer size = total number of nodes in the program component tree × buffer size necessary to acquire trace information for one program component”.
In step S <b> 1203, a buffer area having the buffer size calculated in the memory 103 is secured as the buffer 116.

  In this embodiment, in order to grasp the hierarchical calling relationship of methods, the trace information 117 is acquired at the start and end of the method. However, at what timing the trace information 117 is acquired, Can be specified by the user. In the present embodiment, with respect to conditional branching, looping, and recursion, the trace information 117 is acquired at the start and end of each element as in the case of the method.

In this embodiment, the buffer size required to acquire information for one program component is set to 2. For example, since the total number of nodes in the program component tree shown in FIG. 9B is 8, as described above, the buffer size required to store the trace information 117 acquired by executing the program 901 in FIG. 9A is It is calculated as 8 × 2 = 16. The buffer size is the length of the array held by the tracer. In the case of the program 901, the buffer 116 on the memory 103 has an array length of 16.
In the present embodiment, the buffer size necessary to acquire the trace information 117 for one program component is set to 2, but the user appropriately specifies the buffer size according to the specifications of the buffer 116 for storing the trace information 117. be able to.

  FIG. 13 is a flowchart showing the flow of the program rewriting process (S206 in FIG. 2) performed by the program rewriting unit 109. In the program rewriting process, a probe is inserted into the program 113 in order to acquire the trace information 117 of the program 113 read in the program reading process (S201 in FIG. 2). In the present embodiment, a probe for acquiring events is inserted before and after the bytecode corresponding to each event acquired by the tracer using the Bytecode Instrumentation function of Java.

First, in S1301, it is confirmed whether or not there is a class to be read in the program 113 on the memory 103. The class here is a byte code group (binary) generated from Java source code. If there is a class to be read (S1301: Yes), the class is read from the program 113 on the memory 103 in S1302.
In step S1303, it is checked whether the read class is a class to be rewritten. If the read class is the target of rewriting (S1303: Yes), the process proceeds to S1304. If there is no method to be rewritten (S1303: No), the process returns to S1301.
In step S1304, it is confirmed whether there is a method to be rewritten. When there is a method to be rewritten (S1304: Yes), in S1305, an event acquisition probe corresponding to each node related to recursion, method, loop, and conditional branch is inserted. If there is no method to be rewritten (S1304: No), the process returns to S1301.
If there is no class to be read in S1301 (S1301: No), the rewritten program is output to the memory 103 as the extended program 114 in S1306, and the program rewriting process is terminated.

  The events acquired in this embodiment are assumed to be “method start / end”, “recursion start / end”, “loop start / end”, and “conditional branch start / end”. 14 shows an image in which probes of “method start / end”, “recursion start / end”, and “loop start / end” are inserted in the program 1401, and FIG. 15 shows “condition branch start / end”. The image which inserted the probe of "is shown.

As a representative, the image after the probe insertion shown in FIG. 15 will be described in detail.
A methodEntry 1502 is a probe for acquiring a method start event. By using methodEntry 1502, it is possible to acquire a method-specific ID and grasp which method has started. Note that methodEntry 1502 is inserted at the beginning of the method processing.
The ifEntry 1503 is a probe for acquiring a conditional branch start event. By using the ifEntry 1503, it is possible to acquire the ID unique to the conditional branch and the condition held by the conditional branch and grasp which conditional branch has started. Note that ifEntry 1503 is inserted at the head of conditional branch processing.

The recursiveEntry 1504 is a probe for acquiring a recursion start event. By using recursiveEntry 1504, it is possible to acquire the ID unique to the recursion and the number of recursion iterations, and to know which recursion has been repeatedly executed. The recursive entry 1504 is inserted at the beginning of the recursive method process.
The recursive Exit 1505 is a probe for acquiring a recursion end event. By using recursiveExit 1505, it is possible to acquire a unique ID of recursion and grasp which recursion has been executed. The recursiveExit 1505 is inserted immediately after the recursive process is completed.

The forLoopEntry 1506 is a probe for acquiring a start event of a loop (for loop). By using forLoopEntry 1506, it is possible to acquire a loop-specific ID and the number of loop repetitions, and to know which loop has been repeatedly executed. The forLoopEntry 1506 is inserted at the beginning of the iterative process in the loop. The forLoopEntry 1506 is executed many times. This is because the number of repetitions is grasped by executing forLoopEntry 1506.
The forLoopExit 1507 is a probe for acquiring a for loop end event. By using forLoopExit 1507, it is possible to acquire an ID unique to the loop and grasp which loop has finished executing. The forLoopExit 1507 is inserted immediately after the end of the loop process.

A methodExit 1508 is a probe for acquiring a method end event. By using the methodExit 1508, it is possible to acquire a method-specific ID and grasp which method has ended. Note that methodExit 1508 is inserted at the end of processing in the method.
The ifExit 1509 is a probe for acquiring a conditional branch end event. By using ifExit 1509, it is possible to acquire an ID unique to a conditional branch and grasp which conditional branch has ended. Note that ifExit 1509 is inserted at the end of the conditional branch.

  In addition, count1 and count2 described as probe arguments in 1504 and 1506 are variables indicating the number of loop or recursion iterations, and increase by 1 each time a loop or recursion start event is detected. The number of repetitions of count1 and count2 is assigned to each loop ID and recursion ID.

In this embodiment, the probes related to the loops 1506 and 1507 are limited to the for loop. However, a probe similar to the for loop, such as a while LoopEntry or a doWoopLoopEntry probe, is set for the while loop or the do while loop. May be.
In the present embodiment, the acquisition items of each probe are also described with limited acquisition items, but additional information such as the occurrence time of an event may be acquired. Also, the events to be acquired are limited to the above-mentioned eight events of “method start / end”, “recursion start / end”, “loop start / end”, and “condition branch start / end”. However, it is also possible to target events such as acquisition / change events of variables such as arguments and return values.

  The program 113 in which the probe is inserted is rewritten to the extended program 114 by the program rewriting process described above. The extension program 114 is stored in the generated memory 103. Note that this program rewriting process need not be performed for all the programs 113 when there is a user designation such as a package name or a class name, and may be performed only for a designated method.

FIG. 16 is a flowchart showing the flow of the trace information acquisition process (S208 in FIG. 2) performed by the trace information acquisition unit 111. In the trace information acquisition process, the trace information 117 obtained by executing the extension program 114 is stored in the buffer 116 on the memory 103.
First, in S1601, the extension program 114 in which the probe is embedded is executed, and the trace information 117 is acquired.
Next, in S1602, it is confirmed whether the acquired trace information 117 is the start of a loop or the start of recursion. If the trace information 117 is the start of a loop or recursion (S1602: Yes), in S1603, the trace information 117 after the start of the loop or recursion is deleted from the buffer 116 in order to initialize the loop or recursion process. To do. If the initialization overhead is large, the pointer indicating the storage position of the next trace information 117 may be returned to the position of the loop node or recursive node to overwrite the data.
In step S1604, the value of the iteration counter that records the number of times the iteration processing by loop or recursion has been performed is incremented by one.
In step S1605, the trace information 117 is stored in the buffer 116 together with the value of the repetitive counter, and the process of acquiring the trace information 117 is terminated. The repetition counter is stored in the buffer 116 together with trace information 117 corresponding to each event of loop start and recursion start.
If the trace information 117 acquired in S1601 is not a loop or recursion start (S1602: No), the acquired trace information 117 is stored in the buffer 116 in S1606.

  As described above, in this embodiment, the trace information 117 corresponding to the repeated portion such as loop or recursion stored in the buffer 116 is deleted or overwritten. Therefore, only the history that the loop or recursion has been executed, the number of iterations of the loop or recursion, and the final execution history of the iteration remain in the buffer 116. As a result, it is not necessary to leave all the trace information 117 generated when the loop or recursive program is executed by the iterative process included in the program 113, and a buffer 116 having a size larger than necessary is secured. The memory 103 can be used in a planned and efficient manner without the necessity of running out of the buffer 116 or the reserved buffer 116.

Next, a storage example of the program 113 and the buffer 116 including the loop will be described with reference to FIG. 17A shows a program 1701 as an example of a program including a loop. FIG. 17B shows an example of storage on the buffer 116. In FIG. 17B, “C” is a method start event, and “Le” is a loop start. Event, “R” indicates a method end event, and “Lx” indicates a loop end event. Arrows 1723 to 1727 indicate pointers indicating the next storage destination of the trace information 117. 1707 to 1712 show state transition diagrams from the first state to the sixth state of the trace information stored on the buffer 116. Each state transition diagram indicated by reference numerals 1707 to 1712 schematically shows a part of the trace information 117 stored in the buffer 116.

First, when the program 1701 shown in FIG. 17A is executed, a start event of the main method 1702 and a start event of the methodA 1703 inside the main method 1702 are generated. Therefore, as shown in the first state 1707, the start event 1713 of the main method and the start of the methodA method Trace information 117 indicating two start events of the event 1714 is stored.
Next, when the loop 1704 in the method A 1703 is executed once, as shown in the second state 1708, the start event 1715 of the loop, the start event 1716 of the method B 1705, the end event 1717 of the method B 1705, the start event 1718 of the method C 1706, and the method C 1706 Trace information 117 indicating the end event 1719 is stored.

  Then, by returning the pointer 1724 indicating the next storage position of 1719 to the position of the loop start event Le 1715, the trace information 117 from the loop start event Le 1715 to the last method end event R 1719 as in the third state 1709. Is deleted. Alternatively, the pointer 1724 is returned to the position of the loop start event Le 1715, and the trace information 117 is overwritten and stored thereafter. This is because the loop start event occurs again, and thus the trace information 117 of the repeated portion is stored in the same storage destination by deleting or overwriting the repeated data acquired in the past.

Next, after initializing the trace information 117 of the repeated portion, the trace information 117 corresponding to the loop start event 1715 is stored again as in the fourth state 1710. At this time, the repetition counter is stored as accompanying information of the trace information 117.
Next, when the loop processing ends, trace information 117 indicating the loop end event 1720 is stored at the end of the buffer 116 as in the fifth state 1711.
Finally, as in the sixth state 1712, trace information 117 indicating the end event 1721 of the methodA method and the end event 1722 of the main method is stored.

  Further, regarding the buffer size, in the program 1701 of FIG. 17A, the total number of methods in the loop is 2, the buffer size necessary for acquiring the call information for one method is 2, and the loop start / end information. Is 2, the buffer size is 2 × 2 + 2 = 6. Therefore, the buffer usage amount 6 except the start event 1713 and 1722 of the main 1702 and the start event 1714 and the end event 1721 of the method A 1703 as in 1712 is the same. Note that the above example illustrates only a loop example, but even when there is recursion, the number of pieces of trace information 117 to be acquired can be calculated in the same manner as the loop example.

  In this way, conventionally, when an element that indicates repetition such as loop or recursion is included in the program, the number of trace information to be acquired depends on the number of iterations of loop or recursion. Could not be calculated. As a result, the buffer size necessary for storing the trace information could not be grasped in advance. However, in this embodiment, since the number of trace information acquired from a program including an element that indicates repetition such as loop or recursion as described above can be calculated, the buffer size for storing the trace information in advance Can also be calculated.

FIG. 18 shows an output example of the trace information 117. In the present embodiment, the trace information output unit 112 in FIG. 1 outputs the trace information 117 to the external storage device 118 as a file. 18 shows the output result of the trace information 117 obtained by executing the program 1701 shown in FIG. 17A, and each line 1 to 10 shows the trace information 117.
Trace information 1801 represents the start of the main method. A method_entry 1805 represents a method start event, and a main 1806 represents a target method of the method_entry 1805.
Trace information 1802 indicates that a loop with a loop ID of 1 has been started and that the loop has been repeatedly executed 100 times. For_loop_entry 1807 represents a loop start event, 1808 represents a loop ID, and 1809 represents a repeat counter.
The trace information 1803 indicates that methodB has ended, method_exit 1810 indicates a method end event, and methodB 1811 indicates a target method of method_exit 1810.
Trace information 1804 indicates that the loop with the loop ID 1 has been completed. For_loop_exit 1812 represents a loop end event, and 1813 represents a loop ID.

Finally, an example of how trace information can be acquired according to the present embodiment will be described. In the program execution of the computer 101, description will be made assuming that a failure occurs during loop execution. FIG. 19A shows a program 1901 as an example of the program 113 executed by the computer 101. FIG. 19B shows an output example of the trace information 117 when a failure occurs during loop execution.
It can be seen from the trace information 1903 that the for loop was repeated 10 times. Also, it can be seen from the trace information 1904 that methodC has been started. Therefore, it can be seen from the output example of the trace information 1902 that some failure has occurred in methodC during the tenth iteration of the for loop.
FIG. 19A shows an output example of the trace information 117 when a program 1901 including a loop is executed, but the same trace information 117 can be output in the case of recursion. Therefore, in the present embodiment, it is possible to leave sufficient trace information 117 for failure analysis even if the storage of the trace information 117 is omitted for loop / recursion.

[Second Embodiment]
Next, a second embodiment of a computer to which the present invention is applied will be described. The second embodiment is an embodiment in which a program component constituting a program execution path having a high user execution frequency is selected, and a buffer size is calculated based on the selected program component.
FIG. 20 shows the overall configuration of the computer in the second embodiment. A configuration different from FIG. 1 showing the overall configuration diagram of the first embodiment will be described below.

First, in this embodiment, functional units of an extended buffer size calculation unit 2001, a buffer reallocation unit 2002, and a user execution data totaling unit 2003 are newly provided on the Java virtual machine 104. In addition, execution history data 2004 and user execution data 2005 are stored on the memory 103.
The extended buffer size calculation unit 2001 extracts a program execution path with a high execution probability from the program component tree, and calculates the buffer size from the number of nodes belonging to the extracted program execution path. The buffer reallocation unit 2002 allocates When the buffer size is insufficient, the buffer is reallocated.
A user execution data totaling unit 2003 totals program execution history data 2004 for each user, and generates user execution data 2005.
The execution history data 2004 is data indicating the execution history of each node (program component) of the program component tree of all users.
The user execution data 2005 is data obtained by tabulating the execution history data 2004 for the number of times each node of the program component is executed for each user.
Note that the execution history data 2004 and the user execution data 2005 may be stored not in the memory 103 but in the external storage device 118.

FIG. 21B is an example of execution history data 2004 obtained by executing the program 2101 of FIG. 21A. The execution history data 2004 includes a user ID 2102, a node name 2103, and a time stamp 2104.
FIG. 22 is an example of user execution data 2005 generated from the execution history data 2004 of FIG. 21B. FIG. 22 shows user execution data 2005 of users whose user IDs are “1” and “2”. The user execution data 2005 includes the node name 2201 and the execution count 2202 indicating the total value of the execution count of each node. It consists of.

FIG. 23 shows an outline of processing in the second embodiment to which the present invention is applied. Note that the processing from S2301 to S2304 is the same as the processing from S201 to S204 shown in FIG.
First, in step S <b> 2305, the extended buffer size calculation unit 2001 reads the execution history data 2004 on the memory 103, and calculates the buffer size from the read execution history data 2004 and the static analysis data 115. Then, the buffer 116 having the calculated size is secured on the memory 103 (extended buffer size calculation process).
Next, in S2306, the program rewriting unit 109 executes program rewriting processing (program rewriting processing).
Next, in S2307, the program rewriting unit 109 executes program execution processing (program execution processing). Note that whether or not a failure has occurred in the trace information acquired at this time is confirmed.
Next, in S2308, the program rewriting unit 109 executes a trace acquisition process (trace information acquisition process). Note that S2306 to S2308 are the same processes as those in the first embodiment.
In step S <b> 2309, the buffer reallocation unit 2002 confirms whether the allocated buffer 116 is insufficient. If the allocated buffer 116 is insufficient (S2309: Yes), in S2310, the buffer reallocation unit 2002 performs buffer reallocation processing (buffer reallocation processing). The buffer reallocation process is a process in which the buffer reallocation unit 2002 replaces the buffer 116 on the memory 103 with a buffer 116 having a buffer size calculated based on the number of nodes in the program component tree. Then, after executing the buffer reallocation process, the process returns to S2307.
If the allocated buffer 116 is not insufficient (S2309: No), the trace information 117 is output in S2311, and a series of processing ends (trace information output processing).

  Hereinafter, a method for extracting a program execution path with high execution frequency from a tree of program components will be described. In this embodiment, the node execution count is assigned to each node of the program component tree, and the execution probability is obtained from the assigned execution count. Then, a program execution path composed of nodes having a high execution frequency is extracted based on the obtained execution probability. Since the difference in execution probability is often caused by a deviation in the branch direction in the conditional branch, the execution probability in the conditional branch is evaluated in this embodiment. The execution probability is obtained from “the number of executions of the child node of the conditional branch node ÷ the number of executions of the conditional branch node”.

FIG. 24 is a flowchart showing the flow of extended buffer size calculation processing performed by the extended buffer size calculator 2001. The extended buffer size calculation process obtains a buffer size based on the number of nodes in the program component tree and an efficient buffer size required for each user calculated from the execution history data 2004, and a buffer having the obtained buffer size 116 is secured on the memory 103.
First, the execution history data 2004 is read from the memory 103 in S2401.
Next, in S2402, the total number of nodes is acquired from the static analysis data 115.
In step S2403, the maximum buffer size is calculated based on the total number of nodes.

Next, in S2404, the buffer size based on the execution probability is calculated. In order to calculate the buffer size, the execution probability of each conditional branch node and its child node is calculated from the static analysis data 115 based on the user execution data 2005, and a program execution path having a high execution probability is extracted (buffer size based on execution probability). Calculation process). Then, the buffer size is calculated from the number of nodes belonging to the program execution path. In step S2404, the execution history data 2004 is aggregated for each user, and the execution probability of the program component is obtained using data corresponding to the currently executing user.
In step S2405, a buffer area having the calculated buffer size is secured on the memory 103, and the process ends.
Thus, in this embodiment, the optimal buffer size can be determined for each user by evaluating the execution probability with respect to the execution path of the program. Therefore, each user can use the memory according to the program to be executed.

FIG. 25 is a flowchart showing the flow of the buffer size calculation process (S2404 in FIG. 24) based on the execution probability performed by the extended buffer size calculation unit 2001. The buffer size calculation process based on the execution probability is performed by extracting the program execution path sequentially from the method node of the start method of the program component, following the nearest conditional branch node, and calculating the buffer size from the number of nodes belonging to the extracted program execution path. calculate.
First, in S2501, execution frequency data is assigned to each node of the program component tree in the static analysis data 115. The execution frequency data given here is the number of executions for the node to which the user execution data 2005 is given.
In step S2502, the starting point node of the program component tree is set as the current node.
In step S2503, it is confirmed whether there is an unevaluated conditional branch node. An unevaluated conditional branch node is a conditional branch node having a child node whose execution probability is not evaluated. If there is an unevaluated conditional branch node (S2503: Yes), the nearest conditional branch node traced from the current node is set as the current node in S2504. If there is no unevaluated conditional branch node (S2503: No), the process proceeds to S2506. However, the node to be evaluated is a node in the end direction of the program component tree as viewed from the current node.

In step S2505, the execution probability of the child node of the conditional branch node is calculated. In this embodiment, the execution probability of the child node is calculated by “the number of executions of the child node of the conditional branch node ÷ the number of executions of the conditional branch node”.
Next, in S2506, the execution probabilities are compared between the child nodes of the conditional branch node, and nodes with a low execution probability are excluded from the buffer size calculation targets. However, when comparing execution probabilities between child nodes, if the difference in execution probabilities is equal to or less than a threshold value, the child nodes may not be excluded. This threshold value may be set in advance to a predetermined value or specified by the user. Then, after S2506 ends, the process returns to S2503. However, it is assumed that the node excluded in S2506 is not an evaluation target in S2503.
Finally, in S2507, the number of nodes not excluded in the program component tree is obtained, the buffer size is calculated from the number of nodes, and the process is terminated. When there are a plurality of program execution paths, the buffer size is calculated based on the program execution path with the maximum number of nodes. The buffer size calculation method is the same as that in the first embodiment.

  FIG. 26A shows an example of an execution probability table for each node of the program 2101 shown in FIG. 21A and a display screen for setting a threshold value for a difference in execution probability used when selecting a node. The execution probability table for each node includes a node name 2601, a node execution count 2602, and a node execution probability 2603. Further, the threshold value of the difference between execution probabilities can be designated by the user at 2604. Here, an example is shown in which the execution probability difference threshold is set to 10%. This means that if the difference in execution probability between conditional branch nodes is 10% or more, the child nodes belonging to the conditional branch are excluded from the buffer size calculation targets.

FIG. 26B shows a program component tree selected based on the execution probability of each node shown in FIG. 26A.
First, the execution probability of the child node is evaluated for if_1 2606, which is the first conditional branch node of the program component tree. From the execution probability table of each node in FIG. 26A, it can be seen that the execution probability of methodB 2607 as a child node is 30%, and the execution probability of the conditional branch node of if_2 2609 is 70%. Therefore, since the difference in execution probability is 70% −30% = 40%, methodB 2607 and methodC 2608, which are nodes below methodB 2607, are excluded from the buffer size calculation targets. In FIG. 26A, the excluded nodes are drawn with dotted lines.

FIG. 27 is a flowchart showing an outline of the process of the buffer reallocation process (S2310 in FIG. 23) performed by the buffer reallocation unit 2002. In the buffer reassignment process, the buffer 116 secured by the extended buffer size calculation unit 2001 is reassigned to the buffer 116 up to the maximum buffer size. In this embodiment, the buffer reallocation process is performed on the assumption that the buffer size necessary for storing the trace information 117 obtained by executing the program 113 is insufficient for the secured buffer size. However, the present invention is not limited to this, and processing can be executed under arbitrary conditions such as when the user designates it.
First, in step S <b> 2701, the buffer 116 having the maximum buffer size calculated by the extended buffer size calculation unit 2001 is secured on the memory 103.
Next, in S2702, the trace information 117 stored in the existing buffer 116 (buffer having a buffer size calculated based on the execution history data 2004) is copied to the secured buffer 116.
In step S2703, the existing buffer 116 area is released, and the buffer reallocation process ends. With this process, even if the trace acquisition amount becomes larger than the buffer size due to the execution of a route with a low execution probability in the program, tracing can be performed without causing the omission of acquisition of the trace information 117. .

  In the present embodiment, it is assumed that an approximate required buffer size is calculated for each system user from the execution history data 2004. Then, it is assumed that the buffer 116 is reassigned to the buffer size calculated based on the number of nodes of the program component tree shown in the first embodiment under an arbitrary condition such as when the buffer 116 is insufficient. Therefore, the buffer 116 for storing the trace information 117 is used in combination with the buffer 116 having the buffer size calculated based on the execution history data 2004 and the buffer 116 having the buffer size calculated based on the number of nodes in the program component tree. Can be used more efficiently.

101 computer, 102 CPU, 103 memory, 104 Java virtual machine, 105 program reading unit, 106 static analysis data generating unit, 107 static analysis data reading unit,
108 buffer size calculator, 109 program rewrite unit, 110 program execution unit, 111 trace information acquisition unit, 112 trace information output unit, 113 program, 114 extended program, 115 static analysis data, 116 buffer, 117 trace information, 118 external Storage device, 2001 extended buffer size calculation unit, 2002 buffer reallocation unit, 2003 user execution data totaling unit, 2004 execution history data, 2005 user execution data

Claims (19)

A computer for calculating the number of trace information acquired by the tracer,
The computer has a control unit that identifies an element that controls a flow of a program, the control unit identifies the number of elements before execution of the program, and acquires the number based on the number of identified elements. A computer characterized in that the number of trace information to be calculated is calculated. The computer according to claim 1,
The control unit determines a size of a memory area for storing trace information based on the number of pieces of trace information to be acquired. The computer according to claim 2,
The control unit determines the size of the memory area for storing the trace information of the program to be executed according to the number of the specified elements and the size of the memory area necessary for storing the trace information for one element. A computer characterized by determining. The computer according to claim 3, wherein
When the specified element is an element that instructs the repetition of the process, the control unit deletes or overwrites the trace information acquired from the element that instructs the repetition of the process, and stores the trace information in a memory area. Calculator to do. The computer according to claim 1,
The computer is characterized in that the control unit generates a tree composed of elements that control the flow of the program and specifies the number of the elements. The computer according to claim 5, wherein
The control unit further manages, for each node, an execution frequency, which is a record of executing nodes constituting the tree, specifies a predetermined program execution path according to the execution frequency, and is included in the specified program execution path A computer that calculates the number of trace information to be acquired based on the number of nodes to be acquired. The computer according to claim 5, wherein
The control unit further manages, for each node, an execution frequency that is a record of executing each node constituting the tree, specifies a program execution path having a high execution frequency from the execution frequency, and sets the specified program execution path to the specified program execution path. A computer that calculates the number of trace information to be acquired based on the number of nodes included. The computer according to claim 6 or 7,
The control unit determines a size of a memory area for storing trace information based on the number of pieces of trace information to be acquired. A computer according to claim 8, wherein
When the size of the memory area for storing the trace information obtained by executing the program and executing the program is insufficient with the size of the determined memory area, the control unit, from the size of the determined memory area, The computer is changed to the size of the memory area up to the size of the memory area for storing the trace information calculated based on the number of all nodes included in the tree. A method for calculating the number of trace information acquired by a computer by a tracer,
The computer identifies an element that controls the flow of the program before the execution of the program,
A method of calculating the number of pieces of trace information to be acquired based on the specified number of elements. The method of claim 10, comprising:
It said computer based on the number of the acquired trace information, wherein the determining the size of a memory area for storing trace information. The method of claim 11, comprising:
The computer determines the size of the memory area for storing the trace information of the program to be executed according to the number of the specified elements and the size of the memory area necessary for storing the trace information for one element. A method characterized by determining. The method of claim 12, comprising:
When the specified element is an element that instructs repetition of processing, the computer deletes or overwrites trace information acquired from the element that indicates repetition, and stores the trace information in a memory area. The method of claim 10, comprising:
The computer generates a tree composed of elements that control the flow of the program and specifies the number of elements. A program for causing a computer to calculate the number of trace information acquired by the tracer,
In said computer, an element for controlling the flow of the trace target program is specified before the execution of the traced program, based on the number of the identified elements, characterized in that to calculate the number of trace information to be obtained program. The program according to claim 15,
A program for causing the computer to determine the size of a memory area for storing trace information based on the number of acquired trace information. The program according to claim 16, wherein
In said computer, said the number of identified elements, by the size of the memory area required to store the trace information of a single component of the element, a memory area for storing the trace information in the trace target program to the execution A program characterized by determining the size of a program. A program according to claim 17,
When the specified element is an element instructing repetition of processing, the computer causes the computer to delete or overwrite the trace information acquired from the element instructing repetition and store it in a memory area. . The program according to claim 15,
A program that causes the computer to generate a tree composed of elements that control the flow of the trace target program and to specify the number of the elements.

Images