From: mpearson@buserr.gatech.edu (Mark Pearson)
Subject: Re: Rethinking the Object Paradigm
Organization: The Clouds Project, Georgia Tech
Date: Fri, 29 Jan 1993 03:38:52 GMT


In Clouds (a distributed operating system), we may specify large-grained
object classes, that contain code and data. The classes, when instantiated,
represent an entire user address space, with an entry-point interface. 

Consider a typical program, running on a conventional operating system.
When we start the program, a process is created, and a virtual address
space for the process is created. We initialize some data in virtual
memory. We hopefully do some interesting. If this program is a server,
or a daemon, our process blocks for a message. Upon receipt of the
message, the server does something interesting, and then blocks for
the next message. When the process dies, the virtual address space
associated with it is removed.

Some common message passing distributed operating systems allow large-grained
objects, similar to Clouds objects, to be specified and instantiated.
These instantiations include a virtual address space, and a process (because
the virtual address space cannot exist without the process). 
These are *active* objects, because their existence relies on the
existence of an active process.

In Clouds, the address space and means of execution (read process) are
divorced. Thus the Clouds object (persistent virtual address space) is
*passive*. When an object entry-point is invoked, a process, which
exists on behalf of a user thread, maps in 
in this virtual address space so that it is visible to the process.
The thread may then execute in the Clouds object, and change data
within it. When the thread leaves the object, the address space pertaining
to the object persists, along with the changes made to the data within
it. The next time this object is visited, the data is available in
the state seen by the last thread at its exit point. Since the
existence of the Clouds object is not tied to any process (or active
entity) it is a *passive* object.

The majority of object instances created a running 
OO language program are passive objects.
They have no thread of control associated with them. A process may
visit them, and via their methods, change data within them.
Once the main thread of control exits the method code within these
objects, they persist, retaining their data until the process
revisits them.

In order to have an active object in this circumstance, a thread
of control would have to be associated with the object instance
itself. One such example would be an object class that, when
instantiated, would create a garbage collection thread of control
to collect garbage in data structures defined within the instance. Whether
or not the main program's thread of control visits the object, this
other thread of control (heavy or lightweight) would always be
active within it. This instance would not function properly if something
happened to this active thread.

Thus, to determine whether an object is passive or active, one must
ask the question whether this object can exist *without* the
active entity. If it can, it is passive. If it cannot, it is active.

-Mark



Mark Pearson, Distributed Systems Group/Clouds Project, College of Computing
Georgia Institute of Technology, Atlanta, Georgia, 30332-0280 404-853-9390/1
uucp    : ...!{akgua,decvax,ihnp4,ulysses}!gatech!helios!mpearson
Internet: mpearson@cc.gatech.edu