PASTA is a tool for automatic synthesis of object state transformers in dynamic software updates (DSU) of Java programs. Given a code change (both old and new versions) and a field to be updated, PASTA automatically gives a list of candidate object transformers.


PASTA Command Line Tools

We assume you’re at the pasta directory. Let PASTA_JAR be the generated target/pasta-[ver]-full.jar.

PASTA-distill

$ java -jar $PASTA_JAR distiller
usage: pasta distiller
 -h,--help      Print help messge
 -pc <arg>      XML config file of target program, containing source/byte
                code directory
 -u <arg>       The javelus.xml file that contains detailed update
                information
 -v,--verbose   Print verbose messages for debug

Two options are required by the distiller: -u points to the update description file (javelus.xml) and -pc points to the structure of the target program.

Option: -u

The javelus.xml file is generated by the dpg module, which will be built together with PASTA. To generate a javelus.xml file for an update, just execute:

bash ./modules/dpg/dist/run.sh \
    -o path/to/old/version/bytecode \
    -n path/to/new/version/bytecode \
    -d path/to/save/output -x

For detailed usage of dpg, just execute bash ./modules/dpg/dist/run.sh.

Option -pc

PASTA analyzes source code and compiled byte code to generate gadgets. To specify where to extract them, the -pc option points to the project configuration file (XML), whose structure is:

<dsu>
    <commitRoot>/directory/for/the/generated/results/</commitRoot>
    <old>
        <root>/directory/of/old/version/program/</root>
        <projectSourceDir>/classpath/of/old/version/source/code/</projectSourceDir>
        <projectByteDir>/classpath/of/old/version/byte/code/</projectByteDir>
        <testByteDir>/classpath/of/new/version/test/code/</testByteDir>
        <jarDirs>
            <dir>/directory/of/dependent/jar/files/</dir>
            ...
        </jarDirs>
    </old>
    <new>
        ...
        configuration for new version program.
        ...
    </new>
    <apiTypes>
        <type></type>
        ...
    </apiTypes>
<dsu>

The commitRoot points to the directory of the update, i.e., the old and new programs could be put in this directory. The old and new nodes contain the path to source code, compiled byte code, and directories of dependent Jar files. The update node depicts the target field in a changed class. The apiTypes node can be used by developers to specify some special types. PASTA will also extract gadgets from these apiTypes.

PASTA-synthesis

$ java -jar $PASTA_JAR synthesizer
usage: pasta synthesizer
 -h,--help      Print help messge
 -pc <arg>      XML config file of target program, containing source/byte
                code directory
 -u <arg>       The javelus.xml file that contains detailed update
                information
 -v,--verbose   Print verbose messages for debug

The javelus.xml file for -u option is same as distiller.

Option -pc

The -pc option is the same as the distiller. However, in order to synthesize transformers for a target field, the following configurations should also be put into the project config file.

<dsu>
    ...
    <update>
        <class>name.of.changed.class</class>
        <newField>
            <type>type.of.target.field</type>
            <name>name</name>
        </newField>
    </update>
    ...
</dsu>

PASTA-verify

PASTA is also shipped with a verifier for running unit tests against transformers. Strictly speaking, this is out of the scope of PASTA synthesis algorithm. However, we use this verifier in the experiments to filter out invalid transformers.

$ java -jar $PASTA_JAR verifier
usage: pasta verifier
 -h,--help                 Print help messge
 -jc <arg>                 XML config file of necessary jars, which can
                           also be specified by environment variables
 -m,--method <arg>         The code of transformer method that should be
                           verified. Inside the code, use _stale_ as the
                           stale object, and _object_ as the target field
                           to be tested
 -pc <arg>                 XML config file of target program, containing
                           source/byte code directory
 -tt,--testTimeout <arg>   Timeout in seconds for one test case execution.
                           Default is 60
 -v,--verbose              Print verbose messages for debug.

Option -m

Verifier tests the code of a transformer, which is specified via -m option. Check tutorial for transformer examples. In the code, the stale object should be named as _stale_ and the target field should be named as _object_.

Option -tt

Verifier needs to execute a test many times. Each execution will be guarded by the timeout. The default time to execute a test is 60 seconds. you can specify a value with -tt option.

Option -jc If PASTA is successfully built locally, a .library file should be generated in the pasta directory. Executing source .library is sufficient for running verifier inside the same terminal and -jc option is no longer required.

Also, an XML file can be used via -jc option. The structure of the file is:

<dsu>
    <junitJar>/path/to/junit/jar/file</junitJar>
    <hamcrestJar>/path/to/hamcrest/core/jar/file</hamcrestJar>
    <xstreamJar>/path/to/xstream/jar/file</xstreamJar>
    <xstreamLibs>/directory/to/xstream/dependent/jar/files</xstreamLibs>
    <agentJar>/path/to/agent/jar/file</agentJar>
    <verifyJar>/path/to/pasta/full/jar</verifyJar>
</dsu>

If build successfully, the junit and hamcrest Jar files can be found in ./target/lib. The xstream and agent can be found in ./modules.

Option -pc

The -pc option is the same as distiller and synthesizer. Developers should specify which test cases should be used in verifier.

<dsu>
    ...
    <usefulTestFile>/file/contains/test/names/</usefulTestFile>
    <testRoot>/classpath/of/extra/tests/</testRoot>
    ...
</dsu>

Name of each test in the usefulTestFile is like full.class.name+testMethod. Verifier will ignore other test methods and only execute testMethod inside the test class. Verifier will load test cases from the new version program. Developers can also prepare their own test cases. The testRoot is the classpath points to those compiled tests.


PASTA is an open-source software published under GPLv3.