Brian T. Rice
water at tunes.org
Tue Apr 16 15:45:08 UTC 2002
On Tuesday, April 16, 2002, at 02:56 AM, goran.hultgren at bluefish.se
> I wrote some posts about ImageSegments (that I use at SqueakDot btw:
> http://anakin.bluefish.se:8080/squeakdot/) a while ago, I copied them in
> Ok, an ImageSegment contains all objects that are ONLY reachable from
> it's roots.
> It uses the GC algorithms in a smart way by essentially withholding the
> roots in question
> and doing a mark from all other roots (globals). This will leave the
> objects in memory
> that are only reachable from your segmentroots unmarked.
So basically the rule is to take care not to have variables assigned to
an element of your collection directly, assuming that I have code that
determines that a whole section of data is not needed at the time. Now
obviously it still works if I do, but the remaining directly-referenced
elements will still be in the image with the collection out to disk.
>> Also, if I want to dump and image segment to disk and read it back in
>> *not* as a project, how do I do it? Is it worth doing?
> Sure! There are basically two ways of using an ImageSegment. One can be
> used for "object swapping" like this,
> below is a method from an "account" object I have:
[snipped interesting useful code]
> This would "swap out" the object and replace all references with
> autoloading stubs. It works like a charm!
> And especially loading it back in is FAST.
Ok, so loading back in is transparent and quick. Great!
> Here is some code for using ImageSegments for export into possibly other
> images that I recently whipped up:
> "Export me using an ImageSegment. Return nil on fail.
> This is used for checkpointing the account on disk
> in a form that can be brought into an independent image.
> We do not overwrite older versions - when the image does a
> snapshot it can purge old checkpoints."
> | is fname myParent dir stream |
> myParent _ parent.
> lastCheckPoint _ TimeStamp current.
> dir _ self dir.
> fname _ dir nextNameFor: self fileName extension: self
> stream _ dir newFileNamed: fname.
> [ parent _ nil.
> is _ ImageSegment new.
> is copyFromRoots: (Array with: self) sizeHint: 1000000 areUnique:
> is writeForExportOn: stream ]
> ifError: [parent _ myParent. ^nil].
> parent _ myParent.
> The method above nils out a parent pointer but that is just to "make
> sure" - I don't think it is needed. The sizeHint is good to set high
> because otherwise there will be
> numerous "tries" when dumping large structures and that takes a lot of
> The writeForExportOn: method wraps the ImageSegment in a ReferenceStream
> in order to gracefully deal with the outpointers.
I see! Thanks for the sizeHint tip, that would probably have me guessing
for a while.
> This needs a new simple method in ImageSegment to work:
> writeForExportOn: fileStream
> "Write the segment on the disk with all info needed to reconstruct it
> in a new image. For export. Out pointers are encoded as normal objects
> on the disk."
> | temp |
> state = #activeCopy ifFalse: [self error: 'wrong state'].
> temp _ endMarker.
> endMarker _ nil.
> fileStream fileOutClass: nil andObject: self.
> "remember extra structures. Note class names."
> endMarker _ temp
> And this is how I load them back, a method in my account class (on the
> class side):
[snipped loading method]
> In order for the above code to work I also needed a method in
[snipped useful utility method]
> Well, perhaps it helped!
It definitely did. You should submit these two added methods as ENH.
> And... you can see this stuff "in action" at SqueakDot - just sign up,
> go to "My SqueakDot", play with "checkpoint" and "account analysis". You
> can also see some code by clicking on "source for this page" at the
> bottom of most webpages.
I had tried it at one point, and thought it was very interesting, but to
be honest I'm waiting for some kind of framework over it so that I have
some starting point for an application.
> regards, Gˆran
Thanks, this was very helpful!
More information about the Squeak-dev