Metadata and Method Dispatch

  

Figure 7: The method lookup objects. Lookup proceeds first as shown on the left to acquire a MethodDecl, then on the right to acquire a MethodBody.

Jupiter creates metadata resource objects to represent the Java program itself. These objects take the form of Classes, Fields, MethodDecls, and MethodBodies. Jupiter accesses classes by name through the ClassSource interface, using a function called getClass. Once a Class has been acquired, its Fields, MethodDecls and MethodBodies can be accessed in order to perform the operations required by the running Java program. A Field encapsulates the data required to locate a field within an object. Typically, it contains nothing more than the field's offset. A MethodDecl encapsulates the data stored in the constant pool to represent METHODREF and INTERFACEMETHODREF entries. A MethodBody encapsulates the data that represents a method implementation; for non-native methods, it holds the bytecode instructions.

Method dispatch is modeled as a mapping from a MethodDecl to a MethodBody. The data structures involved in this mapping are shown in Figure 7. First, the ConstantPool of the target object's Class is consulted to acquire a MethodDecl object. If the MethodDecl has not yet been resolved, the ConstantPool calls upon the Class to locate the MethodDecl, for which it uses a hash table keyed by method name and type signature. As with most JVMs, once the MethodDecl has been acquired, it is cached by the ConstantPool to accelerate subsequent accesses.

Having acquired the MethodDecl, it must now be dispatched to a particular MethodBody. This is done using jump tables indexed by an offset stored in the MethodDecl. Interface methods use a two-level table scheme that allows them to be dispatched in constant time [14]. Once the MethodBody has been acquired, it can be executed, either by interpreting its bytecode, or, for native methods, by invoking the appropriate function through the Java Native Interface (JNI) [11].