Spoon progress 15 April 2005: inert method deletion
details and next steps
Trygve Reenskaug
trygver at ifi.uio.no
Sat Apr 15 06:10:24 UTC 2006
This is really important work. You create an opportunity to evolve a better
and even readable Squeak to the great benefit of all.
I remember that there was a study a long time ago to compare how long it
took to become proficient in C++ and Smalltalk. The answer was the same in
both cases - about one year. The reason for the unexpected Smalltalk result
was that a person needs this long to become familiar with the class library.
Congratulations, Craig. Keep up the good works
--Trygve
At 01:33 15.04.2006, Craig wrote:
>Hi all--
>
> Now that I've been living with it for a while, here are a few
> details on the shrinking technique I mentioned a couple of months ago
> (where methods that haven't been run recently get reclaimed by the
> garbage collector). Also, at the end, are some notes on what I'm doing
> now and my next steps.
>
> When I did the earlier imprinting work, I added two bytes to the
> compiled method trailer format. One bit in those bytes indicates whether
> the virtual machine has run the method (the other fifteen are for
> recording the method's linear version). I changed the virtual machine to
> set that bit every time it runs a method. By clearing that bit on all
> methods, then examining them later after running the system for some
> duration, one can tell all the methods which were run over that duration.
> A method without that bit set is "inert".
>
> I extended the garbage collector with an alternative mark phase
> that doesn't mark or trace inert methods (with the exception of methods
> associated with currently-active contexts). References to inert methods
> are replaced with nil. This leaves some method dictionaries with nils
> where methods used to be.
>
> My typical development mode so far has been to use a "full"
> object memory equipped with remote-messaging tools to control a target
> object memory over a network. This lets me make changes to the target
> with impunity. In particular, I don't have to worry about the target
> getting wedged because I've broken the user interface, because I'm using
> another system's user interface. I've got a remote system browser,
> debugger, process browser, and workspace. The remote system browser uses
> the master system's compiler, and transfer methods directly into the
> target, so the target need not have a compiler (or ClassBuilder). No
> class names are ever exchanged between master and target, and source code
> is completely optional.
>
> I changed the target system's Object>>doesNotUnderstand: so that,
> before raising an exception, it first attempts to install the missing
> method from the connected master system. If installation is successful,
> it resends the method and carries on. I changed method lookup in the
> virtual machine so that when a nil is encountered where an inert method
> used to be, it is handled as a message-not-understood. So, the master
> system effectively acts as a virtual memory for the target, providing
> missing methods inline as they are encountered.
>
> In the past (before the garbage collector changes), a new target
> system was created as a copy of the master system. I would then connect
> master and target, and use the remote tools in the master to shrink the
> target manually. I've done two passes that way; the first took three
> months of work in 2003, the second took two weeks of work in 2005. The
> reason I've made multiple passes is that I kept realizing significant
> system features I'd forgotten to include before I started shrinking
> (e.g., remote debugging), and it'd be much more work to retrofit it into
> the target than to just shrink a new master copy. Since there will
> probably always be new fundamental things to add, I decided I ought to
> just make the shrinking process more automatic.
>
> Now I've got a class in the master that can automatically gut the
> target in 30 minutes. It invokes code in the target that can throw out
> entire "inert classes" (classes which have no references and no non-inert
> methods). I got rid of the entirety of Morphic this way, for example,
> without having to understand anything about how Morphic works.
>
>***
>
> In January I wrote a module-aware webserver for the target, to
> which the web-based Spoon installer will redirect the user after
> downloading and starting the system. The user will then be able to
> discover and select modules to load and unload, make snapshots, quit,
> etc. Currently I'm working on a Naiad module which installs the
> ClassBuilder (for manipulating existing classes in the target). (Naiad is
> Spoon's module system.)
>
> After that I plan to:
>
>- make a module which installs every last bit of 3.8 final, just to
>show that one can recreate familiar old systems
>
>- make modules which install the VM construction tools
>
>- make a VM from a Spoon system with those modules in it
>
>- throw away the VMs and object memories that I started with!
>
>- make modules for other things I want to use (Quoth, Chronos,
>Weather on Display, Tweak, etc. etc.)
>
>
> Ideally, I'd like the new modules to contain well-factored and
> highly-readable expressions of the ideas of the old subsystems, rather
> than just blind repackagings, but we'll see... it's tempting to just
> imprint things to save time. :) (For more about imprinting, see [1].)
>
>
> thanks,
>
>-C
>
>[1]
>
>http://lists.squeakfoundation.org/pipermail/spoon/2004-October/000061.html
>
>--
>Craig Latta
>improvisational musical informaticist
>www.netjam.org
>Smalltalkers do: [:it | All with: Class, (And love: it)]
>
--
Trygve Reenskaug mailto: trygver at ifi.uio.no
Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver
N-0378 Oslo Tel: (+47) 22 49 57 27
Norway
More information about the Squeak-dev
mailing list
|