The ovm.core.domain package contains the interfaces that deal with domain-specific information, along with actual VM object type information and layout.

A domain is essentially an application space; applications running in different domains have (conceptually) no interaction via shared objects. Two different domains might well contain two classes with the same name but different implementations (for example, one domain may contain a class that uses one version of java.lang.String, whereas another application may expect a different implementation of this class). The domain with which the application is associated will determine where classes will be searched for at resolution time.

Information about objects and their types is stored in two different data structures. A Type contains information about a class and its structure and domain. Some information within a Type may be resolved lazily. A Type has a reference to its Context, which contains a reference to the Type's domain. Thus, every Type belongs to exactly one Context, and every Context refers to exactly one Domain. The Type can then be seen as a domain-specific representation of class information.

Each Type is corresponds to a RepositoryClass; the RepositoryClass encapsulates the repository's view of the information contained in a class file. The Type object represents a particular domain's view of the associated class. (This means that there could be several different Type objects associated with a given RepositoryClass object.)

As mentioned in the before, some information within a type may be filled in lazily. For example, if a class has a field which is never assigned to, the class representing that field's type may never be loaded. Since the field's type may never be resolved, the Type doesn't bother to encode that information until the actual resolution occurs. Type objects, then, may evolve at runtime.

A Blueprint, on the other hand, represents an object's layout and the information necessary to create an instance of that object. This may include virtual method tables and other information, but this depends upon the implementation of Blueprint. Once an object has been created with a given instance of Blueprint, that Blueprint is then considered immutable.

There is not necessarily a one-to-one mapping between Types and Blueprints. Every Blueprint does have exactly one associated Type; however, it is possible that an implementation may choose allow a Type to have several different Blueprints for various reasons. For example, if there were a reason to add some bookkeeping information to some instances with a given Type, but not all of them, a second Blueprint could be associated with the type that had additional space for this information. Multiple Blueprints corresponding to the same type must still be compatible, however.

Domains, then, are containers for Blueprints and Types. Similarly, a Type may have multiple Blueprints.

Every object in the language being implemented is visible to the implementing language as an Oop. Each Oop, as the representation of an object, has a Blueprint; this Blueprint has a reference to its Type.

Other associated objects, such as class member objects, are also included in the ovm.core.domain package. See specific class descriptions for details.

N.B.: For the time being, there is a one-to-one correspondence between Type objects and Blueprint objects. However, KP indicated that this will hopefully change, at least as far as the higher-level concept is concerned (i.e. implementations may choose to keep this one-to-one, but this is a special case of one-to-many).

An example of the interaction between RepositoryClass objects, Types, and Blueprints is shown below. This figure is based upon the following code:

      class A {
          static int bar;
          public int foo;
      }
      



As the figure shows, each instance of A is associated with a Blueprint. The instance object itself contains the values associated with that instance (in this case, the value of foo). Here there are two instances of A shown: a1 and a2. Both were created from the same Blueprint, but could have different values for foo.

The Blueprint associated with a1 and a2 describes the instance object layout. In this case, for example, it contains information about the offset of foo within the object. It also contains a reference to the Type object associated with class A in this domain. It also contains a reference to a shared-state object for class A as well as a reference to the Blueprint for all objects of class Blueprint; these are discussed in more detail below.

A shared-state object is associated with each Type object. It functions much like an instance object, except that it contains any shared-state information for the class and, as such, there is only one such object per Type. For example, in Java, this object contains the values of static variables. In our example, then, this object would contain the value of bar for all instances of class A, since it is a class variable, not an instance variable.

Like instance objects, the shared-state object has a Blueprint which describes its layout, including the offsets of member variables. To ensure that there is not an infinitely recursive chain of shared-state objects, the shared-state pointed to by a shared-state Blueprint is null. The Type object referenced by a shared-state Blueprint is the same Type referenced by instance objects of the class. As with instance object Blueprints (and indeed all Blueprints), there is a reference to the Blueprint for instances of class Blueprint.

For reference, it should be noted that Blueprint extends Oop. As mentioned before, all Oop objects have a Blueprint. Thus, instances of class Blueprint also have a Blueprint describing their layout. In the figure, all Blueprint objects contain a Blueprint reference. As shown, these all point to the Blueprint for instances of the Blueprint class. This Blueprint contains the same kind of information that the Blueprint for instances of class A contains; a reference to the Type object associated with class Blueprint, a reference to the shared-state object, etc.