In Scenario A we added a new method sleep at the very beginning of Programmer. Our solution does not require recompilation of Manager, because Manager does not make any assumptions about the vtable layouts of Programmer and JavaProgrammer.
Figure 7 illustrates what happens during the class loading of Programmer and JavaProgrammer. When Programmer is being loaded, its vtable is constructed on the fly so that any binary changes before class loading can be taken into account. The layout of this newly constructed vtable is registered in the global allocation table entry of Programmer. This layout information is used to fill in the relevant offset table entries of Manager.
When JavaProgrammer is loaded later (being a subclass of Programmer, its loading cannot precede that of Programmer), its vtable is constructed following the layout requirements specified by the global allocation table entry of Programmer. By doing this, the consistency of the vtable layouts between a subclass and its superclass is maintained. Once this is done, the layout information is propagated accordingly to the offset table entries of Manager. Using the offset specified in the corresponding offset table entry, a virtual method invocation will successfully get through.
