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