[squeak-dev] re: MicroSqueak
Craig Latta
craig at netjam.org
Mon Mar 2 05:20:31 UTC 2009
Hi--
Igor writes:
> ...any object/class which interfacing with core VM functionality
> should be in that hierarchy.
Heh, but that just shifts the question over to what exactly "core
VM functionality" is. There's a lot of cruft in th VM, too. And I happen
to agree about starting from a desired high-level task (that's exactly
what I did for Spoon). I'm suspicious of any process which doesn't start
from there.
> The rest is optional, since by having a compiler we could file in any
> code we want to.
Well, I prefer to install compiled methods directly without
recompiling anything, but sure.
Stephen Pair writes:
> Hmm, I think the key question here is: what do you want to be able to
> do with the image you create?
Sure, I personally think that should be where the process starts
(otherwise I suspect unnecessary things get included), but I'm
interested in approaches from that point that differ from mine.
> I've no idea how John did this, but I think I would start by writing a
> method that did all the things I'd want to be able to do in the image
> I ultimately create. This might be things like compiling a string of
> code, loading something from a file (or socket), etc...the bare
> minimum of things you'd absolutely need to do in a minimal image. Then
> I'd guess you could create a shadow M* class with this method in it
> and some sort of proxies for literals and global references. With a
> little doesNotUnderstand: magic I'd think you could run that method,
> hit those proxies and copy over other classes and methods as you hit
> them. I'm sure the devil is in the details, but this top level
method > that expresses exactly the things that you'd want to be able to
do in
> this minimal image seems like it would be an interesting artifact in
> and of itself. It would be in a sense a specification of this image.
This is roughly what I did with Spoon, although my tactic was to
mark everything in a normal object memory involved in a particular task,
then use the garbage collector to throw away everything else
atomically[1]. I like to have a known-working object memory at every
point in the process, by dealing with a running memory as much as
possible (rather than creating one in situ and hoping that it works when
resumed).
Igor responds:
> I have 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.
>
> Squeak already having facilities which can be used for this
> (MessageTally>>tallySends:). We just need to make some modifications
> to it, and as you pointed out, since we need a bare minimum, then
> capture things while running:
>
> FileStream fileIn: 'somecode.st'
>
> is a good starting point.
Right, although I think using the VM to do the marking is more
convenient, and faster.
Andreas writes:
> The alternative (which I used a couple of years back) is to say:
> Everything in Kernel-* should make for a self-contained kernel image.
Aha, yeah; I'm not that trusting. :)
> So I started by writing a script which would copy all the classes and
> while doing so rename all references to classes (regardless of whether
> defined in kernel or not).
>
> At the end of the copying process you end up with a huge number of
> Undeclared variables. This is your starting point. Go in and add,
> remove or rewrite classes and methods so that they do not refer to
> entities outside of your environment. This requires applying some
> judgment calls, for example I had a category Kernel-Graphics which
> included Color, Point, and Rectangle. Then I did another pass removing
> lots of unused methods which I had determined to be unused.
Yeah, that's a lot of work; perhaps on the order of work I was
doing earlier in the project, when I was removing things manually with
remote tools[2].
> At the end of the process I wrote a script that (via some arcane
> means) did a self-transformation of the image I was running and
> magically dropped from 30MB to 400k in size. Then I had a hard disk
> crash and most of the means that I've been using in this work were
> lost :-(((
Ouch! I'm sorry to hear that. That actually happened to me too (in
2005), but through a total coincidence I had a sufficiently-recent
backup to keep going. Several nice minutes of panic...
> I still have the resulting image but there is really no realistic way
> of recovering the process. Which is why I would argue that the better
> way to go is to write an image compiler that takes packages and
> compiles them into a new object memory. That way you are
concentrating > on the process rather than on the artifact (in my
experience all the
> shrinking processes end up with nonrepeatable one-offs)
Oh, I agree that shrinking is not something one should do to
produce deployment artifacts. I think it should be done to get a truly
minimal memory that can load modules, and then never done again
(although the way I do it is repeatable, for the sake of review).
As for whether to produce an object memory statically and then set
it running, or transform an object memory which is always running... I
think the resulting memory will need to load modules live anyway, so one
might as well do all the transformations that way. Perhaps this is
simply an aesthetic choice.
thanks,
-C
[1] http://tinyurl.com/2gbext (lists.squeakfoundation.org)
[2] http://tinyurl.com/bdtdlb (lists.squeakfoundation.org)
--
Craig Latta
www.netjam.org
next show: 2009-03-13 (www.thishere.org)
More information about the Squeak-dev
mailing list
|