El Sun Jan 18 2015 at 1:53:51 PM, Craig Latta <[email protected]> escribió:
> Hi Stef-- > > > For your information guille produced pharo images of 11k for simple > > addition, 18k for large numbers. Also Seaside counter application of > > about 500k. > > Why so large? The simple addition image I made is 1k. > Haha, this already looks like a competition. I don't want to compete ^^. One explanation is that the tailoring process I use is generic and cannot anticipate whether the VM uses an object or not. That is, I start the tailoring process from an almost empty special objects array and an expression to execute. But that expression is arbitrary, it may contain a simple addition or start a seaside server. Then I ensure some objects that the VM uses directly in any execution, making ~10K of common denominator for almost any application (then 11k is ~10k of common denominator + ~1k of integer addition code ;) ). For example, I have to add the character table in the special objects array just in case a string is used in the starting-point-expression. The character table is 256 long: character table slots = 256 * 4 bytes = 1k characters = (8bytes headers + 4 bytes slot) * 256 = 3k that makes already 4k. Of course, for a simple addition you just need - a special objects array - a processor - a process - a context - the method for the context doing the addition - some SmallInteger class for the VM to check And voilá. That should be even smaller than 1K. But I lack support to detect whether the VM access directly an object or not. And adding that in the VM for a couple of kilobytes... I don't know, I have enough writing my thesis just now :). Then I have some other implementation details that make my images a bit bigger. I use for example a block to handle exceptions. I could remove that and make my object memories smaller at the cost of being less robust... In any case, the image just doing an addition is just the example that pushes the limits of *my* particular tailoring framework... But afterwards it has no other real usage :). > > Of course this is done in Pharo so it will not really be exciting for > > you. > > The minimal kernel isn't the exciting part, it's just a > prerequisite. The exciting part is the distributed module system > (Naiad). You need a minimal kernel for that to be practical. There is > nothing like Naiad for Pharo yet. > Well, not only. As Chris says, what the minimal kernel should ensure is that you can grow it. That may be through a distributed module system or another way to install code inside it. As we don't have such a module system, in our first steps we are generating a small image that contains only a compiler and a class builder. Cheers, Guille
