| || ||
JavaSlicer is an open-source dynamic slicing tool developed at Saarland University.
It is licensed under GPLv3.
JavaSlicer can be used to produce traces of Java program executions, and then offline computing dynamic backward slices on them.
It is organized in several modules:
The downloadable archives and the SVN contain a USAGE.txt file which describes how to use the respective command-line tools.
If you plan to extend JavaSlicer, or to integrate it into your own tool, e.g. by postprocessing the slicer's output or reusing the dynamic dependence graph, you should start exploring JavaSlicer's API from the existing main-methods, mainly Slicer.main.
This is the java agent which produces a trace file of a java program execution.
The trace file contains the bytecode representations of all loaded classes, as well as all information to reconstruct the execution trace for each thread.
Contains all classes needed to open and process a trace file. It provides forward and backward iterators over the execution trace.
This is the core of the slicing component.
It uses the TraceReader component to process a trace file and computes all dynamic dependences inside this run.
The slicer itself is built on top of that. It accumulates the dynamic dependences to compute the dynamic backward slice.
Includes classes used from several other components.
This component was created on demand.
It creates a JUNG graph of the dynamic dependences, with the option to visualize it.
Unfortunately, this only works for very (very!) small graphs, because of the poor layouting algorithms shipped with JUNG.
Currently JavaSlicer still has some limitations, which may or may not be lifted in the future.
- Tracing of native methods.
This is a drawback of using a java agent and will most probably never get fixed.
Instrumenting native methods loaded from shared libraries is far more complex that instrumenting java bytecode.
This drawback also affects many method in the Standard Library, like for example System.arraycopy and large parts of the java.util.concurrent.atomic package.
- Tracing of some Standard Library classes.
Unfortunately, some of the integral classes of Java have to be excluded from instrumentation, hence they are not traced.
This includes the classes java.lang.String, java.lang.System, java.lang.Object and others.
The consequence is that the dependencies through method calls in these classes can not be reconstructed, leading to incomplete slices.
It is theoretically possible to circumvent most of the problems arising when instrumenting these classes, so this may get fixes in the future.
- Tracing of multithreaded applications.
At the moment, each thread is traced separately, so data dependencies between different threads can not be reconstructed.
This also means that the finalize method will most probably not be contained in the trace, since (at least in some JVMs) the finalizer is executed in its own thread.
Please report bugs via Mail directly to Clemens Hammacher (contact below).
Please download JavaSlicer from the GIT repository on GitHub.
JavaSlicer depends on the sequitur implementation which is also available on GitHub.
For more hints about installation and usage, please take notice of the README file included in the JavaSlicer repository.
If you encounter any bugs, or implement extensions to JavaSlicer which might also be useful for other users, please consider opening a pull request on GitHub.
Since JavaSlicer has started in the context of
Clemens Hammacher's bachelor's thesis, this is the document
describing most of the internals of JavaSlicer.
An own publication making use of JavaSlicer was published at the IWMSE 2009:
Also, David Schuler used JavaSlicer for computing checked coverage:
Below you can find links to the people working on JavaSlicer.
Please contact Clemens Hammacher for questions.
Impressum ● Datenschutzerklärung
<firstname.lastname@example.org> · http://www.st.cs.uni-saarland.de//javaslicer/ · Stand: 2018-04-05 13:41