[self-interest] dSelf - A distributed Self for JVM Platforms
tolk at cs.tu-berlin.de
Thu Mar 8 09:22:17 UTC 2001
[being new to the list, I am not sure about conventions - if this
should be answered directly, please tell]
Jecel Assumpcao Jr
> Wow! Congratulations on this excelent work!
> At a presentation I gave on Monday I was asked if any academic groups
> were working on Self implementations and I said "no". I am very glad
> that I was wrong about that.
> After reading the dself.pdf I would like to make some slight
> corrections. There were, in fact, previous papers on distributed Self
> but they were written in Portuguese and so wouldn't have been of much
> help to you. My key insight in the later papers was that not only
> primitive objects but any immutable objects could be copied without
> affecting the execution semantics. My system is a multiuser one and any
> any given "session" most objects (those belonging to other users) are
> read-only and can be replicated instead of using remote references.
Have you tried to push the papers through the Altavista Babelfish?
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.
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.
> Your use of "<-" versus "=" in slot declarations seems strange. I don't
> think that the stack examples are quite right: you change slots defined
> with "=" ("parent", for example). You use the "clone" method but it is
> not defined anywhere (you don't mention the traditional "traits
> clonable" object, for example).
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.
> Several of the things you mention as missing in dSelf were actually
> dropped in Self 3.0. I found it strange that you wrote that Self
> doesn't have local methods, but I just tried it in Self 4.1.2 and did
> indeed get the error: "syntax error - local slots not implemented yet".
> How strange.
We took 4.x as reference. The assumption of downward compatibilty
seems to be quite wrong...
> In tinySelf 1 I explored parallel (but not distributed) execution in
> Self but got stuck in trying to lock things automatically. It is not an
> easy problem to solve.
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.
> Once again: good work!
Thanks. [I include Kai in the cc, as he did the implementation and a
lot of design decisions]
> -- Jecel
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dr.-Ing. Robert Tolksdorf | Technical University Berlin _______ _
mailto:tolk at cs.tu-berlin.de | FB 13 - FLP/KIT - FR 6-10 (_ _ | |
http://www.cs.tu-berlin.de/~tolk | Franklinstr. 28/29 | | | | |
tel: +49-30-314-25184 (FR6071) | D-10587 Berlin / Germany `-' `---'
More information about the Self-interest