>
> Yes. With the experiment of Tobias, the #writeSnapshot: and #loadDefinitions
> took only 1% of the whole process.....so…
the problem is
- classbuilder
- logging
- …
so we should go step by step
>
> Now, for that radical change you mention, we have started to think a little
> bit:
>
> 1) we need to store the source code anyway. This is because we would need to
> recompile all CompiledMethod (because of instance variable accessing
> bytecodes) when the superclass of a class which is in the image changes it
> shape (hence, instance variables moved their index). For this purpose, we
> thought we can easily store the source code in the method trailer and
> serialize that. The thing is at materialization. What do we once we have
> materialized? we keep the sources in teh CM or we put them in the .changes
> file and we put back a .changes pointer in the trailer??? should a load of a
> package always store in .changes ?
>
> 2) Since we materialize classes without class builder, and this monster does
> everything together, we need to analyze what has to be done exactly when
> materializing a package for example: notify class creation/modification,
> validations (what happens if the class already exist, etc.), etc, etc. This
> is the most difficult part for us, since understanding what the classbuilder
> does is complicated....
>
> Our progress is in FuelPackageLoader...
>
> Cheers
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
