The Fox – A Tool for Java Object Graph Analysis

1. The Fox – A Tool for Java Object Graph Analysis 8. Results: Examining a Single Program (ArgoUML). Lets take a popular Java program, Argo-UML, and look at the percentage of aliased objects, distribution of kinds of confinement, and the percentage of strings as it runs. Time as ArgoUML Runs The Queries: QPercentage("FStringProperty("PConfinement", "STRONG", FSnapshot())"); QPercentage("FStringProperty("PConfinement", "WEAK", FSnapshot())"); QPercentage("FStringProperty("PConfinement", "NONE", FSnapshot())"); QPercentage("FStringProperty("PClassName", "java.lang.String", FSnapshot())"); From these measurements we can observe the increasing number of aliased objects inside the program as it runs. This can mean that the program becomes more and more susceptible to the aliasing-related errors and defects…  9. Results: Many Programs, Same Story (CorpusAnalysis). Although Fox is useful when it comes to a detailed analysis of a particular program, we also applied it to the study of various aspects of object graphs across a large number of programs. We measured 52 heap snapshots of a corpus of over 30 programs, from test programs to larger systems with over 350, 000 objects. We found that only around twelve percent of objects (ranging from 5 - 25 percent had more than one incoming reference; that objects were on average five layers deep within an object ownership hierarchy; and that around one third of all objects were strongly confined according to our instantaneous confinement definition. Object confinement is related to the concept of a Java package. Every class in Java has to belong to some named package, thus we called a class confined if no instances of the class are referred to by the instances of classes in a different package. The confinement distribution across the snapshots in the corpus is shown and represents those objects that have no referrers from outside the package (NONE), no referrers outside the “top level” package (WEAK), and no referrers outside the defining package (STRONG). The concept of confinement is a lot more general than this description, please refer to “Confined Types” paper by Bokowski and Vitek for more information. 10. Results:Power Laws Apply to Object Graphs. The Power Law or Zipf’s Law was first observed by George Kingsley Zipf, a Harvard linguistics professor, in his study of the frequency of the words in English text. He observed that in the distribution of words in any given novel: the nth most common word occurs about 1/n times as frequently as the most common word. Finally, it would be interesting to look at whether there are any objects that have both a large number of incoming and outgoing references. With the help of Microsoft Excel, Matlab, and QProperties query, we were able to plot the heat map representing the distribution of the number of objects having a particular number of incoming and outgoing references. The figures above have darker colours where the number of objects is smaller. We can see that no objects have a large number of both incoming and outgoing references, rather both tend to stay close to axis. To show that in a given program, the distribution of incoming or outgoing references follows a power law, we need to sort the objects in the order of the frequency of a particular number of references occurring. Then we need to plot on the log-log scale the frequency rank of the number of references occurrence versus the number of objects having such a rank to see if the resulting graph will form a line. We can clearly observe that even though in the graphs above all the plots have a different number of objects inside the memory graph, the plots all lie on a line. Hence, we can conclude that the distributions of incoming and outgoing references conform to the Power Law. 11. Acknowledgements and Future Work. Questions? Ask Alex. Supervisors of my Honours Project: Various helpful graduate students: In the future, we plan to concentrate on exploration of different interesting properties of ownership, and other aliasing related measurements. This work should help us improve and develop further the query language. We have two different ways to go from where we are now: we can either extend FQL and make its syntax nicer and more compatible with OCL, or we can decide to switch to storing our heap snapshots in a database and only delegate Fox to do the conversion for us, while writing all the queries using standard SQL. Stuart NB! Thanks to Sylvia Lutnes for the image of the Fox: The Cricket Cage (http://www.thecricketcage.com/) Special thanks goes to the Royal Society of New Zealand Marsden Fund for supporting some of our work James Noble Robert Biddle Myself, Dan, Rilla, and Pippin Craig 1. The Problem. 5. Where did the Fox come from? • We wanted to find a tool that would allow us to examine ownership and confinement properties of object graphs. • Found a large number of ownership tree visualisation tools but no ownership measurement tools at the time (early in 2002). • Wrote our own tool, called Rabbit, that examined static snapshots of memory graphs and produced required ownership and confinement metrics. • Found cumbersome to implement new experiments in Rabbit, which had to be done from scratch in Java, and to have to recompile a whole program for every small adjustment introduced. • After looking at the related work in query-based-debugging we came up with the current version of the tool, called Fox, that is a lot more extensible and flexible. Object-oriented programs, when executed, produce a complex web of objects. The result-ing object graph can provide an insight into the real behaviour of a given program. The Fox tool allows analysis of memory snapshots of any running Java program using a query language. We describe its architecture, query language design, and several studies that directly utilised the tool to study aliasing, ownership, and more. Trivia: We came across the Heap Analysis Tool (HAT) by Bill Foote and produced the first version of our 2. What is an Object Graph? program that came out of it: Rabbit. An object graph – the object instances in a pro-gram and the links between them – is the skeleton of an object-oriented program. Because each node in the graph represents an object, the graph grows and changes as the program runs: it contains just a few objects when the program is started, gains more objects as they are created, and loses objects when they are no longer required. The Fox ca-me after the Rabbit...  The figure above illustrates the object graph of a simple part of a program – in this case, a doubly linked list of Student objects. The list itself is represented by the LinkedList object (an instance of the LinkedList class, presumably), which has two references to Link objects representing the head and tail of the list. Each Link object has two references to other Link objects – the previous and the next Links in the list, and a third reference to one of the Student objects contained in the list. Although some objects (such as the Student “Alice”) are accessed uniquely by only a single reference, the overall structure is clearly a general directed graph with many cycles, rather than a tree or a directed acyclic graph. 6. About the Fox Query-Based Debugger. In Java, all the objects created by the program are allocated inside the heap, even though they can be pointed at by the local variables inside the stack. Thus, it is sufficient to analyse the heap snapshot to cover all the objects present inside the memory of a running Java program. The Fox (on the left) is written in Java and it works with heap snapshots produced using the Heap Profiler (HPROF) which comes as part of the Sun’s JDK 1.2 or higher and utilises the Java Virtual Machine Debugger Interface (JVMDI). After loading the heap snapshot using the Heap Analysis Tool (HAT) it constructs the ownership tree and constructs an easily accessible and compact data structure representing all the objects inside the heap. The results produced by the Fox can be further analysed using such programs as MS Excel and GNUmeric. The architecture of the Fox is depicted below. 3. What’s up with aliasing? Aliasing occurs when there is more than one pointer referencing an object. This causes the identity of the object to be compromised because one referrer can change the state of the object without others knowing about it. The author is ready to discuss the internal workings in more detail based on the class diagram on the left. Those who want more information about how the Fox works, we would like to refer to the Fox’s web site on: http://www.mcs.vuw.ac.nz/~alex/fox/ Pictured to the left is a simple case of aliasing. Say we have an object with elements inside it, if we add an element, it can still have an alias from the outside that may change its internal value thus affecting the whole container object (e.g. d on the left changing the state of a via k). a d Trivia: Aliasing, although widely used term in OO community, is in fact not a valid English word. Neither Oxford nor Webster’s dictionaries have a definition for it. size contents i j k 7. The Fox Query Language. For a simple case of a hashtable with students, having an alias to student that can change its hash code may cause the student object to disappear from the container (it can no longer find it). We maintain the abstract-ion of view-ing the heap as a large da-tabase table with each row contain-ing informa-tion about a single object and each co- Object Graphs in Some Program as Time Goes By A Snapshot is Taken 6 Objects passing the filter. 8 Each object shows its depth from root value. 5 7 6 1 6 1 3 5 2 4. What are Ownership Trees? FIntegerProperty(“PDepthFromRoot”, < 4, Fsnapshot()) 1 1 3 An object a owns another object b if all the paths from the root r to the object b go through a. In this case b is called the owner of a. The implication of ownership is that no object outside the owner b is allowed to have a reference to a. We posit a global root r through which all the objects in the root set of the current heap snapshot can be accessed. Ownership allows us to structure an object graph into an implicit ownership tree. 2 lumn being a particular property an object might have. We use filters and their com-binations to select a particular subset of objects that we want to analyse using one of the queries. The properties for each object are calculated as the heap snapshot is being loaded by Fox. The queries range from simple queries like average and count, to complex visualisation queries. QAverage ( filter, “PNumberOfOutgoingReferences”) Averaged 0.5 across the objects passing the filter.