Hi eliot
On 14.03.2015, at 13:32, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> On Thu, Mar 12, 2015 at 3:56 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> Hey Eliot,
> 
> On 12.03.2015, at 17:44, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> >
> > The problem with image segments is that they are in the format of the VM's heap objects.  However, Bert and I want co co-mentor a project to implement image-level support for loading segments from "foreign" object memories.  Alas GSoC did not approve our organization this year.  Maybe soon.  Or maybe some student at one of the teaching institutions using Squeak or Pharo would be interested in having a go.
> 
> Can you or Bert give me an outline or a heads up?



> An ImageSegment is a WordArray whose contents are a sequence of heap objects in the VM's native object format.  A segment is loaded by invoking a primitive that swizzles the pointers in the word array so that they become valid objects, and then shortening the word array, leaving the objects behind in memory.  Since the contents of the WordArray are specific to a given VM architecture one cannot use the primitive loading mechanism to load segments from VMs with different object representations.  Here different means 
>     - 32-bit V3 vs 64-bit V3
>     - the contents of the CompactClassesArray (if they're not the same in the saving and loading system, objects could be loaded with the wrong class, which could crash the VM)
>     - V3 vs Spur
>     - Spur 32-bit vs Spur 64-bit
> 
> But there is no reason why Smalltalk code could not parse the contents of the WordArray and hence load objects by creating them based on the data in the WordArray.  This would allow image segments to be loaded in any format the Smalltalk code supported (and it would be interesting to compare performance and see how much slower "synthesized" loading would be).  This would provide legacy support for segments from "old" versions, and maybe even provide a oath to adopting a more neutral format such as Fuel.
> 
> To implement such a system one would have to understand the object formats of each system, using the VM source code as a guide, both the object representation and the load and save primitives themselves.
> 
> Does this answer your question?
> 

Yes. Thank you :)
I'll see whether some students could work with that… (no promise tho)

Best
	-Tobias

>  
> (maybe off-list…)
> 
> Best
>         -Tobias