Object Components

In the Microsoft VM for Java, a class is a description of an object type that includes declarations of data and method members. Classes can inherit all types of members from parent classes including constants (static final fields), static fields and methods that exist once for all instances of a class in one namespace and are shared between instances, dynamic fields that exist separately in every instance of the class type, and dynamic methods that operate on specific instances of a class through a "this" pointer.

Interfaces declare only abstract, dynamic methods, constants fields, and properties (which you can think of as "virtual fields"). The methods declared in an interface can be implemented only in a class, not in an interface. When a class implements an interface, it is guaranteed to contain an implementation for every method in that interface, and all interfaces that the interface extends.

This object model specifies layout of the following object components.

• Synchronization block
• Methods
• Interfaces
• Dynamic fields

When a base interface is loaded, vtables are created for its member methods, fields, and interfaces that it extends. The field tables are simply arrays of the field description structures; methods also are described by arrays of methods descriptions, but have vtables associated with them that can be accessed by indexes that remain constant throughout the hierarchy of a class.

When a base class is loaded, the Microsoft VM creates tables just as with interfaces for its member fields and methods. The class vtable differs from an interface vtable only in that its header contains the number of interface slots found below the object, and a pointer to the actual class descriptor that owns the vtable. These elements are followed by interface vtables and then by method pointers which are not declared in any of the implemented interfaces. Method pointers are pointers to the native Just-In-Time (JIT) code entry points or a native interpreter stub (call compatible with JIT code) of methods implemented in the class or its superclasses. An interface vtable consists simply of an array of methods.

Now that you know what a vtable looks like, look at how it is used in the context of creating an object—treating it as an instance of one of its superclasses, or treating it as an instance of one of its implemented interfaces.

The following example class contains one field and one method. The class, "foo", looks like the following:

public class foo {

public int Field1;

	void Method1()  {}
}

Normally, a Java-compatible compiler will create a constructor for this class, and the object will inherit methods from the Object class. For the purpose of this example, pretend that all you get is one field, Field1, and one method, Method1. The vtable for this class would look like:

An object of type foo would contain space for Field1, a main vtable pointer, and a pointer to the synchronization block. Note that the synchronization block for an object is not really present unless it is used. It is created "lazily" to conserve space in nonsynchronized objects. The vtable exists only once per class and is shared among objects of that class type, but the synchronization block is per instance.

The following illustration shows an object of type foo.

If you declare two interfaces, IFCA and IFCB, IFCA contains one method, Method2; IFCB contains two methods, Method3 and Method4. If you then declare another class, "bar", which extends foo and implements IFCA and IFCB, you get an object that looks like the following illustration.

An interface's vtable is simply an array of Just-In-Time–compiled, code-callable methods. If an interface extends other interfaces, it has those interface vtables inside it. When the Microsoft VM for Java resolves an object that implements an interface, that interface vtable is copied to the main vtable when it is encountered. The nested interface offsets are calculated by adding their offsets in the implemented interface to the current position in the new vtable.

Since some aspects of the object model used internally in the Microsoft VM for Java are subject to change, all data structures besides the object data itself should be considered abstract and accessed only through functions available in Java.