2008/8/7 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> 2008/8/7 Andreas Raab <andreas.raab at gmx.de>:
>>>
>>> This doesn't work (try it sometime). It is impossible to create an empty
>>> metaclass hierarchy since you can't send any messages to it. Which is why
>>> you need a simulator to do it because the simulator can operate on the
>>> data
>>> structures without requiring any of the objects to understand any
>>> message.
>>> Most of the steps in your proposal have similar fundamental flaws (like
>>> creating "new" SmallInteger instances etc).
>>>
>>
>> Oh, come on!
>
> Your line of argumentation reminds me of the old S. Harris cartoon:
>
> http://www.sciencecartoonsplus.com/pages/gallery.php
>

Yeah, this discussion worth very little without practical and working examples.
Lets then wait till i have a working example - the best argument.

> The problem is that you simply cannot have an uncontaminated environment
> without the simulator. It is trivial to show: Since you cannot manipulate
> objects without sending messages, you will *necessarily* have to send
> messages from the "old" to the "new" objects while the new environment is
> being constructed. This *necessarily* implies that the classes, metaclasses,
> literals, and methods of the "new" environment will start out as instances
> of the "old" environment. There is simply no way around this.
>

So, what is wrong with it?
A literal, like string carries just a buch of bytes. Unless you change
the object memory format, you will get the very same object at the
end.
An object who referencing to other objects can be pruned to contain
references only to objects in "new" environment.

Things can be contaminated if compier & image-building tools do not
creating objects directly but instead using an abstract environment
for this.
In this way, a Compiler is not responsible from creating new objects
(CompiledMethod, literals etc) - but environment object instead.
And depending on environment you can instantiate new objects in same
object memory or 'instantiate' them in simulator's bytearray.

I've used this model of compiler who speaks with environment to
bootstrap & instantiate a simulated object memory in CorruptVM
project.
Needless to say, that it works well and producing a functional object
memory as result, completely independent from environment where it
created (in a sense that it knows nothing about things which liying
outside it).

> And that ultimately means that what you're creating is just a (modified)
> clone of the old environment not an environment that I would consider to be
> created from "first principles" (note that I'm not saying that such a clone
> might not be useful, I'm just not interested in yet another cloning
> approach).
>

If we envision a process of creating new image as:

a) defining object formats
b) defining a set of objects which will be included in new image &
relations between them

then unless you changing formats, you can trivially use the very same
'old' heap for holding new objects - i see nothing wrong with it. In
the end what the difference between a bunch of bytes lying in VM's
heap and bunch of bytes lying in simulator's bytearray?


> Cheers,
>  - Andreas
>

-- 
Best regards,
Igor Stasenko AKA sig.