Storing Squeak Images in mercurial
bert at freudenbergs.de
Fri Sep 28 08:00:47 UTC 2007
On Sep 28, 2007, at 9:15 , Hans-Martin Mosner wrote:
> Keith Hodges schrieb:
>> It would be advantageous for storing binary diffs if images did not
>> change much between snapshots.
>> I seem to remember some mention that the image may have its pointers
>> updated and so this would not be the case.
>> can anyone fill me in on the details?
>> Would it be possible to save or post process a "sorted" image to take
>> full advantage of a repository which uses binary diffs?
> Assuming that most unchanged image content should be within the oldest
> parts of an image, which accumulate at low memory addresses, there's a
> Images are mostly a snapshot of the object memory, with all addresses
> kept as they are. When re-loading an image at a different memory base
> address, all object pointers get updated by the difference between old
> and new base. It should be relatively easy to move a saved image
> file to
> memory address 0 (I think the interpreter simulator does this). Two
> related images with the same base address probably have only small
> differences in the lower memory addresses. I have not tried this,
> but it
> could work.
Interesting idea, yes, that should work.
Or, we could move to an object table. Awfully nice, these ;) Solve so
many issues - one of them being object references that do not have to
be relocated on startup.
Another idea I have been pondering for a while is making the lower
part of Squeak's object memory be "constant". There is a large number
of objects in an image that virtually never change but are only read.
This part does not have to be garbage-collected, making a full GC
much cheaper. When we fork off a new system process with the VM using
copy-on-write pages, this part could be shared between images,
reducing the over-all memory consumption significantly.
- Bert -
More information about the Squeak-dev