writeImageFile() without snapshot()?

Dan Ingalls Dan at SqueakLand.org
Wed Oct 26 16:41:23 UTC 2005


Andreas wrote...

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

I tuned into this discussion a bit late, but this is close to what I was going to recommend.

Here are some thoughts...

1.  Given a stable application running for hours, I would *not* expect compaction to require a lot of movement after one or two full GCs.  The old objects should just pile up at the bottom of memory, and the compaction phase shouldn't take much longer than that of an incremental GC.  If this is not happening, then I'd say it's worth a little research.

2.  I thought we had code around to reconstruct the roots table from the root bits.  If so, it should be possible to just do an incremental GC and then save the image, *provided* that that image is somehow flagged as requiring root table reconstruction (this sounds like something my dentist does) before resuming.

3.  The one argument against tenuring is that it causes creep toward a full GC.  So if you keep tenuring, you will have to do a full GC from time to time.  Whereas, I'm assuming that a stable server application will run essentially for ever without a full GC being necessary (if someone has added gratuitous tenuring somewhere, you may want to turn it off).  If you can avoid tenuring, you should be able to avoid the worst case latency.

4.  If you have access to the copy-on write logic, there ought to be a way to write only the altered pages in subsequent saves.  This would make for a much quicker checkpoint, but it will also leave you with a messy save format to decode when you want to restart from that checkpoint.  It's the kind of thing the OS itself ought to do for you.  Really ;-)

Ciao
	- Dan



More information about the Squeak-dev mailing list