This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Generational Scavenging of Store
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
GC'ing the Store database is similar but not exactly the same as GC'ing objects in Smalltalk. The end goal is not exactly to reclaim disk space used in the Postgresql database (at least, not yet), but simply to provide a pool of objects that are relevant. In other words, we want to separate the garbage from the current "warm" stuff, but what we do with it differs.
One of the (many) mechanisms employed by many GC systems is generational scavenging. Part of this process involves moving objects from bucket to bucket based on their tenure of existance. Why not do the same with Store?
In the analog, periodically a new OpenRepository is created. As people find stuff they want in it... they replicate it from the previous repository. Creating a new Postgres database backend alongside the existing one is trivial. Like 2.5 minutes of sysadmin time. Desirable packages are replicated forward, "garbage" is left behind. Anyone who shows up wondering where that one package he really wanted is, can go back to the older repositories and get it (and possibly replicate it forward). In this way nothing is lost.
But when to create new versions? I can't think of a better time than at each VW version release. Now this gets powerful. The current repository has a grand mishmash of packages built against VisualWorks versions 5i.something through alpha 7.3. It's not just that there's a raft load of unmaintained stuff, or that people like to use the OR as a staging grounds, but that you can't even know what a given package is relevant to! Having a major repository version which tracks the VW versions simplifies this greatly. Debian users should recognize this policy.
Having proposed that, it really sounds more like the two space flip mechanism, extrapolated out to N temporal spaces.
Previous Topic
