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.