You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

The class data structures of the Java HotSpot virtual machine are immutable during the execution of a program. While new classes can be loaded, it is not possible to change existing classes (e.g. add/remove methods or fields). This projects tries to relax this condition to allow arbitrary changes to existing Java classes (including changes to the class hierarchy) while running a Java program.

Prototype

Work in progress.

Latest patch update: February 2, 2010
Patch name: hotswap.patch
Please send any comments or questions to: wuerthinger@ssw.jku.at

Implementation Notes

Initial implementation description (April 1, 2009): Thomas Wuerthinger, Dynamic Code Evolution for the Java HotSpotVirtual Machine

General Design Decisions

  • Arbitrary changes possible (including changes to subtype relationships)
  • No performance penalty before or after the change
  • No introduced indirections
  • Continued execution of old active methods
  • Only simple, comprehensible strategies for field matching or method transitions
  • Change possible at any point when the VM is suspended
  • Graceful handling of accesses to deleted fields or calls of deleted methods

Status

Type of Change

Supported?

Possible problems after resume

Swap Method Body

yes

 

Add Method

yes

 

Remove Method

yes

NoSuchMethodError

Add Field

yes

 

Remove Field

yes

NoSuchFieldError

Add Supertype

yes

 

Remove Supertype

yes

possible VM crash

Mutator Methods

Classes can implement a method "void $mutator()".
This method is called on every object whose class was redefined and can therefore be used to initialize the new instances of a class.
Example code:

Initial version
class A {
  int x;
}
New version
class A' {
  int x;
  int doubleX;

  void $mutator() {
    doubleX = 2 * x;
  }
}

Future Work

  • Identify possible problems introduced by deleting a method or field (bytecode analysis on existing fields).
  • Determine safety of type narrowing changes.
  • Automatic generation of mutator methods
  • Investigate ways to match method execution points.
  • No labels