[squeak-dev] 4.6/5.0 -- how to help users manage different formats?

Eliot Miranda eliot.miranda at gmail.com
Sat Mar 14 12:32:10 UTC 2015


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?



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



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150314/9d59f4f3/attachment.htm


More information about the Squeak-dev mailing list