[squeak-dev] Re: Hydra/Spoon
Andreas Raab
andreas.raab at gmx.de
Sat Feb 23 06:05:55 UTC 2008
Thanks for the clarification. There were indeed some misconceptions on
my end regarding imprinting and inert method removal.
Cheers,
- Andreas
Craig Latta wrote:
>
> 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)]
>
>
>
More information about the Squeak-dev
mailing list
|