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
|