Sun Microsystems Laboratories Experimental Stuff HotSwap Client Tool

Background - the HotSwap Research Project

There is a class of computer applications that must run continuously and without interruption, and yet must be changed from time to time to fix bugs or upgrade functionality. The most spectacular examples of such applications are financial transaction processors, telephone switches, air traffic control systems, etc. A common solution to make highly important, mission-critical systems run non-stop, is to design them in a special way and/or run them on a specially configured, redundant hardware. In the case of applications written in the Java™ language, custom class loaders are often used to implement dynamic class updating.

However, it is widely realized that custom class loaders are not an ideal solution. One problem with this approach is incompatibility between instances of versions of a class created by different class loaders. That is, you cannot re-use previously created objects with the new class version even if the object format is the same for both classes, and you may need to write additional code to migrate objects to the new class. The most general problem with custom class loaders, however, is that this solution does not support unanticipated class evolution. That is, you have to write your application such that it anticipates which classes may be updated, and has a means of interacting with the user/administrator, retrieving the new class version, installing it, etc. This does not make your application more readable or easier to maintain, and only supports updating of a limited subset of classes.

The HotSwap project addresses the above issues by providing the capability to dynamically update classes at the JVM level. That is, any class can be redefined on-the-fly by attaching a dedicated tool to the running JVM and invoking a special API call that takes an existing class object and the new class version in the form of a byte array corresponding to the .class file.

A natural question that many people ask at this point is: what happens to the active methods of the updated class? The answer is: in our current implementation, all invocations of old methods are allowed to complete, whereas all method calls initiated after class redefinition go to new methods. One may think of other method replacement policies, for example, "wait until there are no active invocations of methods of the class to be redefined" (if such a state is ever achievable). See the discussion of various method replacement policies in our research publications.

HotSwap Project Research Publications

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Safe Class and Data Evolution in Large and Long-Lived Java Applications
M. Dmitriev
PhD Thesis, Department of Computing Science, University of Glasgow, Scotland. Also published as Sun Technical Report SMLI TR-2001-99.
Abstract

Towards Flexible and Safe Technology for Runtime Evolution of Java Language Applications
M. Dmitriev
Published in the Proceedings of the Workshop on Engineering Complex Object-Oriented Systems for Evolution, in association with OOPSLA 2001 International Conference, Tampa Bay, Florida, USA, October 14-18, 2001.
Abstract

This page is: http://www.experimentalstuff.com/Technologies/HotSwapTool/publications.html
Last Modified: Wed, 08 May 2002 18:13:30 GMT
copyright (c) 2000-2009, Sun Microsystems