Actually the VM has an optimization where as for example on the  
macintosh the memory start value for the oops space "usually" when using
the same VM is at the same virtual memory address. If so and this  
matches the remembered memory address then no swizzling of the object  
pointers is needed.

Otherwise all object addresses are swizzled with an offset so that  
the object pointer which is the 32/64 bit memory address matches  
expectations using the last offset versus the new offset.

I'll note that more secure operating systems, say OpenBSD ensure the  
memory addresses allocated from application startup to startup don't  
follow a pattern so on that
operating system it's likely the startup address would never be the  
same as any previous startup.

Therefore it's plausible that one *could* swizzle the address from  
the starting offset to zero after the image has been fully GCed and  
halted .

See ObjectMemory>>adjustAllOopsBy:
for thoughts
and Interpreter>>writeImageFile:
for placement to swizzle to zero, then back to the original value.
	

PS I have a dim memory of someone wanting to abuse the low bits in an  
object pointer because they decided for example the oops space could  
never be allocated below say
ox00000000XX because the operating systems usually allocate from  
memory after the VM binary...


On Sep 28, 2007, at 12:15 AM, 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.
>
> Cheers,
> Hans-Martin
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===