[self-interest] dSelf - A distributed Self for JVM Platforms

[Jecel Assumpcao Jr]

On Thu, 08 Mar 2001, Robert Tolksdorf wrote:
> [being new to the list, I am not sure about conventions - if this
> should be answered directly, please tell]

It is best to use the list since the answers may be of interest to
other people.

> Have you tried to push the papers through the Altavista Babelfish?

Only the page commenting on the thesis. It is better than nothing, but
not by much.
  
> Concerning replication: Right now, there are two sorts of things in
> dSelf, the one are references, the others are primitive objects (such
> as the number 1). The primtive objects are located at _every_ dSelf
> VM, so in some sense, they are in fact replicas (one can also say that
> eg. the Java-standard classes are replicated on every JVM). Of course,
> true replica need some sort of consistency management, which we
> currently do not need, as primitve objects are immutable (cf. the java
> standard classes). There is going to be another diploma theses that
> deals with the issue. In fact, the work on it should start this week.

Any object that doesn't have assignment slots is effectively immutable.
You can replicate it without any worries about consistency. Most
"traits" objects are like that. I know that this sounds like the class
replication problem that you wanted to avoid by choosing Self, but at
least it is less hidden in this case.

One problem in Self is "prototype corruption". If you do the web
tutorial, for example, and start changing the circleMorph itself
instead of a copy (very easy to do) then you will break the system. My
solution was to make the system multiuser - the circleMorph prototype
doesn't belong to you and the system doesn't allow you to modify it. If
you make a copy, that belongs to you and you can change it. In the case
that you really need to modify the prototype itself, it is just a
matter of logging in as its owner. So you can still do it, just not by
accident.

In this multiuser Self most of the object in the system can't be
modified by the current user. Neither can they be modified by the user
in the workstation to the right. So I can allow all these objects to be
replicated on both machines without having to worry about consistency.

> My view is that we should introduce something like in Replicated Obliq
> by MacIntyre, where remote, replicated and simple (ie. primitive)
> objects are distinguished and the environment offers means to change
> the "class" of objects along those three kinds.

That is a good option, though I prefer a less explicit solution when
possible.

> we should have mentioned (and might add a footnote), that these
> examples use a pseudo code. The reason for that was to show simple
> code instead of lots of _addslots messages whose explanation would
> have cluttered the flow of the text.

Pseudo code is good, but the difference between data slots and constant
slots should have been reflected in the code.

> We currently have this ad-hoc solution with locking objects. The
> mentioned diploma-thesis shall also deal with the issue of finding a
> suited model for concurrency in self and implementing it. in dSelf, we
> have implicitly concurrency by two people (or a shell) starting two
> dself-VMs that then do run concurrently, although there is no forking
> within a dself vm.

See tinySelf 1 (and the "wait by necessity" model in the differences
page) for lots and lots of forking:

   http://www.lsi.usp.br/~jecel/tiny.html

My model was too strict and couldn't handle recursion at all, so I
explicitly relaxed it for this case. Tail recursion was optimized away.
I also wanted to handle immutable objects specially in the future, but
didn't get around to that.

On the other hand, my model wasn't as strict as the Eiffel version of
"wait by necessity" (they lock all the arguments to a method and not
only the receiver like I did) and so it was possible to write buggy
code. I handled blocks differently to eliminate the most common cases
of this.

The real solution is to have a good model of state. And that is very
hard in Self. Is an object's state the values of its data slots? Of its
slots and those of all of its ancestors? Of itself, its ancestors and
of all of the other objects that it points to? Information is read from
the object, changed and put back into it. This must be an atomic
operation, but I haven't figured out how, yet.

David P. Harris asked about the jar file. It is (mostly) a regular ZIP
file - WinZIP or similar should be able to extract what is inside if
you are more interested in taking a look than actually running it.

-- Jecel