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
|