2009/3/1 Avi Bryant avi@dabbledb.com:
On Sat, Feb 28, 2009 at 7:32 PM, Eliot Miranda eliot.miranda@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).