Storing Squeak Images in mercurial

Bert Freudenberg 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
> possibility:
> 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 mailing list