I would rather not say anything until tinySelf was
available for downloading, but as almost a year has
passed since it was promised "in a couple of weeks"
I feel I owe the people who are waiting an explanation.
Donald Knuth says that premature optimization is the root
of all evil. That certainly has been the case here. I
have wasted a lot of time undoing such smart ideas as
combining objects (like futures, messages and contexts),
using fields in objects to link them into lists (instead
of explicit list objects), combining the scheduler and
the C "trampoline" routine and so on. Each of these seemed
to save a little memory and some coding, but eventually
bloomed into a lot of extra coding to cope with all the
weird corner cases that kept cropping up.
A major source of the delay has been the need for me to
think things out in order to make tinySelf "tiny". There
were two mechanisms for primitives: special objects
(like the cpu object, renamed runtimeAbstractionServices,
which allows you to mess around with the MMU and things
like that) and 27 extended bytecodes. I have now
eliminated the extended bytecodes. There were three
different message passing models: user level messages
(with futures and blocking and reflection...), micro
messages (which combined to implement the first type,
they were more like parameterized coroutines) and
inlined messages (not implemented in the interpreter,
but present in the model to handle a compiler in a
future release). Though it took me quite a while to
figure it out, inline messages now have the same
semantics as all user messages, and some "hand inlining"
has eliminated the micro messages.
Finally, I have been unable to resist a few new
"premature" optimizations:
- By using the StackThreads scheduler[1] instead of a
simpler one, most of the heap allocation of contexts
is avoided. This makes the unification of message
models, described above, more practical.
- The idea of multiple vtbls in [1] was already being
used in tinySelf as "map switching" to handle the
conversion from futures to contexts (this has
changed a little). This can be used, with a small
overhead in terms of memory, to eliminate the cost
of dynamic inheritance for objects that use it, and
greatly decrease the cost for objects that inherit
from them.
- Excessive customization is the main reason Self 4.0
is such a memory hog. I have a "shared header"
scheme that (I hope) will detect for which cases
customization is worth the costs. This technique
also doubles as a very fast message dispatch for
the interpreter.
[1] "An Efficient Implementation Scheme of Concurrent
Object-Oriented Languages on Stock Multicomputers"
Kenjiro Taura, Satoshi Matsuoka and Akinori Yonezawa
Proceedings of the 4th ACM PPOPP, May 1993, pp. 218-228
see http://web.yl.is.s.u-tokyo.ac.jp/
--
-----=============( Jecel Mattos de Assumpcao Jr )===========-----
http://www.lsi.usp.br/~jecel/merlin.html | mailto:jecel@lsi.usp.br
