Caching Issues

I rewrote a few parts of the Thread Checker, mainly in the areas that instrument classes on-the-fly and in the strategy for automatically generating predicate methods for @Combine-style annotations.

Now making backups and saving annotated class files works as expected. I also require a directory to be on the classpath, but only if @Combine-style annotations are used. The caching works very well if the classes involved in rewriting are all regular files and not in jar files: Running the TCSample4 test the first time with on-the-fly instrumentation takes about 33 seconds, the second time it doesn’t even take 2 seconds.

Unfortunately, when the files are in a jar file, caching the rewritten class files is not very effective: The first run takes about 31 seconds, and the second still 30 seconds. The problem obviously is that generating the code isn’t the expensive part, but examining the class files to figure out what code to generate or check if it has already been generated.

I could write some kind of caching for jar files or write out the information obtained into some kind of file, and then on the second run first consult that file, in the hopes of being able to skip the expensive examination phase, but it just doesn’t seem like that is so essential to the project. There are other, more important things to figure out, so my suggestion right now is just this: Keep the files that are involved in rewriting outside of jars.


About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing. Bookmark the permalink.

Leave a Reply