You can clone it from:
I believe JavaMOP 3.0 works as well, but I'll assume 4.0. You can clone it from:
However, I have not tested the code in this repository. I've been using one in the Google Code repository:
svn checkout http://javamop.googlecode.com/svn/trunk/ javamop-read-only
It would be great if someone checks whether the github version works.
You can clone the repository from the Google Code page:
In the properties/ directory, you should be able to see JavaMOP specifications. Throughout this document, I'll call this properties/ directory as $JAVAMOPSPEC_DIR.
The modified AspectJ
The original AspectJ will fail to weave fop of DaCapo 9.12 with the 179 specifications. You will get the following error message, something like "code size too big". To avoid this error, I modified the AspectJ compiler. For more details, refer to the Appendix of Choonghwan Lee's thesis.
You can clone this from my repository hosted on fslwork:
git clone ssh://[your-id]@fslwork.cs.illinois.edu/home/clee83/repository/aspectj
You should be able to build it using ant. During the compiltation, an error like "property 'local-properties' not at ..." may occur. You should create local.properties under build/, and you can simply copy from build/sample.local.properties. If the build procedure is successful, you will be able to see the following directory:
This directory contains all the important files:
- aspectjtools.jar: the AspectJ compiler
- aspectjweaver.jar: the load-time weaver (LTW)
- aspectjrt.jar: runtime
All of these files can be useful, but, for the purpose of generating a JavaMOP-Agent, only the LTW and runtime are necessary. Throughout this document, I'll call this lib/ directory as $ASPECTJ_DIR.
It turned out that I automated the procedure that will be explained in the "Manual Procedure" section.
It's part of a pretty complicated C# program, which is written for running the DaCapo 9.12 and others. This program is quite complicated because it does many things:
- runs DaCapo 9.12 under both UNIX and Windows
- relives some problems in JavaMOP 2.3
- supports various settings
- supports resuming; i.e., one can stop the execution and resume later
- supports both performance measurement and violation collection (with call-site counting)
In short, it won't be very readable. Nevertheless, if you are adventurous and you want to see more formal procedure (i.e., methods and classes), you can get the source from my repository hosted on fslwork:
git clone ssh://[your-id]@fslwork.cs.illinois.edu/home/clee83/repository/javamop
The corresponding class is CreateAspectJAgentPlugin.
- Input: JavaMOP specifications in $JAVAMOPSPEC_DIR
- Output: RV-Monitor specifications in $RVSPEC_DIR
- Output: $ASPECT_FILE: an Aspect file in $RVSPEC_DIR
You may run JavaMOP any way that pleases you, but do not forget the -translate2RV option. I typically run as follows:
javamop -d $RVSPEC_DIR -dacapo -silent -translate2RV -n all -merge <path-to-spec1> <path-to-spec2> ... <path-to-specn>
This will generate the output files in $RVSPEC_DIR.
Both the -dacapo and -silent options are what JavaMOP 3.0 has without any explanation. They have something to do with suppressing log messages, but I'm not sure if they are effective under JavaMOP 4.0. (Qingzhou, could you shed some light on this?)
Here, <path-to-spec1> ... <path-to-specn>, where n = 179 for a thorough test, should be provided. Under UNIX systems, I guess a wildcard may work, although I have not tried.
Note: if you are running under Windows, you cannot use a wildcard. When you provide a list of full paths, you should make sure that the entire command is no longer than a certain limit, imposed by cmd.exe. You may avoid this using Powershell. I used a C# program that directly spawn a process; this is similar to calling one of exec(2) family of POSIX.
- Input: RV-Monitor specifications in $RVSPEC_DIR
- Output: $MONITORJAVA_FILE: a Java file that implements the monitoring functionality in $MONITOR_DIR
I typically run RV-Monitor as follows:
rvmonitor -d $MONITOR_DIR -dacapo -silent -n all -merge <path-to-spec1> ... <path-to-specn>
This will generate a single Java file in $MONITOR_DIR. This file implements the interface for firing events, and some data structures, such as monitors and monitor sets.
Here, specifications are, of course, RV-Monitor specifications, generated by JavaMOP.
Compile the generated Java file
- Input: $MONITORJAVA_FILE
- Output: $MONITORLIB_FILES: many .class files
You can use javac. When you compile this, you should provide the path to the RV-Monitor runtime (rvmonitorrt.jar).
Due to Java's strict rule, there will be many files, one for each class. I'll refer to all of them as $MONITORLIB_FILES.
Compile the generated Aspect file
- Input: $ASPECT_FILE
- Input: $BASEASPECT_FILE
- Output: $AOPAJC_FILE: an XML file
- Output: $COMPILEDASPECT_FILE
You can run the AspectJ compiler without a program, as follows:
ajc -1.6 -outxml $BASEASPECT_FILE $ASPECT_FILE
Then, ajc will generate two output files.
It is recommended to edit $AOPAJC_FILE. Right after the <aspects> tag, add the following:
<weaver options="-nowarn -Xlint:ignore"></weaver>
This will suppress less useful warning messages.
Create a Java Agent
- Output: $JAVAMOPAGENT_FILE
The goal of this procedure is to create a single .jar file, which is qualified as a Java agent. You can simply view this procedure as merging all the necessary files into one .jar file.
Prepare a working directory
We will start from AspectJ's LTW, and then add necessary things below.
- Unzip aspectjweaver.jar in $ASPECTJ_DIR into $AGENT_DIR
Copy specification-specific files
- Place $AOPAJC_FILE$ in $AGENT_DIR/META-INF/
- Place $COMPILEDASPECT_FILE in $AGENT_DIR/mop/
- Place $MONITORLIB_FILES in $AGENT_DIR/mop/
The last two operations assume that the specification is defined in the "mop" package, which is the case at the time of writing this.
Copy RV-Monitor runtime
- Unzip rvmonitorrt.jar
- Copy recursively com/ to $AGENT_DIR/com/
Zip the directory
Now, you can create .jar file from $AGENT_DIR. I issue the following command:
jar cmf $AGENT_DIR/META-INF/MANIFEST.MF $JAVAMOPAGENT_FILE -C $AGENT_DIR .
You should make sure that the manifest file is specified. If this is successful, you will get a JavaMOP-Agent, referred to as $JAVAMOPAGENT_FILE.
Now, you can test a program using $JAVAMOPAGENT_FILE. For example,
java -javaagent:$JAVAMOPAGENT_FILE Foo
Hope this works!