[E-Lang] Re: Upgrading old objects
Mark S. Miller
Wed, 28 Nov 2001 10:47:51 -0800
Sending to e-lang as well, because I think it's of general interest.
At 04:46 PM 11/22/2001 Thursday, Vijay Saraswat wrote:
>So have you thought through the issus with upgrading old objects? Does
>this need to be dealt with in R0RE? Or not just yet?
I have thought about it extensively, but probably not adequately. It is,
and for a long time will remain, one of the hardest problems confronting us.
In any case, I think R0RE should deal with upgrade, as upgrade-support is
the rationale of several features of the E language, even though
upgrade-support is not yet implemented, and there are still some open design
In particular, Rather than having the object expression simply be lambda +
message dispatch, We also bundled in the object's "name". In expansion to
Kernel-E, this name expands into serving as both a variable name (nothing
unusual so far), and into a fully qualified behavior name (the special part,
but not yet fully implemented). On
http://www.erights.org/elang/kernel/ObjectExpr.html it says:
>The String is the optional behavior name, or "_" if absent. It serves the
>same function as Java's fully qualified class name, including continuity
>across upgrade (both serialization-upgrade and live upgrade), [...]. If the
>behavior name is absent ("_"), its instances cannot be serialized,
>unserialized, or upgraded; [...].
>If the behavior name is present, it will be interpreted as a sequence of
>segments separated by "."s. All but the last of these segments will be
>interpreted as package names, and should correspond to the relative
>directory path from the source root in which the current source file is
>found. The last segment is interpreted as the containment path. It is
>further interpreted as a sequence of segments separated by "$"s, and should
>correspond to the lexical nesting of object expressions. No two object
>expressions should use the same behavior name. We do not yet specify what
>happens when these conventions are not followed, but currently such programs
>will be rejected.
Actually, the rejection of convention-violating programs isn't implemented
And there are open design issues here regarding security, assurance of
immutability, and (ClassLoader-like?) management of multiple namespaces of
fully-qualified behavior names.
What's the point of all this? Anonymous closures cannot be upgraded,
because there's no reliable way to determine which new anonymous lambda
expression, in some new version of the sources, corresponds to the original
lambda expression of which this closure is an instance. The correspondences
cannot be inferred, they must be stated by the programmer. Java succeeds at
serialization-based upgrade of instances of named serializable classes,
because the programmer understands that the fully qualified class name (or
the simple class name + serial UID) is the basis for upgrade continuity, and
can engineer successive versions accordingly. Smalltalk succeeds at both
serialization-based upgrade and live upgrade for the same reason -- but only
for instances of named classes.
E's fully qualified behavior name serves the same role in the same way, and
is defined to enable an E implementation to be mapped on to a Java
implementation in a straightforward way, enabling E to parasitize Java's
support for serialization-based upgrade.
Serialization-based upgrade applies to two circumstances:
1) "upgrade for release" -- I release a new version of some body of code,
and my customers upgrade their old instances to be instances of the new code.
2) "comm coexistence" -- VatA serializes a PassByCopy instance of
foo.bar.Carol to VatB. Can VatB unserialize this object to instantiate the
code bound to foo.bar.Carol in some (ClassLoader-like?) namespace already in
VatB? Note that we may define this issue away: it is at least consistent to
say that passing an object by copy also passes its behavior by copy.
Besides these, inspired by Smalltalk, E has been designed to support
3) "live upgrade" -- for development and debugging work.
The clearest example is at the Elmer command line. An interactive E command
line interpreter already maintains a mutable OuterScope, so that top level
variables may be redefined. It should also maintain a behavior map, mutably
associating fully-qualified behavior with code (vTables). When a fully
qualified behavior name is redefined, this should *not* instantly upgrade
all old instances. Rather, it should queue a request to an upgrade service
for this vat, to perform all requested upgrades in its own separate turn.
These three forms of upgrade are defined so that they can avoid one of
Smalltalk's nightmares: what to do about old stack frames of methods of
objects that have been upgraded. In E, we have been careful to ensure that
the question cannot arise.