Hotswap

From APIDesign

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 it has never been flexible enough. At least it was not until Thomas Würthinger 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. NetBeans Runtime Container as well as OSGi containers helped us find the necessary practices to make hotswapping happen and also helped us realize the limits. 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

Some kinds of applications are more suitable for Hotswap than others. Some can release all user objects after change their implementation classes easily. This is the case of web applications for example. Most of the objects persist only only during handling of a single request. Changing their implementation, throwing them away and pressing F5 to reload a page in browser to start over 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 Würthinger 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!

Changing the done state

Wait, there are still remaining open issues. Hotswap can update the data structures easily, but there are still things that shall be updated (to really replace the previous component with new behavior) and which remain.

First problem is a old method on a stack. This is not that big problem for web-like request scope computation, which respond to a request and exit. However for real application (for example the web server infrastructure) this is very desirable. Often there are main loops that endlessly process incomming data over and over. When the code of these loops is updated, it needs to be replaced while there is a thread having the method on its execution stack. Not all hotswap technologies support this, it is complex task, but definitely not impossible. Thomas mentioned his university has plans to work on that.

However problems don't end with method on stack issue, that is just the begining. More complex problem is the need to re-run already executed algorithms during hotswap. Without this capability there can remain objects flying around that are (from new point of view) improperly initialized. For example the newly added fields can be null, in spite they are always initialized in constructor to non-null values. Or the fields can have different value than expected. Consider following trivial case:

// old version of the class
class Data {
  final int version = 0;
  public void checkVersion() { assert version = 0; }
}
// new version of the class
class Data {
  final int version = 1;
  public void checkVersion() { assert version = 1; }
}

All instances of the Data class existing prior the Hotswap to new version will throw an assert from the checkVersion() method.

Matisse Example

TBD

Virtualization

TBD