[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Igor Stasenko siguctua at gmail.com
Sun Mar 1 11:13:57 UTC 2009


2009/3/1 Avi Bryant <avi at dabbledb.com>:
> On Sat, Feb 28, 2009 at 7:32 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>> I need to point out that unless the various communities can start building
>> their disparate and diverging images form a micro-kernel image I don't see
>> how improved execution technology is going to be adopted by the community.
>>  I'm working hard on a VM that will be potentially 10x the current Squeak VM
>> for Smalltalk intensive benchmarks.  This VM will be source code compatible
>> and bytecode compatible but likely it will not be image compatible as it
>> will use a streamlined object representation that doesn't use compact
>> classes.  The only way I can see this being adopted by the community at
>> large is if the community starts building images form microkernels.
>
> I'm not sure that's true.  Say it becomes yet another fork, separate
> (necessarily, at first, because it's a different image format) from
> all of the other forks.  As long as most packages can be loaded into
> it, it'll get used.  Maybe not by the people doing the forking (by
> Scratch, say, or Squeakland), but by the majority of us who have a few
> pet packages (in my case, Seaside, OmniBrowser, DabbleDB, etc) that we
> can load into nearly any Squeak image and feel at home.  I'm pretty
> happy to load those into a MinimalMorphic image this month, a Pharo
> image next month, and a Cog image the month after, if there's some
> compelling reason to do so - and 10x performance would certainly be
> compelling.
>
> A shared microkernel would be nice, but I don't think it's essential
> in the short term to drive adoption of a new technology.
>

It is essential in a terms of allowing evolution of VM as a regular
process, not as a single major blow which done once, then adopted and
frozen for the next 10 years (or more).
VM having a certain contracts with a language side, like object
formats, bytecode set, special objects and their slot positions, core
classes etc etc..
If you not follow the VM obligations on this - you can't declare your
image/work as a safe, stable environment.
And kernel image is the best way to ensure that all such contracts is
fullfilled. It serves to identify all such contracts, represent them
at language side and make them work.
Without kernel image, we doomed to wander in the dark, guessing , what
code needs to be changed to adopt new VM capabilities, and also keep
VM developers care much more about backward compatibility (often by
sacrificing the cool improvements, just because of fear that it will
not be compatible).


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list