I just uploaded a new Technical Report. The report (currently under submission) describes a novel typestate analysis, called Nop-Shadows Analysis,  that I implemented for my doctoral dissertation. The analysis is certainly one of my dissertation’s major technical contributions. I implemented the Nop-Shadows Analysis in the Clara framework, which means that you are welcome to download it, try it out or extend it.

Continuation-equivalent states

So what are these continuation-equivalent states that appear in the title? We say that two automaton states s1 and s2 are continuation-equivalent if, given the current code location and all possible continuations of the execution after this location we either will or won’t reach a violating typestate regardless of whether we are in s1 or s2. Maybe an example is in order… (taken from the paper)

Assume that we want to evaluate the “ConnectionClosed” property that is depicted by the state machine on the right. The property says that it is an error to write to a closed Connection (where connections can alternate between an “connected” and a “closed” state through “close” and “reconnect” operations. Next, assume that we want to statically evaluate this property on the following simple program…

The figure on the right shows a program that is annotated with the analysis information that the Nop-Shadows Analysis computes. The example program violates the connection property by closing the connection (even twice, at lines 5 and 6), and then writing to the connection (line 7). Note, though, that all other statements in this program are irrelevant to the property violation. In particular, one does not need to monitor the “close” and “reconnect” operations at lines 3 and 4 because they precede the violating fragment of the run. Conversely, the operations at lines 8 to 10 follow this fragment, and hence do not need to be monitored either. A little more subtle, even of the the two“close” events at lines 5 and 6, it is correct to omit monitoring one of them. (But not
both!) The static analysis that we present in the paper will eliminate the instrumentation at exactly those shadows that we just identified as irrelevant—“nop shadows”, as we call them. Instrumentation will only remain in lines 5 and 7, or 6 and 7—an optimal result for this program.

The Nop-Shadow Analysis uses a deterministic finite-state machines for the mirror language of the original automaton’s language (see Figure 4b) to construct for every statement a partitioning of automaton states. States that are in the same class of the partition are continuation-equivalent. For instance, at line 3, which transitions from state 0 to 1, states {0,1,2} are all continuation-equivalent. Therefore there is no need to monitor the transition at this line – the transition is irrelevant!

Results

The analysis has several nice properties. Firstly, it is relatively efficient, and it is precise (see Figure). Also, it seems to be the first analysis of its kind (a flow-sensitive typestate analysis generating residual runtime monitors) that is sound. Unfortunately, we found an unsoundness problem in two analyses that we and others published earlier. The paper describes this problem in the related-work section. For my dissertation, I proved the novel Nop-Shadows Analysis sound, which was relatively easy because the analysis follows a relatively simple design.

Typestate properties aid program understanding, and one can even define type systems that prevent programmers from causing typestate errors, or derive static typestate analyses that try to determine whether a given program violates typestate properties. Unfortunately, the typestate-analysis problem is generally undecidable. Researchers have therefore proposed a hybrid approach that uses
static-analysis results to generate a residual runtime monitor. This monitor captures actual property violations as they occur, but only updates its internal state at relevant statements, as determined through static analysis.

Clara allows researchers to implement such hybrid typestate analyses with a minimal amount of code.

For Researchers, Clara offers:

• a convenient specification format for typestate properties, called Dependency State Machines,
• an extensible framework to implement static typestate analyses quickly and with high quality,
• automatic support for generating residual runtime monitors, even for collaborative runtime verification, and
• a platform to share specifications and compare analysis results.

For Developers, Clara offers:

• tool support to precisely define the behavioral interface of an application,
• tool support to check whether client code fulfills these specifications, and if not
• the possibility to have a residual runtime monitor that deals with property violations just-in-time.

We wish to extend Clara in the future. Please join our mailing list if you want to stay tuned on further developments. Or, if you even feel like extending Clara with your own analyses, download the tool and, if you feel like it, drop us a line.

Details about the Clara framework

Clara’s major design goal is to de-couple the code-generation for efficient runtime monitors from the static analyses that convert these monitors into faster, residual monitors. The figure to the right gives an overview of Clara. With Clara, the researcher first defines a set of typestate properties, denoting each property as an annotation to an AspectJ aspect that implements a runtime monitor for the same property. Annotations directly encode a non-deterministic finite-state machine. In my dissertation, I show how researchers can even use runtime- monitoring approaches like tracematches, JavaMOP, and others, to generate these annotated aspects automatically from high-level monitor specifications.

Clara weaves the monitoring aspect into the program under test and emits helper classes that implement the run- time monitor as defined by the aspect. Clara extends the  AspectBench Compiler for this purpose. Clara then invokes its static-typestate-analysis engine. Researchers can add a number of static analyses to Clara and have them applied in any order. These analyses obtain, through the finite-state machine defined in the aspect’s annotation, enough in- formation about the typestate property to precisely approximate the set of relevant instrumentation points. When an analysis determines that an instrumentation point is irrelevant to a property, i.e., the program can neither violate the property nor prevent a property violation at this point, then Clara automatically disables the instrumentation for this property at this point. The result is an optimized instrumented program that updates the runtime monitor only at program points at which instrumentation remains enabled.

Clara originated as Eric Bodden‘s doctoral-thesis project at the Sable Research Group. The design and implementation of Clara was greatly influenced by the work of this group and the Programming Tools Group at the University of Oxford, specifically Laurie Hendren, Patrick Lam, Oege de Moor, Pavel Avgustinov and Julian Tibble. Clara uses technogies from the AspectBench Compiler, Soot, JastAdd, polyglot and other open-source projects.