This is a much more complex and challenging subject that you might think. There has been a lot of work done on this for many years, many approaches have been tried.
I am pretty sure that the people behind the Pharo Bootstrap project are aware of the existing literature. > On 21 Jan 2016, at 09:49, Peter H. Meadows via Pharo-dev > <[email protected]> wrote: > > > From: "Peter H. Meadows" <[email protected]> > Subject: Re: [Pharo-dev] [ANN] Pharo bootstrap > Date: 21 January 2016 at 09:48:23 GMT+1 > To: Pharo Development List <[email protected]> > > > On 20 January 2016 at 16:36, [email protected] <[email protected]> wrote: >> >> >> On Wed, Jan 20, 2016 at 4:19 PM, Peter H. Meadows via Pharo-dev >> <[email protected]> wrote: >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Peter H. Meadows" <[email protected]> >>> To: Pharo Development List <[email protected]> >>> Cc: >>> Date: Wed, 20 Jan 2016 15:17:59 +0000 >>> Subject: Re: [Pharo-dev] [ANN] Pharo bootstrap >>> Cool. Any chance someone can explain for beginners to understand >>> what's going on here? >>> Why is cleaning the image not as simple as running it and deleting any >>> object that wasn't used? >> >> >> The point is not to clean but to start with an empty object engine and fill >> it in with the minimum required core. > > But why should this not end up with the same end result? > One way is to start with nothing, and only add stuff we need to make > it run/boot, and the other way is to start with what we have, and > remove anything that is not needed to make it run/boot. In both cases > don't you end up with the same thing? > > >> Currently, the image is the result of an evolutionary process and rebuilding >> it from zero was not possible. > > I wonder if they thought about this when they created the first image. > Didn't they think 'hey, we should really have a way for anyone to > create new images from nothing'? Or was it just that they didn't get > around to making this tool? > >> This maes it possible to audit the whole build process, create different >> base image for various purposes (very small, headless with no UI objects at >> all, using the object engine in a completely different way that is used >> today). >> >> That makes the image the result of a fully reproducible process, from a file >> of zero bytes, to a file with a working image. >> >> That would make us master the whole chain. Today, there is still black magic >> in the image, due to the history. >> >> That's an exciting development. For example, in C, one compiles all files, >> and links, giving the exe. All that from a file of zero size. We will be >> able to do the same kind of thing at the image level. >> >> Also, this allows to experiment with new low level mechanisms. This is >> currently not possible since it makes us like performing surgery on our own >> brain. Also, the Oz-inspired system will help in exploring other image >> memories (small or large) and manipulate them as entities. At this point, >> this is also not common pratice. >> >> HTH >> Phil, wishing to master the mitosis competency... >>> >>> >>> (Thanks in advance) >>> >>> On 20 January 2016 at 12:52, Guillermo Polito <[email protected]> >>> wrote: >>>> Well, there is no formal specification… But I could summarize the >>>> features >>>> as follows (and as Christophe points mostly out) >>>> >>>> OzVM supports having two images in logically separated spaces. This >>>> separation is achieved by using the free bit in the object header. Thus >>>> we >>>> support only two spaces by now. >>>> >>>> - The main addition is actually a new primitive: >>>> #resumeFromSpecialObjectsArray that receives an special objects array as >>>> argument and: >>>> - resumes the execution from the active process of such array >>>> - on context switch, if the VM is running from a second special >>>> objects >>>> array, it will return to the first one instead. >>>> >>>> - fixes to primitives/bytecodes that assume a single special objects >>>> array. >>>> e.g., >>>> - #someObject and #nextObject should only iterate objects from the >>>> correct “space” >>>> - #isNil comparisons should take the correct nil >>>> - the GC should set the correct nil object on Weak containers >>>> >>>> The extensions I made are about 20 overrides to StackPrimitive and >>>> NewObjectMemory methods. >>>> >>>> The rest is implemented completely on image side. We use mirror >>>> primitives >>>> to manipulate objects from other space (as each image/space has it’s own >>>> selector table). >>>> >>>> I have in my long TODO list see if the "clever hack” I did can be >>>> supported >>>> in a nice manner on top of Spur’s segmented memory. However, I should >>>> stop >>>> commencing new projects and start finishing them :P. >>>> >>>> On 20 ene 2016, at 9:03 a.m., Christophe Demarey >>>> <[email protected]> wrote: >>>> >>>> Hi Eliot, >>>> >>>> Le 19 janv. 2016 à 19:29, Eliot Miranda a écrit : >>>> >>>> Hi All, >>>> >>>> great news! Where can I read a specification of the Oz VM >>>> facilities? >>>> >>>> >>>> I do not know all the details of the Oz VM but basically, it is a >>>> standard >>>> stack interpreter vm specialized to be able to run 2 images at the same >>>> time >>>> on top of it. >>>> Guillermo made it possible by using one available bit in the object >>>> header >>>> of objects to mark the ownership of an object (e.g. is my object from >>>> image1 >>>> or image2?). Then, he mainly had to specialize VM primitives dealing >>>> with >>>> objects retrieval from memory. By example, he had to modify the garbage >>>> collector to set the right nil instance (yes, we have 2 images so 2 nil >>>> instances. we need to take the one of the active image) when an object >>>> is >>>> garbage collected; the primitive someObject has to return an object from >>>> the >>>> active image, etc. >>>> There is also a way to switch execution from an image to the other just >>>> by >>>> switching the special objects array reference. >>>> >>>> You can find some information in: >>>> https://guillep.github.io/files/publications/Poli15Thesis.pdf. >>>> The Oz code is in http://smalltalkhub.com/#!/~Guille/ObjectSpace and in >>>> https://github.com/guillep/OzVM >>>> The current implementation uses Cog 6.6.1and OzVM-GuillermoPolito.22. >>>> I do not know if Guille has a more formal specification of the Oz VM. >>>> >>>> If you have advices on what is the best way to handle two distinct >>>> object >>>> (memory) spaces in Spur, they will be welcomed :) >>>> >>>> Cheers, >>>> Christophe >>>> >>>> >>>> _,,,^..^,,,_ (phone) >>>> >>>> On Jan 19, 2016, at 6:29 AM, Christophe Demarey >>>> <[email protected]> wrote: >>>> >>>> Hi all, >>>> >>>> In case you do not know, we work on bootstrapping Pharo, i.e. create a >>>> Pharo >>>> image from sources, not based on a previous image (well, we use a pharo >>>> image to produce it but no code / state from it). >>>> >>>> This process will allow to define a minimal Pharo kernel (currently 52 >>>> packages but we could have it far smaller) and to modularize the whole >>>> image >>>> (currently packages have too much dependencies on packages already >>>> loaded >>>> into the image). >>>> The bootstrap process also allows to write down the recipe to initialize >>>> a >>>> new image from scratch (some code is missing in the image or is wrong). >>>> In >>>> addition, I think we will clean a lot of historical objects that are not >>>> used anymore. >>>> >>>> With the amazing work done by Guillermo Polito during his Phd (around >>>> Espell, Oz): >>>> https://guillep.github.io/files/publications/Poli15Thesis.pdf, >>>> we succeeded to get a first prototype of a bootstraped Pharo 5 image >>>> (from >>>> 5.392). >>>> This prototype is able to run an eval command line handler and to log >>>> output >>>> / errors. Not all classes are yet initialized and you cannot yet save / >>>> restart this image but it is a big step forward. >>>> It is a 4 mb image (could be half the size without unicode data). You >>>> can >>>> download it at: >>>> >>>> http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/pharo-bootstrap/pharo-bootstrap.zip. >>>> >>>> Next steps are to have a bootstrapped image fully working, then to load >>>> packages on top of it (like network, sunit) to produce a minimal image. >>>> Then, we need to implement an Oz VM on top of Spur. >>>> After that, we need to work on a reliable way to build the bootstrap >>>> (not >>>> too sensitive to changes in the image). >>>> >>>> Christophe. >>>> >>>> ------- >>>> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >>>> ../pharo >>>> bootstrap.image --no-default-preferences eval "1 + 1" >>>> 2 >>>> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >>>> ../pharo >>>> bootstrap.image --no-default-preferences eval "'a' , 'b'" >>>> 'ab' >>>> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >>>> ../pharo >>>> bootstrap.image --no-default-preferences eval "1 / 0" >>>> ZeroDivide >>>> SmallInteger>>/ >>>> UndefinedObject>>DoIt >>>> OpalCompiler>>evaluate >>>> OpalCompiler(AbstractCompiler)>>evaluate: >>>> SmalltalkImage>>evaluate: >>>> >>>> EvaluateCommandLineHandler>>no (source is Undeclared) >>>> no source in EvaluateCommandLineHandler>>evaluate: in Block: no source >>>> BlockClosure>>on:do: >>>> EvaluateCommandLineHandler>>evaluate: >>>> EvaluateCommandLineHandler>>evaluateArguments >>>> EvaluateCommandLineHandler>>activate >>>> EvaluateCommandLineHandler class(CommandLineHandler >>>> class)>>activateWith: >>>> >>>> BasicCommandLineHandler>>no (source is Undeclared) >>>> no source in >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in >>>> Block: no source >>>> BlockClosure>>on:do: >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >>>> >>>> BasicCommandLineHandler>>no (source is Undeclared) >>>> no source in PharoCommandLineHandler(BasicCommandLineHandler)>>activate >>>> in >>>> Block: no source >>>> BlockClosure>>on:do: >>>> PharoCommandLineHandler(BasicCommandLineHandler)>>activate >>>> PharoCommandLineHandler>>activate >>>> PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: >>>> >>>> PharoCommandLineHandler class>>no (source is Undeclared) >>>> no source in PharoCommandLineHandler class>>activateWith: in Block: no >>>> source >>>> NonInteractiveUIManager(UIManager)>>defer: >>>> PharoCommandLineHandler class>>activateWith: >>>> no source in BasicCommandLineHandler>>activateSubCommand: in Block: no >>>> source >>>> BlockClosure>>on:do: >>>> BasicCommandLineHandler>>activateSubCommand: >>>> BasicCommandLineHandler>>handleSubcommand >>>> BasicCommandLineHandler>>handleArgument: >>>> no source in BasicCommandLineHandler>>activate in Block: no source >>>> >>>> SmallInteger>>no (source is Undeclared) >>>> >>>> UndefinedObject>>no (source is Undeclared) >>>> >>>> AbstractCompiler>>no (source is Undeclared) >>>> >>>> SmalltalkImage>>no (source is Undeclared) >>>> >>>> BlockClosure>>no (source is Undeclared) >>>> >>>> EvaluateCommandLineHandler>>no (source is Undeclared) >>>> >>>> EvaluateCommandLineHandler>>no (source is Undeclared) >>>> >>>> CommandLineHandler class>>no (source is Undeclared) >>>> >>>> BasicCommandLineHandler>>no (source is Undeclared) >>>> >>>> BasicCommandLineHandler>>no (source is Undeclared) >>>> >>>> PharoCommandLineHandler>>no (source is Undeclared) >>>> >>>> UIManager>>no (source is Undeclared) >>>> >>>> UndefinedObject>>no (source is Undeclared) >>>> >>>> CommandLineUIManager>>no (source is Undeclared) >>>> >>>> SmalltalkImage>>no (source is Undeclared) >>>> >>>> DelayMicrosecondScheduler>>no (source is Undeclared) >>>> >>>> BlockClosure>>no (source is Undeclared) >>>> >>>> SmalltalkImage>>no (source is Undeclared) >>>> >>>> WeakArray class>>no (source is Undeclared) >>>> >>>> >>>> ps: source cannot be displayed because there is no formatter available >>>> in >>>> the bootstrap
