Check out the new USENIX Web site. next up previous
Next: Scenario A: Adding a Up: Supporting Binary Compatibility with Previous: Background


Static Compilation vs Binary Compatibility

In this section, we give examples to illustrate the concept of Java binary compatibility. We also show how the naïve application of the standard vtable approach for static compilation fails.

Consider the following program. Class Programmer defines two virtual methods, eat and hack. Class JavaProgrammer extends class Programmer, overrides those two methods, and defines a new virtual method study. The main method of class Manager creates instances of both the above classes and does some virtual method calls. Note that at run-time the variable Whoami contains an object of class JavaProgrammer, although its static class is Programmer.

public class Programmer {
  void eat  () { ... };
  void hack () { ... };
}
public class JavaProgrammer
     extends Programmer{
  void eat  () { ... };
  void hack () { ... };
  void study() { ... };
}
public class Manager {
  public static void main (String args[]) {
    // some code that runs for days...
    ...
    Programmer Tom = new Programmer();
    JavaProgrammer Jerry = new JavaProgrammer();
    Programmer Whoami = new JavaProgrammer();
    ...
    Tom.eat();
    Tom.hack();
    Jerry.eat();
    Jerry.hack();
    Jerry.study();
    ...
}}
The standard technique used in object-oriented programming language implementations supports virtual method dispatch by collecting the virtual methods of a class in a record called a vtable, and providing a pointer to this record in each object of the class. When the three classes above are compiled, the layout of the vtables of classes Programmer and JavaProgrammer is determined statically (Figure 1), and the code in class Manager is compiled to invoke virtual methods by accessing the corresponding entries in the vtables of these classes, reachable through the respective objects. Since the variable Whoami, declared of class Programmer, can be bound to an object of class JavaProgrammer, the layout of the vtable of JavaProgrammer must be consistent with that of Programmer, so that virtual method invocations can be compiled to use the same offset in the vtable for a given method of Programmer, regardless of the dynamic class of the object.

Figure 1: The vtables.

However, this vtable approach cannot be directly applied if we want to support binary compatibility. When changes are made to the binary of a class, the locations of method pointers in the vtable may change, which invalidates the offset information used to compile other classes. Even worse, vtables reachable through objects of the same static class may now have different layout, as illustrated in the following subsections.



Subsections
next up previous
Next: Scenario A: Adding a Up: Supporting Binary Compatibility with Previous: Background
Dachuan Yu 2002-05-23