"imprinting" summary

Craig Latta craig at netjam.org
Mon Oct 18 23:39:14 UTC 2004


	This is just a summary of "imprinting", for those who find it
convenient to find one in the Squat mailing list archives. Such a
summary was scattered over a few messages before, with some obsolete
info. I haven't finished "the Squat paper" yet, but I'm working on it.


	I've implemented a means of transferring behavior from one object
memory to another, as it is invoked. The compiler is not needed, and no
special consideration need be made for any behavior. Here, by "behavior"
I mean compiled methods, including their instructions and all literals
(e.g., classes).

	The main benefit of this approach, as I'm using it now, is making an
application smaller by leaving unused behavior behind. (This is useful
because I want to minimize the download time of the resulting
snapshot.)  I can see other interesting uses as well; for example,
"behavior broadcasting", in people "tune in" to a running system (e.g.,
at a demo during a conference), and come away with all the behavior
needed to run the demo again for themselves. It's also a good way of
transferring unmodularized behavior from one place to another without
having to understand its architecture or dependencies.

	Another possible use is gathering information for dynamic type

	It reminds me a little of the first "Matrix" movie, where characters
have martial-arts or helicopter-flying skills imprinted onto them. :) 
But notice they didn't start fighting or flying before the imprinting
was finished. I call that "active imprinting". Consider a reversal of
the source/target relationship, where behavior is invoked at the source,
and imprinted into a target as a side-effect. I call that "passive
imprinting". I have implemented both kinds, but find passive imprinting
more useful (active imprinting has some fatal error modes, described
more in the Squat mailing list archives).

	The process occurs as source behavior is run and with multiple
concurrent targets. The source behavior is affected only in its running
speed; this speed currently improves over time via caching. The user
experience is similar to running the source behavior with a normal
virtual machine in many situations, and immensely faster than using the
simulator. I use an instrumented virtual machine which reports each
method as it is run, without reporting artifacts of the reporting
process itself. Communication between the source and target systems
happens via remote message-sending.

	In my current sessions, the source is a 3.6 snapshot, and the target is
a 2.2 snapshot. This encourages me that the technique will work between
snapshots of any vintage one is likely to desire. I have successfully
transferred, to "virgin" systems, a few notable low-level frameworks,
including the "dynamic bindings" and exception-handling frameworks. I
plan to make a release, so that others can try to find things that the
imprinting process can't deal with. In the meantime, I'd appreciate any
test suggestions.




Craig Latta
improvisational musical informaticist
craig at netjam.org
[|] Proceed for Truth!

More information about the Spoon mailing list