writeImageFile() without snapshot()?

John M McIntosh johnmci at smalltalkconsulting.com
Fri Oct 7 20:32:08 UTC 2005


On 7-Oct-05, at 12:49 PM, Avi Bryant wrote:

>
> On Oct 7, 2005, at 12:08 PM, Andreas Raab wrote:
>
>
>> You can *not* get away without a GC, simply because the GC state  
>> isn't preserved across snapshots. We actually had some obscure  
>> crashes related to this problem in the past (anyone remember the  
>> crashes caused by the root bit being set on the active context  
>> after a snapshot?)
>>
>> In other words, the full GC is required to save the image in a  
>> well-known "right-after-full-gc-state". One would (at least) have  
>> to save sufficient information for the garbage collector to make  
>> this work. Likely other fixes too, since a full garbage collect  
>> cleans up many, many things that we usually don't even think about  
>> (cached contexts for example).
>>
>
> Ok, thanks, good to know.
>
> Now, it should still work to do what Tom was suggesting, right?  Do  
> the fullGC in the parent process, then immediately fork and  
> snapshot  (without doing a second GC in the child).  Does the order  
> of, eg, #storeContextRegisters: and #fullGC inside #snapshot: matter?
>
> Avi

If you do the fullGC, then the fork and snapshot which also does a  
fullGC, then cleans up context records and information about  
primitive linkups you
should find that the amount of memory altered is much less. The  
problem with doing a snapshot at any point is that it most likely  
will move *most* memory
in the image as it compacts the image as a result of the full GC.  
Back to Back full GCs won't move anything (depending on if the  
interpreter runs between calls).
Thus altering much less memory.

However isn't there a cost here in the parent process of doing the  
fullGC, those take time.


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




More information about the Squeak-dev mailing list