The User Interface Module renders a graphical user interface (GUI) that contains one dialog component for phase one (offline analysis) and two dialog components for phase two (online monitoring). The following subsections describe these dialogs and demonstrate how to use the agent to investigate our sample program MyProgram via these dialogs.
4.2.1 Phase One Dialog Component
Figure 4.3 shows the dialog of phase one (offline analysis). During phase one, the agent generates and analyzes the heap snapshot of the investigated program. In our case, a JVM process, in which a Java program runs, is investigated.
Figure 4.4: Heap snapshot of our sample program MyProgram
Since there may be numerous JVM processes executing concurrently, the user has to select a JVM process to monitor. When the user clicks the “Get All JVMs’ PID” button (Figure 4.3 ..1 ), a list of currently running JVMs, including their process IDs (PIDs) and names, is then shown in Figure 4.3 ..2 . The user may select a specific JVM (e.g., MyProgram) and its PID will be shown in the “Selected JVM” textbox (PID 2031 in Figure 4.3 ..3 ).
When the user clicks the “Analyze Selected JVM’s Heap Snapshot” button (Figure 4.3 4 ), the agent starts to generate a heap snapshot for the selected program and analyzes..
it. Heap snapshot generation and analysis can take quite a while, and the overall progress will be reported by the progress bar below (Figure 4.3 ..5 ). Details of heap snapshot generation and analysis will be given in Subsection 4.3.1 and Subsection 4.3.2.
Figure 4.4 is an object diagram of the generated heap snapshot of our sample program MyProgram, described by the UML. Its content is the same as Figure 3.1 described in Section 3.1. The agent then analyzes this heap snapshot and converts it to a dominator tree, whose structure is shown in Figure 4.5. This dominator tree information is displayed by the GUI in a tree-style checklist (Figure 4.3 ..6 ), from which the user can select the object instances to be monitored in phase two. To help users in choosing object instances
Figure 4.5: The dominator tree converted from the heap snapshot shown in Figure 4.4 to monitor, the agent calculates the total occupied bytes of each dominator tree node, and illustrates it in Figure 4.3 ..6 . In the checklist, each entry represents a dominator tree node, displaying the class name of its object instance, the total occupied bytes, and the percentage of its total occupied bytes versus the sum of all nodes’ total occupied bytes on the same level in the same subtree. At first only nodes on the first tree level are shown.
The minus symbol (-) in front of a checklist entry indicates that the entry is a leaf node and is not expandable. By clicking the plus symbol (+) in front of a checklist entry, the user can expand and examine the entry’s subtree.
With the occupied bytes information, the user can determine object instances that are potential leaks. In our sample, MyDblLinkedList takes up 92% of the heap space, which seems suspicious. Therefore the user selects its child node MyListItem and its grandchild node String, and clicks the “Output Selected Object Instances” button (Figure 4.3 ..7 ).
The agent then converts the hierarchical information of selected entries to reference rules (definition of reference rule is described in Section 3.2), and outputs them to a text file.
This output file will be used in phase two.
Figure 4.6: Home dialog of phase two (online monitoring)
4.2.2 Phase Two Dialog Components
Figure 4.6 shows the home dialog of phase two (online monitoring). Through this dialog, the user specifies the object instances he or she wants to monitor by importing the output file of Phase One Dialog, and selects a JVM to start online monitoring.
The user first locates the output file of Phase One Dialog (Figure 4.6 ..1 ), and clicks the “Import” button (Figure 4.6 ..2 ). The content of the file is listed in the “Object Instances to Monitor:” textbox below (Figure 4.6 ..3 ).
To select a specific running JVM, the user clicks the “Get All JVMs’ PID” button (Figure 4.6 ..4 ). A list of currently running JVMs, including their PIDs and names, is then shown below, which can be selected by the user (Figure 4.6 ..5 ). The PID of the selected entry is shown in the “Selected JVM” textbox (Figure 4.6 ..6 ). In our example, program MyProgram with PID 4045 is selected.
Figure 4.7: Report dialog of phase two (online monitoring)
When the user clicks the “Start Monitoring Selected JVM” button (Figure 4.6 ..7 ), the home dialog is closed and the second dialog (Figure 4.7) pops out, indicating that the agent starts online monitoring the chosen JVM process.
The user can click the “Show Current Monitoring Report” button (Figure 4.7 ..1 ) at any time to examine the current monitoring report. At the same time, the user can request the agent to report only those object instances not being accessed within a specific day range (Figure 4.7 ..2 ). After the user clicks the “Show Current Monitoring Report”
button, a report is generated by the Reporter Component as shown below in Figure 4.7 4 . This process might take a while and the progress is reported by the progress bar..
(Figure 4.7 ..3 ).
Figure 4.7 ..4 displays a summary table for the status of the reported object instances.
The columns of this table are explained below.
Reference Path: the reference path of the monitored object instances. (Figure 4.7 ..a ) Instance Count: the number of monitored object instances with the same reference
path. (Figure 4.7 ..b )
Last Accessed Time: the last accessed times (i.e., longest, median and most recent) of monitored object instances with the same reference path (Figure 4.7 ..c ). The object instance corresponding with the maximum (longest) time value is intuitively considered the most potential to be a leak. In addition, median and minimum (most recent) time values are also listed for user reference.
Last Accessed Location: the last accessed location (including the file name and the line number) of the object instance with the maximum (longest) last accessed time (Figure 4.7 ..d ). This column helps the user identify the potential leak in the source code.
The user can click the “Show Current Monitoring Report” button (Figure 4.7 ..1 ) at any time to refresh the report.