writeImageFile() without snapshot()?

John M McIntosh johnmci at smalltalkconsulting.com
Sat Oct 8 00:58:30 UTC 2005


Actually a bit cleaner usage would be to use the
forceTenureFlag

set to true before doing the incrementalGC.
it's looked for and reset in the GC logic.

Also see
primitiveForceTenure

On 7-Oct-05, at 5:37 PM, Andreas Raab wrote:

> Avi -
>
> Try this: Instead of "self fullGC" in primSnapshot, try inserting:
>
>     "DISCLAIMER: This requires some careful review which I
>     don't have the time for right now. This is NOT working
>     or tested code so don't even think of submitting this
>     to VMMaker unless you actually understand why this ought
>     to work and what differences there possibly might be
>     between a full GC and an incremental GC + tenuring."
>
>     savedThreshold := tenuringThreshold. "remember prior threshold"
>     tenuringThreshold := 0. "reset tenuring threshold"
>     self incrementalGC. "force tenuring"
>     tenuringThreshold := savedThreshold.
>
> This may already be enough since tenuring will clean up the roots  
> and thus leave the image in a stable state. But of course, it does  
> require the image to perform a full GC if you want to reclaim space  
> before the snapshot.
>
> Cheers,
>   - Andreas
>
> Avi Bryant wrote:
>
>> On Oct 7, 2005, at 4:09 PM, John M McIntosh wrote:
>>
>>> Of course if you have a  spare GB or two, you could do the  
>>> fullGC  ask for a block of memory, copy start of memory to end of  
>>> memory  there, then write that out
>>> at your leisure, that forgoes the need for fork and the like.   
>>> Assumes of course you can ask and get 500MB at no cost.
>>> Surely the write happens quite quickly on modern high-speed disk  
>>> i/ o machines tho?
>>> Seems to me if you're wanting to minimize downtime you fork and  
>>> do  a snapshot, that as noticed takes upwards of image size to do.
>>> Otherwise as you say full GC, fork for the write, but does that    
>>> save anything?
>>>
>> The scenario is that you have a server packed with large images  
>> that  you want saving to disk periodically.  So mostly what I'm  
>> trying to  optimize is memory usage, but without unreasonable  
>> delay by the  standards of web applications.  The two options that  
>> take more or  less constant memory seem to be a regular snapshot,  
>> or GC->fork- >snapshot.  For a largish image (100-200MB), a GC  
>> takes maybe 2s  (acceptable, if annoying) whereas a snapshot takes  
>> maybe 15s (pretty  much unacceptable).  So the forking seems like  
>> the right choice.   Though if we could get rid of the GC  
>> altogether that would be great...
>> Avi
>>
>
>
>
>

--
======================================================================== 
===
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