Fast class reloading
David.Holmes at oracle.com
Mon May 31 18:02:06 PDT 2010
Gut feeling: you need a modified JVM to do this. If you only want to add
new methods then a mechanism for expanding the existing vtable and
codecache etc of the loaded class might not be too hard. Adding fields
is much harder as all existing objects need to be modified in place to
have the new field (or else you do some serious augmentation to allow
missing fields to be trapped and handled in a different manner). Dealing
with existing instances of a class is what makes general hot-swapping
By the way you can build any kind of custom VM you want from the OpenJDK
Igor Adam Klimer said the following on 06/01/10 10:37:
> Dear all,
> my name is Igor Klimer, I'm a 5th year student at the Wroclaw University of Technology . 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  dynamic class reloading which makes this problem tougher (and more interesting ;)). I've looked into a number of possible solutions:
> - HotSwap  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 , 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  - 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  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 ,  and  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
>  http://www.pwr.wroc.pl/en_main.xml
>  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812
>  http://java.sun.com/javase/6/docs/technotes/guides/instrumentation/index.html
>  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
>  http://jikesrvm.org/
>  http://wikis.sun.com/display/HotSpotDev/Hom
>  http://wikis.sun.com/display/HotSpotInternals/Home
>  http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html
More information about the hotspot-runtime-dev