(Sorry for the resend, there was a rather egregious typo last time.)
Hi--
This is just a summary of "imprinting", for those who find it
convenient to find one in the Squat mailing list archives. Such asummary
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
inference.
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.
***
thanks,
-C
--
Craig Latta
improvisational musical informaticist
craig(a)netjam.org
www.netjam.org
[|] Proceed for Truth!
Hi--
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
interference.
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.
***
thanks,
-C
--
Craig Latta
improvisational musical informaticist
craig(a)netjam.org
www.netjam.org
[|] Proceed for Truth!
