Hi--
I think there were some misconceptions about Spoon on the part of
both Igor and Andreas; I'll try to clarify.
Igor writes:
> ...i think, best would be to incorporate Spoon features to VM. As i
> understand (Craig, correct me if i'm wrong), a Spoon VM changes are
> incremental and not breaking any compatibility.
Andreas responds:
> I'm not sure which changes you mean. If it's about imprinting, I'm no
> fan of that. I don't want methods automatically transferred between
> images...
Imprinting is just the direct transfer of CompiledMethods from one
object memory to another (making source code, which in general is
ambiguous, an optional medium for behavior distribution). The scheme for
determining the content and timing of that transfer may vary.
One scheme is to transfer each method that a providing object
memory runs, immediately, to a consuming object memory (the case you
mention above, let's call it "session imprinting"). I see that as useful
in a presentation situation (at a conference, for example), where the
audience may want to receive the behavior the presenter is
demonstrating. Each recipient could then duplicate the demo later,
without having to spend any effort on installation. I think using this
facility, in coordination with *good unit tests* for the subsystem being
presented, would be very useful. But I wouldn't rely on it to organize a
system in normal development.
Another scheme, the one I'm working on now[1], is to organize all
the behavior of each system into clearly-delineated modules. Each module
can then imprint its methods onto a requesting system (nothing automatic
about it, necessarily). Each module can also describe its relationships
to other modules (dependency on other modules, containment of other
modules, etc.).
> ...I want tools that I can use in a remote image to load and edit code
> just like I do in the "main" image. With the end result being a
> well-defined set of packages that are designed to work together.
Right, this is what I intend.
Igor responds:
> I'm about marking oops while code running, to get a part of image
> which required to run your code and scrap the rest.
Andreas responds:
> Yes, and that's exactly what I'm no fan of ;-) In a realistic
> situation you'd really want to understand what is being used where -
> the fact that a particular method hasn't been touched during a
> particular run of the code is just as insignificant as the fact that
> during a debugging session you might touch code that isn't even in the
> product you're trying to design.
Again I think there's a misunderstanding here about the intended
purpose of a Spoon feature. Indeed, I never intended for "inert method
removal" (as I've been calling it) to be used frequently. I only
intended to use it once, to help derive the absolute minimal object
memory from which all other object memories would derive (there's still
some manual labor after that to get to the absolute minimal system).
After this has been done, and after there is a modularity mechanism to
enable the clear organization of larger systems, one shouldn't need this
facility anymore.
I suppose there will be a use for it whenever a system turns into
spaghetti (like Squeak is now :), but I think we can move past that.
Igor responds:
> Well, there is people who wish to see such capabilities, and if Spoon
> features orthogonal to your approach, then why not include them?
Andreas responds:
> ...I cannot see any situation in which someone would really want to
> rely on [inert method removal]. It seems to me that the approach is
> (as you said in an earlier email) a way to create smaller images
> "without much effort". I'm interested in the *hard* way of doing this
> (i.e., by going in and refactoring and removing things manually)
> because I think this is the only way in which it can be done in
> practice.
I think we're in agreement here. After creating a clearly minimal
object memory, and a module system for adding behavior while maintaining
clear organization, I'm interested in the hard work of deciding what the
content of those modules should be for the behavior we want to deploy. I
do think that session imprinting (defined above) could be useful for
finding a first approximation of what behavior is used by a subsystem
(e.g., Morphic).
> I just happen to think that the mechanism is fundamentally flawed and
> cannot possibly work the way in which people naively think it ought to
> work.
The mechanism, when used for its intended purpose, is sound. I
wholeheartedly agree that some have misunderstood its purpose.
> But be that as it may - the real question is this: Let's assume we
> have a tiny kernel image that is about 100k in size and that we can
> build up from. What good is the mechanism at this point? It seems to
> me that it is only useful to get to a small image but once this is
> achieved it's basically obsolete.
That is my fervent hope. :)
> And I'm definitely not in favor to modify the VM for something that
> will only have a very short window of usefulness.
Again, I think the changes do not increase the complexity of the
virtual machine in any meaningful way. These are minute changes to the
garbage collector, which is already so complicated that you can count
the number of people who even dare to look at it on one hand. :) (I'd
like to change that situation, by the way.) Furthermore, since the
usefulness of the changes during that short window is so high, and there
is the unfortunate possibility that the ability may be needed again in
the future, I think they would be justified even if they did impose some
significant increase in complexity.
Finally, the new garbage collector behavior is accessed through a
function interface which is separate from the normal one; the normal
garbage collection behavior is unaffected and the new behavior is
optional (one invokes fullGCDisardingInertMethods and
incrementalGCDiscardingStaleMethods instead of fullGC and incrementalGC.
In turn, these new functions invoke distinct mark phase behavior.
thanks!
-C
[1] This is "Naiad" (short for "Name and Identity Are Distinct"),
Spoon's module system. Naiad has been my prime motivation for Spoon
from the beginning; it's my attempt to resolve what I have always
seen as Smalltalk's biggest shortcoming: poor support for deployment
in general and modularity in particular.
--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]
