Eliot Miranda wrote:
>
> � � Parcels are wonderful things, but my impression is that ImageSegment and
> � � parcels are designed to do rather different things. Parcels are used for
> � � physical delivery of packages (primarily code), whereas ImageSegments
> � � are for arbitrary graphs of objects (primarily not code, although some
> � � folks have tried to use ImageSegments for code). If parcels are designed
> � � to be more general than package delivery, I'd like to hear about it.
>
>
> You're talking abut parcels expression in VW not their underlying
> nature. �Parcels' underlying nature is just efficient unpacking of
> object graphs. �The code stuff is layered above that, so much so that it
> obscures the essentials. �Parcels are at core another pickling format,
> but one that is very much faster than standard approaches. �My
> comparisons of BOSS (VW's Binary Object Storage System, very similar to
> ReferenceStream et al) and Parcels showed parcels to be 4 times faster
> than BOSS.
>
> Basically you get out of a parcel what you put in, and in VW parcels get
> code put in them. �But you can put arbitrary objects in parcels. �Note
> that parts of the parcel marshalling code is used in Opentalk.
Thanks, that's good to know.
>
> � � I suspect that the only VM support that ImageSegments really need are
> � � the mark-sweep primitives to discover what objects are in the
> � � ImageSegment. All other algorithms, file format, etc. can (and maybe
> � � should) be redesigned to be better, but using the GC to find the objects
> � � is the heart of what ImageSegment is.
>
>
> The core problem is that an image segment is a raw binary snapshot of a
> part of the heap, so a particular VMs object header formats and tagging
> scheme is built-in to the segment. �If I were to evolve the Squeak
> garbage collector and object representation to make Cog significantly
> faster, as I fully intend to do this year, image segments will at least
> break backward compatibility. �They can only be exchanged between VMs
> running exactly the same object representation. Parcels can be loaded
> into very different systems; VW loads parcels into either 32-bit or
> 64-bit images without difficulty, and parcels written before
> immutability or ephemerons were added could be loaded after.
>
> So for me image segments are too low-level and constraining.
Really?
Look at Interpreter>>primitiveLoadImageSegment and Interpreter>>primitiveStoreImageSegment in VMMaker.