[squeak-dev] re: producing minimal systems (was "MicroSqueak")

Craig Latta craig at netjam.org
Tue Mar 3 06:58:35 UTC 2009


Hi--

      Ah, another day, another omnibus response. :)

      Eliot writes:

 > Surely repeatability mandates that one roduce an object memory
 > statically and then set it running?  Because of things like delays the
 > always running memory is almost never in a predictable state, so one
 > always ends up with different bits even if they represent the same
 > functionality.

      Sure, but that's all I care about: something minimal for a given 
set of functionality (in my case, loading the next module). I've made an 
initial memory from which others can be made by loading modules. If I 
need to make a new initial memory for some reason, I don't care whether 
it has every bit in the same place, but I do expect it to have the 
equivalent objects fulfilling equivalent roles.

      I'm after repeatability of functionality without excess. So, no, 
repeatability doesn't mandate producing an object memory statically from 
within a host. Simulation was the first thing I tried. In my experience, 
it has been much easier (although still not a walk in the park :) to 
avoid simulation for this purpose and use remote messaging on a real 
object memory instead. I do, however, run the minimal memory in the 
interpreter simulator occasionally, to debug and produce visualizations[1].

 > ...perhaps a better alternative is just to use Hydra and provide a
 > remote debugging interface to another Hydra space.
 >
 > ...
 >
 > How about the remote debugging?  How minimal is the debugging stub
 > that must exist in the spawned MImage? Would one need VM changes...?

      Just a reminder at this point that Spoon has remote debugging 
between object memories, with support for context stacks spanning 
multiple physical machines. It uses remote messaging, which uses a small 
change to the VM's method lookup, but otherwise no special VM support is 
necessary. And no need for a myriad of shadow classes (MBoolean, 
MockContexts, specialized parsers, et al).

      Igor writes:

 > ...there is a lot of synergy with Spoon. People point this out from
 > time to time.

      Yes, this would be one of those times. :)  I only wish that I 
could have finished this while I was on break, or that I could be 
employed to do this. :)

      Janko writes:

 > A question from someone not so [knowledgeable about] Smalltalk
 > internals: is Spoon compatible with the proposed MicroSqueak? That is,
 > can it be Spoon based on top of MicroSqueak?

      I haven't seen any indication that MicroSqueak is actually 
minimal, so I'm not sure why one would want to do that. It seems like 
Spoon and MicroSqueak are two fundamentally different approaches. Spoon 
isn't really something that runs "on top of" something else; once you 
add anything more to it, it's not minimal anymore.

      Now, if instead you meant Naiad (Spoon's module system) and Other 
(Spoon's remote messaging framework)... sure, those will run in any 
Smalltalk. They have to, in order to provide a convenient way of moving 
code between old and new systems.

      Stephen Pair writes:

 > Maybe you could get the repeatability with a process that is
 > roughly...

      Hmm, didn't you just write that, and didn't I respond that I'd 
already done an equivalent thing? :)

      Jecel writes:

 > You are probably aware of the type inference work Ole Agesen did in
 > Self?

      Yes, thanks!

      Igor writes:

 > I having a similar idea to capture methods/classes while running code
 > to discover what objects i need to clone into separate heap to make it
 > running under another interpreter instance in Hydra.

      Göran responds:

 > Mmm, you are aware of this stuff that Craig has in Spoon right? The
 > "imprinting" stuff IIRC.

      (Thanks, Göran!)

      Igor responds:

 > sure, I'm aware of that. Craig using changed VM to mark methods while
 > code running. But one could do much the same using already awailable
 > tools. Yes, it will be slower, but this process (shrinking) don't have
 > to be performed regularily, so why care.

      True, imprinting uses method activation marking, but imprinting 
has nothing to do with shrinking. Imprinting is useful for transferring 
methods from one object memory to another as they are run, in real-time. 
If the marking weren't done in the VM, it wouldn't work. Given that, it 
really was easiest to just do shrinking with a slightly-modified version 
of the garbage collector. I think it makes a lot of sense.

      But speaking of shrinking, I'll just reiterate the most extreme 
result so far, a 1337-byte object memory[2], suitable for t-shirts...

      As an aside... I'm still amazed at how apprehensive people are 
about modifying the VM, after all the time Squeak's been around. The 
relative ease with which one can do it, with the ability to debug using 
Smalltalk tools, is one of the main compelling things about the system. 
It lets us just go ahead and change the VM *if that's what's 
appropriate*, rather than try to work around it as with previous 
systems. (True, it can be much easier still... and we'll get there 
faster if more people dive in.)

***

      Finally, an obligatory repetition of what I'm working on now: I'm 
implementing Naiad, Spoon's module system[3]. I have a headful object 
memory with editions in it describing its classes, methods, modules, 
etc. (see [3] for terminology). I have a minimal object memory, and I 
have another headful memory with tools in it for manipulating memories 
remotely (remote system browser, remote inspectors, remote debugger, etc.).

      Both the minimal memory and the tools memory can connect to the 
history memory and use that instead of a changes file. I can do 
traditional things like looking up versions of a particular method, but 
also more sophisticated queries (for example, methods written by a 
particular author over some time period, removed over some other period, 
and that access a particular instance variable).

      My current task is creating a minimal history memory, to go along 
with the minimal memory. I'm transferring editions for all the 
components of the minimal memory into a copy of the minimal memory, and 
fixing bugs that I uncover in the process. Then I'll have the pieces of 
the next Spoon system: a minimal object memory, and a minimal history 
memory that describes it. I will release that, along with changesets for 
the remote tools that previous (3.2 to 4.0) object memories can use. 
Then people can start composing Naiad modules for all the behavior that 
I removed (e.g., graphics support).

      I've made several releases of Spoon in the past (most notably 
2004-02-14, 2005-12-11, 2006-10-25, and 2007-04-12), but every time the 
lack of the module system limited the pool of truly interested folks to 
a handful. Given how difficult it is to make releases before the module 
system exists, I've decided to focus on the module system (asking for 
feedback about the module system design[3] in the meantime). I still 
think it's going to be worth the time, and making it my day job would 
still speed it up.


-C

[1] http://netjam.org/spoon/viz
[2] http://netjam.org/spoon/smallest
[3] http://netjam.org/spoon/naiad

-- 
Craig Latta
www.netjam.org
next show: 2009-03-13 (www.thishere.org)





More information about the Squeak-dev mailing list