Check out the new USENIX Web site. next up previous
Next: Algorithm Up: Example Revisited: Programmer & Previous: Scenario B Revisited: Removing


Scenario C Revisited: Binary Change at Run Time

Our solution works even if binary changes happen at run time (Figure 9). Here we illustrate why this is true using the example in scenario C, in which we changed the class hierarchy compatibly by inserting a new class. In scenario C, after class Manager is loaded and being executed, we add a new class OOProgrammer into the old class hierarchy. When object Tom is being created, class Programmer is loaded. Then, when object Jerry is being created, both class OOProgrammer and class JavaProgrammer are loaded. The vtable layouts of Programmer, OOProgrammer and JavaProgrammer are determined during class loading. All of this information is registered in the global allocation table. Using this information, the offset table of Manager is filled in incrementally. Eventually, the virtual method invocations will get through.

Figure 9: Scenario C revisited: changing class hierarchy.



Dachuan Yu 2002-05-23