On Fri, Jan 22, 2010 at 5:51 PM, Martin McClure <[email protected]>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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
