Hotswap

From APIDesign

Revision as of 17:45, 21 December 2010

Hotswap is the most important technology that makes developers productive. Why people think that PHP makes them more productive than Java? Because it is enough to change a single line of code in your .php file, save it and reload the webpage. Doing the same with Java requires compilation, packaging, deployment. All of this takes ages and is not flexible enough. At least it was not until Thomas Wuerthinger released his patched Hotspot!

Modular systems and Hotswap

In fact, the goal of modular systems is to allow a kind of hotswap. System components are supposed to be installed, enabled, disabled, upgraded or removed from the system on the fly. I believe the modular system succeeded in their mission. They find out the necessary practices to make this happen and limit the goals, so we know what is beyond the scope.

Modularity works fine for services. For implementation of shared interface that some components/modules in the system implement and others look up and use. Really look up and use everytime, you are not allowed to hold a reference to individual implementations. Such implementations are dynamic, change everytime and keeping reference to them may result in two objects implementing the same interface (old and new) not being assignable to each other.

In spite of that restriction, modularity helps developers a lot. Instead of reloading the whole application after change of one service implementation, one can reload just the implementing component/module. Still, all the objects created by the module need to be released and recreated.

Web vs. Desktop

For certain kinds of applications it does not matter that all user objects need to vanish during Hotswap. For example on web this is quite usual. Most of the objects persist only only during one request handling. Throwing them away and pressing F5 to reload a page is easy.

However hotswapping the desktop application is more complicated. Nobody can be sure that objects allocated by the hotswaped component are not referenced by other parts of the system. True hotswap system for this kind of environment needs to be able to traverse all the existing objects of of existing component and upgrade them to new ones. Sometimes this is easy (code changes), sometimes it is harder (adding fields, removing fields), sometimes it may be almost impossible (drastic changes to interface hierarchy).

This kind of problems may appear in web applications too (there are often objects that span the life cycle of a request), but they are not as often and as disastrous as in case of desktop. The session wide or application wide objects are usually just config data and they don't change that often anyway.

The JDK Hotswap

When you run the JDK in debug mode, it immediately comes with support for hotswap. You can change your code, recompile your classes and upload modified version to the already running VM. The whole system has one big problem: As of JDK6, you can only change method bodies, not the class definitions. You cannot add new fields, new methods, change method parameters, etc. If you do, then the system shouts at you when applying the changes.

This results in two reactions: first of all users don't use JDK's hotswap at all, as they know it is almost always useless. Instead of incorporating instant code changes into common development lifecycle, they rather shut the system down and restart.

The second outcome of this inflexibility of JDK is a proliferation of various projects (open source like Javaleon) as well as commercial ones that play various classloading and bytecode manipulation tricks to make real hotswap work on top of old JDK. The downside is that you need to start the VM with some special parameters (not always supported by all IDEs) and that often the support is not general - for some frameworks it works better than for other Java applications.

There used to be a saying that Microsoft supports innovation by providing poor MS-DOS, so others can implement improvements and earn some money on it. This time Sun is in the same position, instead of improving the JDK to handle real hotswap (something that SmallTalk can do for decades), the company sponsors segmented efforts to workaround its own limitations.

JDK for Developers

However there is no need to despair any longer. Thomas Wuerthinger fixed Hotspot to handle the real hotswap by itself. No need to download libraries and change your launch scripts. Just download Thomas's work from http://ssw.jku.at/dcevm/, execute the installer and your JDK suddenly true JDK for Developers.

Funny that the D in middle of JDK stays for development, but it takes one extra Thomas to make the developer the real focus of the JDK!

Thomas's version of Hotspot VM solves the old vs. new objects problem. As soon as you upload new version of a class, it re-casts all existing objects from the old class to new. Your code does not need to be ready for this at all, everything changes automatically. Classes get new methods, implement different interfaces, objects allocate new fields.

One might see this as a hotswaping nirvana, a place where we always wanted to be. Now the hotswap is finally ready for production!

Ready for Production

Wait, there are still remaining open issues. Hotswap can update the data structures, but it does not re-run already executed algorithms and cannot influence result of their execution. As such there can still be objects flying around which are initialized into a state far different (and sometimes inconsistent) with the state the new system expects.

For example the newly added fields can be null, in spite they are always initialized in constructor to non-null values.

Matisse Example

TBD

Virtualization

TBD