[squeak-dev] Hydra/Spoon

Craig Latta craig at netjam.org
Fri Feb 22 21:27:11 UTC 2008


      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.



[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
Smalltalkers do: [:it | All with: Class, (And love: it)]

More information about the Squeak-dev mailing list