Spoon progress 23 May 2006: finding dependencies via passive imprinting

[Craig Latta]

Hi--

	Recently I made a module for installing ClassBuilder. (Conveniently, 
Spoon doesn't need ClassBuilder to install new classes, only to change 
old ones.) My first test was to add an instance variable to a class in a 
minimal remote memory. The newly-installed remote ClassBuilder itself 
behaved fine, but there were a few methods in the remote test class that 
needed to be recompiled. The minimal memory has no compiler, so that had 
to be swapped in from the control memory (which also has the GUI and 
tools I use to run the tests).

	Installing classes and methods into a minimal remote memory, inline as 
they are needed, is what I call "passive imprinting". "Active 
imprinting" is installing behavior in a minimal remote memory as a 
side-effect of running it locally where it already exists. I suggested 
in a previous report that only active imprinting is accurate, because a 
memory requesting methods for itself has no was to know if a method it 
can already run successfully actually has an override.

	The situation seems to have changed with the advent of the "method 
placeholders" I mentioned previously[1]. There are already placeholders 
in the current minimal memory for each method that hasn't been run since 
a certain point in time (the beginning of the most recent shrink), but 
whose class is still referred to by something (classes which have no 
references are simply removed entirely). As long as placeholders are 
installed for each overriden method when a new class is defined, passive 
imprinting now works with full accuracy.

	Anyway, since the minimal memory also has no source code at the moment, 
the method recompilation involved in my ClassBuilder test also needed 
the decompiler. I have the control memory set to mention the classes and 
methods it installs on the transcript. During the automatic installation 
of the decompiler, I noticed that DialogStream was getting installed, 
and, in turn, so was TextStream, Text, Form, Bitmap...

	These were things that didn't seem absolutely necessary for 
decompilation. I simply halted the test, noted the point at which 
unwanted dependencies were being invoked (MethodNode>>decompileString, 
which had also just been installed), and changed the offending method so 
that it didn't invoke the first unwanted prerequisite (DialogStream).

	This seems like a great way to find the dependencies between subsystems 
in Squeak!

	The advantage that this technique has over one using active imprinting 
is speed. With active imprinting, one must probe the remote target 
memory after every single local message-send, whereas in the passive 
case the target memory just runs methods without pause until it comes to 
a placeholder.

	A workflow for finding dependencies and using them to inform module 
creation is beginning to appear. It seems we mostly need to come up with 
a bunch of desired test cases, and the time to run them and watch for 
undesired relationships.

	And this whole project is starting to feel like a PhD I should be 
pursuing somewhere. :)


-C

[1]

http://lists.squeakfoundation.org/pipermail/spoon/2006-April/000107.html

-- 
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]