2008/8/6 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> The process of picking objects, dealing with unwanted references,
>> cutting an object graph - all this is on hands of developers.
>
> And of course, all of this "picking objects, dealing with unwanted
> references, cutting object graphs" is exactly why this process has nothing
> in common with creating an image from first principles. It is just
> transforming one mess into another and not all what I am after.
>
> Cheers,
>  - Andreas
>

Okay, let me review the steps, how i seeing it with doing everything
in same interpreter without the need of simulation:

> Start with the interpreter simulator and a (literally) empty object memory.

Start with an empty IdentitySet, which will represent a set of objects
found in object memory to be created. All newly created objects which
we will want to see in our object memory will be put in this set.

> Read a series of class definitions (you can use either MC class defs or
> simply parse simple class definitions from sources) that are sufficient to
> define all of the kernel structures that are required by the running VM
> (incl. Object, Behavior, Class, Integer, Array, Process, CompiledMethod,
> ContextPart, Semaphore etc. etc. etc.).

- use a ClassBuilder, or add single method to Behavior to be able to
create the abovementioned classes, but without installing/registering
them anywhere (SystemDictionary etc) and treat them as anonymous
classes.

Also, we should create a 'shadow' dictionary which will represent a
future SystemDictionary and put these classed in new dict.

> At this point we have a skeleton of classes that we can use to instantiate
> all behaviors required by a running image.
>

- this statement is TRUE for newly created classes in such way.

> Next, make a modification to the compiler that allows one to create a
> compiled method in the simulator from a MethodNode (which should be
> straightforward since the simulator exposes all of the good stuff for
> creating new objects and instances).
>

Indeed, we have to change a compiler to use different environment than
default and use it for:
- creating new method instance
- creating new literal
- installing new method into given class

This is a simple and straightforward rewrite to replace all global
references used by compiler (like Array new: x), with messages sent to
environment (like env createArray: x)  for creating new objects:
strings, arrays, methods.
An environment object could pick proper classes for creating new
literals - by using previously generated kernel classes.

> Next, find a way of dealing with two issues: a) adding the compiled method
> "properly" (e.g., deal with symbol interning and modifying
> MethodDictionaries) and b) global name lookups performed by the compiler
> (since the image is prototypical we can't have it send actual messages; not
> even simulated ones ;-)
>

- not an issue. You creating a new MethodDictionary by sending a
(clonedSystemDict at: #MethodDictionary ) new , or 'environment
newMethodDictionary'.

> The latter issue is the only one that doesn't seem completely obvious which
> is why I would advocate that a bootstrap kernel mustn't use class variables
> or shared pools (in which case the lookup is again trivial since you know
> all the possible names from compiling the original structure).

This not an issue - all Pools, Globals could be created in same way as
everything - as instances of corresponding 'anonymous' classes.

> Lastly, do the bootstrap: Instantiate the first process, its first context,
> the first message. Run it in the simulator to set up the remaining parts of
> the kernel image (Delay, ProcessorScheduler etc).

same thing, except you don't need to simulate it (if you did
everything right, of course) - just send messages.

In result you will receive a fully isolated object graph, located in
same object memory. Except one thing - symbols, because we using same
symbols as in original image.
This is not a problem - we will substitute a Symbol class to new one,
during final cloning stage and include all symbols into new image.
An unused symbols will die by themselves, after few GCs running within
new image - because they are not referenced by anything except
SymbolTable.

-- 
Best regards,
Igor Stasenko AKA sig.