Further Developments

[Jonathan Shapiro]

Over the break, Dave Farber and I had some discussions in the context
of the Eniac 2000 project.  One result of these discussions is that
our research efforts do not require that DIMSUM support heterogeneity.
This will greatly simplify matters, especially in the area of segment
content management.

A consequence is that the level of scalability that I am trying to
achieve has been reduced.

Another result is that I'm now re-examining how far DIMSUM needs to
deviate from KeyKOS.  The revised goals of DIMSUM are:

o Support for QoS scheduling
o Support for "workstation clusters" - clusters of homogeneous
  workstations haveing the ability to transparently support
  traditional TCMP applications on multiple processors using DSM.
o Providing a simple core environment for investigating the
  construction of composable, object-oriented operating environments
  and systems.

Initially, when I thought that wide-scale distribution was vital,
built-in persistence seemed to introduce more issues than I really
wanted to deal with.  Recently, I've had occasion to think more about
the value of persistent processes, and I've come to the conclusion
that I had missed some important issues: persistent, active objects
seem very important in building certain kinds of security and
robustness.  I'm uncertain, as yet, how much of the importance lies in
the "persistent" quality as opposed to in the "active" quality, and
I'ld like to open a discussion on that (see next mail).

Restarting from KeyKOS as a base, the question is then "what changes
are needed to support the above requirements?"  The issues that I see are:

	o scheduling
	o failure discovery, containment, and recovery within such a
          cluster.

These issues have been explored in other systems, such as V, Sprite,
and Amoeba.  As far as I can tell, however, all of these systems view
processes as the unit of migration, and all threads (for those systems
that support threads) migrate together.  With the introduction of ATM,
it seems worthwhile to maybe explore that space a bit further.

	o process persistence, and the fallout for memory objects

Orthogonal persistence has been explored in various systems, but not
in the context of capability systems.  From the papers that I have
read, it seems that persistence has been approached as a "graft on" to
the existing process model rather than as a fundamental part of it.
I'm also inclined to think that the solutions that I have seen are not
wonderful.  Assuming that process persistence is what we want, how to
achieve it in a distributed context remains an interesting issue.


Jonathan