Hi Klaus,

Thanks for the information. We have modified the VM in order to reduce the  
GC activity inhibiting it until the fileIn processes are done, but had no  
luck. The produced files were different with less differences.
We think we have to follow an approach similar to yours. We thought to  
generate a serialized file with all the CompiledMethods we use, without  
change the base image, merging them only when squeak starts up. We hope  
that this process does not demand too much time, since we have also a lot  
of resources to bring up at that time :S

Regards,
Martin

On Mon, 30 Jul 2007 13:22:08 -0300, Klaus D. Witzel  
<klaus.witzel at cobss.com> wrote:

> Hi Martin,
>
> there are a lot of objects (like, for example subinstances of  
> ContextPart) allocated and deallocated on which you do not have much  
> control.
>
> One corner from which this could be started is to consider enumerating  
> (in two sister .images) all the objects you want to deploy. If that  
> fails to produce comparable objects (for any reason, for example if you  
> cannot order/compare object identities other than by hash identity and  
> the latter is assigned by the VM and not by you) then, hrm, it fails.
>
> But if not then you could trace out all the objects you want (thereby  
> disacrding all the unwanted) and the resulting (two sister) .image files  
> then have the same contents byte by byte, because you fix the object's  
> position in the files. I've done that with other images and  
> non-Smalltalk interpreters.
>
> Having said that, your project doesn't look to be easy.
>
> /Klaus
>
> On Mon, 30 Jul 2007 17:31:43 +0200, Martin wrote:
>
>> Hi All,
>>
>> We have tried to produce the same (bit identically) image file after two
>> consecutive snapshots. We start from a base image then, fileIn several
>> files into it and finally, we just SmalltalkImage current snapshot: true
>> andQuit: true. We need this to verify the image file generated by a
>> third-party with a checksum by executing a script.
>> After trying several ways to get it (even by scripting the fileIn  
>> process
>> and the snapshot), we found that the image files have, beside the
>> timestamp differences, thousands of other differences and sometimes the
>> snapshots have also size differeces.
>> We supose that this kind of issues may occur due to the GC activity.
>> Are this issues from the way GC process is changing dynamically the  
>> memory
>> bytes? There is a way to inhibite this activity?
>> Attached are the scripts we use to produce the image files.
>>
>> Many thanks in advance,
>> Martin Troielli