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.
- Research Paper: “Synthesizing object state transformers for dynamic software updates” (ICSE’21)
- Research artifact
- Running PASTA
PASTA Command Line Tools
We assume you’re at the
pasta directory. Let
PASTA_JAR be the generated
$ 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 (
-pc points to the structure of the target program.
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
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>
commitRoot points to the directory of the update, i.e., the old and new programs could be put in this directory. The
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
$ 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
javelus.xml file for
-u option is same as distiller.
-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 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.
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
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
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.
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
The xstream and agent can be found in
-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.