Java VM Class Reloading
Does anyone know of a JVM that supports full class reloading? Sun's JVM doesn't seem to support schema changes. Eclipse works around the issue by loading multiple copies of the same class, but that won't work for me. I couldn't find any details on the JRockit site (though it does have some experimental JIT caching that looks neat). The Jikes VM doesn't appear to have much debugging support at all.
Update: I've concluded that no JVM implementation supports full class reloading. Bummer. I guess JVM implementors care too much about perfect atomicity and consistency. I'm not too worried about a little fuziness (i.e. inconsistent state) because we're just talking about development time, not production, and I don't hear too many complaints from the Rails crowd. I'd modify an existing JVM, but my c/c++ skills are a little rusty, and the only viable Open Source JVM I know of is Jikes. I'd prefer not to do all my development on an experimental JVM.
Does .NET support full class reloading? If so, that combined with the fact that C# now supports closures and implicitly typed local variables might just be enough incentive to switch.
I think I'll build on Eclipse. Eclipse already plays a little fast and loose by loading up new copies of existing classes (both classes can exist at the same time). I could crawl the heap looking for instances of the old class. When I find an old instance, I could create an instance of the new class (without invoking the constructor), copy over the fields from the old instance to the new, and point all references to the new instance. If it's fast enough for the garbage collector, it should be fast enough for me. ;)
7 Comments:
If you feel comfortable with C code, this feature can get into Mustag, or perhaps next VM after it... :-)
Isn't
this (experimentalstuff.com) pretty much what you're talking about? You didn't specify what exactly you need, so...
hope this helps, though :-)
Hotswap implementations are limited and do not allow schema change - though the spec supports that in theory.
The primary reason beehind it as far as I know from my JRockit folks is a risk of out of memory when adding new members to a class.
Couldn't groovy help there? What is your use-case?
I guess Eclipse is doing it with many many classloader. It 's not clear how you'll maintain visibility with unchanged dependant classes though.
Use case is improving the Java web developer experience, so I need to stick to Java. Also, I tried the BeanShell route, but it actually doesn't help much. If an object escapes interpretted land (i.e. into a framework), you're back in the same boat.
You have to reload dependent classes, too, I would suspect.
Would some kind of custom classloader which is aware of changes to its loaded classes help address your problem?
Basically if all the application classes are loaded from a single classloader (custom) which keeps track of the timestamps of classes it loaded and we just bounce the classloader and use the new one if any of the timestamps change on disk.
WebLogic does this for webapps. So compiling any modified files causes a classloader bounce and you get the latest classes reloaded.
This isn't much different from restarting the server. I'd like to maintain as much state as possible.
Hei, I know that a lot of time has passed, but we solved at least part of the class reloading problem. Check it out.
Post a Comment
<< Home