Purity Analysis Kit v0.11

Copyright (c) 2006 - Alexandru Salcianu <salcianu@alum.mit.edu>
GNU General Public Licence

Table of Contents:

Warning: The purity analysis tool and this webpage are provided as-they-are, without any guarantee or legal responsibility on behalf of their authors.

A. Licence information

This purity analysis tool is released under the terms of the GNU General Public Licence (GNU GPL), available online from here. Please discontinue using this tool if you disagree with the GNU GPL. See Section I below to find out how you can obtain the source code.

B. Definition of Purity

This tool implements the combined pointer and purity analysis described in our VMCAI'05 paper. Our analysis considers a method pure if it does not mutate any object that existed before the method was invoked. This definition is identical to the one from JML. Notice that a method that is pure according to this definition may still create, mutate, and even return new objects. This definition is useful for the following purposes: (1) a pure method can safely be used in assertions and instrumentation code; (2) If a method does not mutate any pre-existent object, the invariants attached to those objects propagate over calls to that method. In addition, as a special case, our (and JML's) definition of purity allows a pure constructor to mutate fields of the this object. [ However, as explained in Section F. below, you may use the option --no-jml-constructor-purity to instruct the analysis to consider such constructors impure. ]

C. Download and Installation

The purity analysis kit is released by the jppa project hosted on SourceForge. The purity analysis kit consists of a .tgz archive file that you can download from here. It decompresses into a directory named purity-kit, containing the following files/subdirs:
  1. purity.jar - Contains the classes of the purity analysis, together with a significant part of the Flex compiler infrastructure. Click here if you want to find out how to access the Java sources.

  2. suppJars/ - Subdirectory with the two .jar libraries used by the implementation of the purity analysis: jpaul.jar and jutil.jar. These files are not really part of the purity analysis: they are provided here only for your convenience. You may also find them, together with their sources and Javadoc documentation, on the websites of the jpaul and the JUtil projects.

  3. stdLib/ - Subdirectory that contains the implementation of the Java standard library that Flex compiles/analyzes Java applications against.

    Clarification: the analyzed application consists of (1) the user code, and (2) the standard library from stdLib/. More precisely, the current tool analyzes only those parts of (1) and (2) that are transitively callable from the main method. Notice that the Java standard library from (2) may be different from the Java standard library used by your JVM.

    Currently, the tool uses the Java standard library as implemented by the GNU Classpath project. More specifically, stdLib/ contains the glibj.zip from GNU Classpath v0.08, and some .jars that reconcile GNU Classpath with the object layout used by our compiler. Not sure they are really necessary for the purity analyses, but better safe than sorry :)

  4. jolden/ - Subdirectory containing the Java Olden bechmarks. These applications are not part of the purity analysis: they are provided here only as testcases.

  5. COPYING - The GNU GPL Licence details.

  6. purity-test and flex-self-test - Two testing scripts.

  7. run-purity - A convenient launch-script that takes care of setting CLASSPATH to include all relevant jars. It also asks the JVM for a large heap space (please adjust the -Xmx flag from this script as you feel fit).

  8. README.html - The file you are reading right now.

D. Requirements

Software: JDK 1.5 (Java with generics). The purity tool has been tested on Linux (RedHat, Debian, Fedora Core 3) with the first 5 releases of SUN JDK 1.5.0 (_01 to _05). You should make sure that the CLASSPATH of your JVM contains the following files: purity.jar, suppJars/jutil.jar, and suppJars/jpaul.jar.

Hardware: a fast machine (recommended: P4 @ 3.2GHz or equivalent) with a lot of memory (recommended: 1Gb for medium benchmarks, at least 2Gb for more ambitious ones).

E. Testing

Once you have all files in place, it's a good idea to test right away whether you can successfully run the purity analysis. To do this, execute

cd purity-kit

The purity-test script should analyze two Java Olden benchmarks from jolden/. If everything goes fine, the script generates a very verbose output, full of progress indicators. At the end of the analysis of each application, the analysis prints a short statistic regarding the total number of pure methods. If you want to analyze all of the ten Java Olden benchmarks, execute

./purity-test all

purity-test creates a results/ subdirectory containing files with the analysis trace for each analyzed testcase.

If you want to do a really big test, then run


The flex-self-test script performs the purity analysis on the entire code reachable from the Flex top-level class harpoon.Main.SAMain (this includes the code of the analysis and much more).

F. Usage

Reminder: Before using the purity analysis, you should make sure that purity.jar, suppJars/jpaul.jar and suppJars/jutil.jar are on your JVM's CLASSPATH.

The entry point for the purity analysis is the method

public static void harpoon.Main.Purity.main(String[] args)

You may invoke this method in two ways: (1) programmatically (e.g., from another Java class); or (2) by starting your favorite JVM with the class harpoon.Main.Purity as main class.

The elements of the args array parameter correspond to the command line arguments. They should be, in order:

  1. args[0] - The name of the main class of the application you want to analyze.

  2. args[1] - The path where your application resides. As any Java CLASSPATH, this path can contain several elements (directors, .jar files, and .zip files), separated by ":". The path that the analysis uses in order to load analyzed classes consists of (in order):
    1 The user-defined path (i.e., the value of args[1]).
    2 stdLib/reflect-thunk.jar:
    Reimplement a few classes (e.g., reflection related ones), in order to "reconcile" GNU Classpath 0.08 with the object layout of our compiler.
    3 stdLib/glibj-0.08-extra-purity.jar:
    A few additions to GNU Classpath 0.08; required to analyze class files generated with JDK 1.5.0. GNU Classpath 0.08 implements the Java library up to 1.1, plus some parts of 1.2, but does not contain classes like java.lang.StringBuilder (introduced in JDK 1.5). Needless to say, these .jars does not fully upgrade GNU Classpath 0.08 to JDK 1.5; we provided only the classes that are required such that the analysis can analyze itself.
    4 stdLib/glibj-0.08-purity.zip The classes from the GNU Classpath 0.08 Java standard library, with some small changes to make them easier to analyze. These modifications concern the removal of caches from commonly-used library methods.

  3. The rest of the arguments are passed verbatim to harpoon.Main.SAMain.main(String[] args). Here are a few possible options you may use:

Warning: you can take a look at ./purity-test and ./flex-self-test, but they are far more complex than what you actually need. The reason for this complexity is that we also use them for testing while doing development in the Flex project, and the locations of certains elements are different than in the kit.

G. Programmatic Access to the Analysis Results

The purity analysis examines (almost) all methods that may be transitively callable from the main method of the application (i.e., the main method of the main class). After the analysis terminates, all detected pure methods are put in a set stored in a static field in the class harpoon.Analysis.PA2.Mutation.WPMutationAnalysisCompStage:

public static Set<HMethod> pureMethods;

[ We say "almost" because, for efficiency reasons, the analysis skips (i.e., considers unanalyzable) several large library methods, whose analysis takes a long time and does not seem to produce anything useful. Those methods deal with the SecurityManager and the time zones. Let us know if you really care about them: the analysis can analyze them, at the cost of a bigger analysis time. ]

Also, the analysis stores a map from each analyzed method to a list of the indices of the "read-only" parameters. A parameter is read-only if the method does not mutate any object transitively reachable from that parameter. The read-only information is unsound in general; it should be used only for program understanding and testing tasks. This map is stored in another static field of harpoon.Analysis.PA2.Mutation.WPMutationAnalysisCompStage:

public static Map<HMethod,List<Integer>> method2ReadOnlyParams;

The parameter indices start from 0 and take into account all parameters, including those of primitive types, and, in the case of instance methods, the implicit this argument (the first one, i.e., #0).

harpoon.ClassFile.HMethod is the Flex handle for a method from the analyzed code. Full Javadoc available on the Flex website, or directly through this URL.

H. Limitations / Thorny Issues

I. Getting the Source Code

The purity kit is part of the jppa project. To get the jppa sources, please read the jppa developer info. After you donwload the sources, the script Harpoon/Analysis/PA2/Mutation/make-purity-kit creates the purity kit.

Good luck!

Hosted by SourceForge.net Logo
Copyright (c) 2006 - Alexandru Salcianu <salcianu@alum.mit.edu>
GNU General Public Licence
File CVS version: $Id: PURITY-README.html,v 1.6 2006/08/15 23:52:14 salcianu Exp $