Subject: Types and remote objects
From: Keunwoo Lee (klee@cs.washington.edu)
Date: Sun May 06 2001 - 13:51:11 PDT
Had an idea in the shower this weekend, and I thought I'd share. No
telling if it's silly or not yet, of course.
One-line summary: type inference for location of distributed objects.
Elaboration:
There seems to be an intuitive similarity between the "allocation regions"
in the Tofte/Talpin paper, which we read in Manuvir's class, and nodes on
which computations (and/or objects) occur in a distributed system:
+ A value "lives" in a region, and an object can "live" on a node in a
distributed system.
+ If you want to perform an operation on a value in a region, a handle
("put tau"/"get tau") will be inferred as part of your type. If you want
to send a message to an object in a distributed system, you must have a
handle to that object's node. Etc.
Perhaps we can leverage type inference to perform (semi-)automatic
distribution of constructed objects among nodes, while keeping critical
message sends local and efficient. Here is a proposed mechanism:
+ Objects allocation sites are optionally annotated with nodes/regions.
+ Methods are either "local" and "remote", where "local" methods must be
invoked by a local object and "remote" methods may be invoked by remote
objects. Sending a message whose type contains "local" induces an
equality (subtyping?) constraint on the "location" types of the receiver
and the sender.
+ Object mobility (moving from node n => node m) is modeled as a type
conversion function. Mobility performs a fresh copy; intuitively, the
copy should be destructive--- perhaps a linear type would be useful here,
to make sure the old object is cleaned up?
+ Leverage parametric polymorphism to parameterize classes with location
types. A Collection<L> of objects, for example, may contain objects that
live only on node L.
+ Only a subset of methods/allocation sites need to be annotated; type
inferencer will do the rest.
The ways to determine the policy are the usual:
+ Programmer annotates some subset of methods with "local" or "remote",
annotates some assignments with location conversions, and annotates some
allocation sites with a location on which to spawn the object.
+ Compiler uses heuristics and language rules. Profiling of the
application determines which message sends are performance critical.
Methods are annotated appropriately.
Questions:
+ What is the problem I am solving? I don't know enough about how
distributed systems are programmed to know whether this will even solve
any problems. Presumably programmers want a lot of control over where
objects are located. Beyond that, I don't know.
+ Previous work? There has been a *lot* of work on OO distributed
systems, but I don't think they use types as part of the distribution
mechanism. I think Hank Levy's Emerald, to take one example, made
location transparent but provided location-testing predicates ("islocal")
and explicit object mobility instructions ("move"). The
+ What power does this give you? I think a proper type system might give
you a way to do static, modular reasoning about where objects live,
whereas current distributed object systems may be either so transparent as
to inhibit reasoning, or so explicit as to burden the programmer. Of
course, I don't know much about actual distributed object systems, so this
is currently a fairy tale.
Note that in this e-mail I have phrased everything in terms of objects,
but it may be simpler to begin by talking about location inference in a
more ML-like context. I think all of the above still applies.
~k.lee
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Sun May 06 2001 - 13:52:08 PDT