On Fri, Jan 22, 2010 at 5:51 PM, Martin McClure <martin@hand2mouse.com>wrote:
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. Wow. I haven't looked at the binary format; I had assumed from
what little code I'd read that it was more machine-independent than that. And the format should be defined at the Smalltalk level, not in the VM. But, again, to me the defining quality of ImageSegment isn't what format is used, it's what you can do with it, especially how you define what objects are in the ImageSegment.
Right! cheers Eliot
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project