Hi,
yes this is cool :)
There is also a new smart student that will work on this infrastructure a
bit to make it "normal developer friendly", you know, hiding some
implementation details, making maybe a UI for the process and so on.
Now, about the questions:
- And how much smaller could the image get if the class builder was removed?
Well, as Pavel says, you can get for example 10K. You can get even less
if you tweak it manually. Around 10k is the minimal required by the VM to
run a full featured image (at least in cog 32 bits, I did not measure it in
Spur). Imagine that the VM requires at least:
* one process scheduler
* one process in that scheduler
* one context on that process
* one method on that context
Then, the VM requires some information to interact with the runtime,
e.g.,
* what is the selector used for doesNotUnderstand: (yes, we can change
it!)
* what are the first 256 character objects in the Character flyweight
* what is the class of SmallInteger immediate instances
* some special/optimized selectors
My automatic process generated a somewhat 10k of objects required for
this VM/image interaction.
Of course this list changes a bit with Spur, and could be reduced (for
example, if you don't use characters, you wouldn't need the character
flyweight and so on...)
- Is it future approach for bootstrap? (with respect to the 10k image)
Well, if you read my thesis, what I'm doing there is to lazily pick what
classes and methods will go inside an image. While this is nice to
experiment, I do not think It's a good approach for bootstrapping:
* you need to exercise/execute all possible cases your image needs to
support
* and that means you need to know all those cases in advance
* and that you have to be careful with side effects
Otherwise, code not executed is not taken in the resulting image.
Also take the fact that changing a little line of code may result in
bootstrapping an image a couple of times bigger because of a wrong
dependency.
All these points make this approach less reproducible and a bit more
complicated. I prefer an explicit list of packages to bootstrap, that we
can control and really test the output :)
Also, as Igor says, we could be able to generate an image without a class
builder, as we are able to generate an image without a compiler. But we do
not want to. Because that is an image that we cannot almost interact with.
We cannot load code inside. So the more interesting question is where is
the balance between space and functionality.
BTW Pavel, this approach may need to be updated but I think we could make
it run on top of the simulator also ;).
- How faster or slower bootstrap process with it?
They are not really comparable. They do not use the same infrastructure,
nor the same process, and they do not generate the same results.
The 10k image is of course generated in a matter of seconds, but a 600k
image containing the seaside counter may take half an hour.
In our current approach, the speed of bootstrap is directly related to
the number of classes and methods inside the result. There are two ways to
speed up the process:
- by speeding up the ast interpreter (or replacing it by a compiled
version of it)
- and by cleaning the kernel
Guille
On Fri, Feb 24, 2017 at 9:15 PM, Igor Stasenko <siguc...@gmail.com> wrote:
>
>
> On 24 February 2017 at 21:01, Pavel Krivanek <pavel.kriva...@gmail.com>
> wrote:
>
>>
>> 2017-02-24 17:17 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>:
>>
>>>
>>> 2017-02-24 16:36 GMT+01:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>>
>>>> The "guest" object memory runs in a special virtual machine simulator
>>>> during the bootstrapping. That simulator uses AST Interpreter to execute
>>>> the code inside the guest environment before it is installed for real. It
>>>> uses own special kind of proxies and tricks to do it. The current bootstrap
>>>> cannot run without class builder in the guest environment, but...
>>>>
>>>>
>>>>> And how much smaller could the image get if the class builder was
>>>>> removed.
>>>>>
>>>>
>>>> ...Guille in his thesis tried different approaches and he was able to
>>>> produce extremely small images (~10 KiB) that did for example only a sum
>>>> of two numbers.
>>>>
>>>
>>> Is it future approach for bootstrap?
>>> How faster or slower bootstrap process with it?
>>>
>>
>> That's more question for Guille, but I do not think we will adopt this
>> approach of bootstrapping in near future because it needs to be updated for
>> the Spur format and it needs a special VM modifications. And the question
>> is how much is it really needed because if you want to do something with
>> the image, you will anyway need most of methods needed for the class
>> builder like basic strings and collections support.
>>
>>
> I think, you can shrink image even more, by running something after
> booting it to remove ClassBuilder & co, if you don't need to create classes
> etc.
>
> --
> Best regards,
> Igor Stasenko.
>
