[self-interest] Self/R not started yet - some plans

Jecel Assumpcao Jr jecel at merlintec.com
Tue Feb 26 15:40:44 UTC 2002


On Friday 18 January 2002 01:49, I wrote:
> The next two would require patching the C++ code, but I don't think
> they would be too much trouble:
>
>    5) primitive objects instead of primitive messages
>    6) the cache manager

Well, I have figured out how to do this without any virtual machine 
changes.

I can handle the difference in primitives between my hardware and the 
current VM by loading a "bootstrap snapshot" with Self code for all the 
4.1 primitive messages (over a thousand, by my count). That would 
include the parser, file stuff, graphics stuff and lots of low level 
stuff. This hardware+boot snapshot combo can than load a regular 
snapshot file and will work just like the VM written in C++.

When the regular snapshot tries to execute a primitive it will send a 
message starting with underscore to some object. That object is 
guaranteed not to understand it, causing a lookup error. This will be 
converted into a message to a global "adaptor" object which will give 
the desired result. I am counting on the compiler optimizations to 
short circuit most of this for future executions so that the 
performance won't be too bad.

Now about the cache manager, what it does is the equivalent of replacing

                    obj someSlowCalculationWith: arg

with

             cache96 lookup: obj And: arg IfAbsentDo: [
                          obj someSlowCalculationWith: arg ]

and also replacing some expressions that violate the assumptions behind 
a given cache, like

              myPoints <- list copyRemoveAll

with

              myPoints = (rawPoints).
              myPoints: p (cache96 flushAllWith: self. rawPoints: p).
              rawPoints <- list copyRemoveAll

While my initial idea was to change the VM to get these effects without 
actually changing the method sources (bytecodes, really), there would 
be no great performance advantage compared to the manual patching in 
the above examples. So one alternative is to implement this in the 
programming environment, just like copy-down slots. The programmer 
would see the expressions as they were before patching, but specially 
annotated (the lookup could be in green and the flush in red, for 
example).

The only complication is with expressions with non local returns (or 
that send 'value' to blocks that might have non local returns).

Just a quick note about why a "cache manager" is a good idea, in case 
anyone is wondering. Programmers waste most of their time writing code 
to save things to disk and load them back. If we have persistent 
objects, then we don't have to do that and applications become much 
shorter and simpler. So what is the second largest time sink in terms 
of programming time? Rewriting code that works but is slow into 
something that is faster. See the example in the first part of this 
paper http://www.dreamsongs.org/NewFiles/usedsf.pdf

I just want to be able to write code in an understandable way and then 
make it go faster with a few clicks of the mouse instead of a complex 
rewrite.

-- Jecel



More information about the Self-interest mailing list