Fast class reloading

[Igor Adam Klimer]

Dear all,
my name is Igor Klimer, I'm a 5th year student at the Wroclaw University of Technology [1]. For my Master of Science thesis, I'm working on improving the performance of a mutation testing tool my colleagues are working on.

Long story short - for each class you want to test, you end up with hundreds (+/- it depends on the number of mutation operators enabled) of "mutants" - slightly modified (by a mutation operator) original class. This mutations (one mutation at a time, in one place of the class at a time) range from simple arithmetic operator changes ("-" becomes "+") to changing method signature. The problem is that each of this mutation is just another version of the same class, so I have to load each of them via a separate ClassLoader - which has a very significant impact on the overall testing process.

So my main job is to make the class (re)loading faster or even better (?) take it out of the equation. Unfortunately, Java doesn't support [2] dynamic class reloading which makes this problem tougher (and more interesting ;)). I've looked into a number of possible solutions:
- HotSwap [3] offers great speed, but it can only modify the body of a method. While that would speed up some/most of the mutation operators, the *most* interesting ones, the object-oriented ones, would be impossible with this method
- many solutions involving proxy classes [4], etc. - while they offer great flexibility, the speed penalty of modifying such a number of classes would probably nullify any speed improvements over normal classloading
- creating a custom JVM - while this solution seems the most elegant one (and offering the greatest possibilities), I'm afraid it would void any chances of thie mutation testing tool becoming a popular tool/practice. Another reason against this idea is that, AFAIK, Sun does not allow creating custom JVM's based on their code. A possible solution (and usually preferred for research purposes) is to use the JikesRVM [5] - which is very "research-friendly". However, since speed and compatibility is our goal, JikesRVM is also not acceptable.

One solution I came up with is to use a Java Agent [3] to modify some key elements of the JVM so that class reloading would be possible (and didn't have the restrictions of HotSwap). While I understand that it's harder than it sounds, I believe (more like: I pray :)) it is doable - of course, this solution would be highly customized to our needs/situation - for example, we can be sure that once a class/mutant is tested it can be safely discarded/reloaded, we're sure no other part of the program is going to reference it. It might come out a bit "hackish", but it's the best I could come up with.

So my question to you, dear Hotspot developers, is what are your thoughts on this? Just your "gut feeling" is ok - does my idea seem feasible? Any advice where to start hacking the JVM? I was also wondering if you could point to some more information on the internals of class loading - I found [6], [7] and [8] a very interesting read (although they are too brief, IMHO), the source code and comments there are also helpful, but I was wondering if there's anything more you'd recommend :)

Any thoughts on this matter would be greatly appreciated.

Best regards,
Igor Klimer

[1] http://www.pwr.wroc.pl/en_main.xml
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812
[3] http://java.sun.com/javase/6/docs/technotes/guides/instrumentation/index.html
[4] M. Pukall et al, Flexible Runtime Program Adaptations in Java-A Comparision, http://www2.cs.uni-magdeburg.de/fin_media/downloads/forschung/technical_reports_und_preprints/2009/TechReport14-p-1591.pdf
[5] http://jikesrvm.org/
[6] http://wikis.sun.com/display/HotSpotDev/Hom
[7] http://wikis.sun.com/display/HotSpotInternals/Home
[8] http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html