Home Products Consulting Industries News About IBM

Mutability and Accessibility Analysis

We want to identify which fields in classes can be altered. Some applications of mutability analysis focus on instance fields; others focus on class (static) fields. Sometimes we are interested in which fields actually change; others times on the fields could be changed. The approach is essentially the same for all cases. During invocation graph construction and data flow analysis we record all the (types) values stored in all fields and all the places store operations are performed. Thus, we can identify which fields have been changed (e.g., which instruction in a specific method).  Using this definition, however, the general question is usually uninteresting -- almost all fields have something stored in them at some point. The more interesting and meaningful questions arise when one asks which fields are mutated in specific parts of the call graph.  For example, we usually want to know which fields were mutated after the object containing them was constructed.

Our notion of mutability includes both value mutability and state mutability. Value mutability is what we described above; the value in a field is modified. State mutability includes the possibility that a field in an object referenced by another field may have changed. By this definition, even fields marked final can be mutable since an object within the closure of the object referenced by the final field may be mutated.  A simple example of this is a field which is declared final that references an array of int.  While the referenced array can not be changed, each of the elements of the array can be modified.  Thus, we say that the field is state mutable.

The extension of mutability from the case where a field is mutated to the case where a field can be mutated is handled by using all accessible methods as root nodes in the invocation graph and data flow analysis. From the resulting graph, we can answer the more general question of which fields can be mutated.  To answer the question of whether a field can be mutated we also must answer questions about the accessibility of methods and fields.  In particular, even if there are no store operations to a field, it is possible that the field could be mutated by code a user may write becuase the user can gain access to the field. Thus, a field is said to be mutable if it is accessible and if its declared type is mutable. A field is accessible if it is declared accessible. In Java, this includes public fields, default scope fields in packages which are not sealed, and protected fields in classes which are not final. There are addtional accessability rules.  A class is mutable if any of the instance fields in that class are mutable.

A paper describing mutability analysis can be found here.

An example of the output from our mutability analysis tool can be found here.  It works best with IE 5.0 or later.  The report links to the source code for the example.  The links that begin with L# are links to the line where the problem (e.g., a store operation) is located.  Links that begin with M# are links to roughly the beginning of the method in which the problem is located.  Links that begin with TF reference parts of the report that describe problems with instances (e.g., specific object allocation sites).  (Note that the frames on the left side are not currently active, so they can be ignored.)

The analysis described here is based on our control flow and data flow analysis work.  You can return to our home page.

Privacy

Legal

Contact