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
- Requirements: standard JDK, ant, and maven
- Download and install: simply clone and make
- Running PASTA
- Tutorial: try PASTA on a class update now!
- Docker image: all experimental subjects in a package, push-button to run
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.