Taking a trip into the memory basement, I came up with the Dr. Dobb's Journal for April 2000, where Joshua W. Burton discusses "various" GC algorithms and implementations. That article also references a DDJ Dec. 1997 article by Mike Spertus.
Joshua is/was a software engineer at Geodesic Systems (the makers of Great Circle AFAIK).
The focus of the article is on incremental garbage collectors with low latency, as latency is the biggest problem faced by GC nowadays. In terms of raw speed, an atomic collector (like "mark and sweep", where in one pass, all unreferenced memory is marked, and in the second pass, all marked memory is released for recycling) will always be the fastest, but on the other side, you have the latency problem, that for example "mark and sweep" will always take a certain amount of time.
An implementation that suggests low latency is Reference Counting, but even here you (can) have cascades of memory releases, pushing up the latency.
The article then moves on to describe a coloring collector, which colors memory into three categories (for any given moment) :
- black - live and fully scanned
- grey - known live but not yet fully scanned, may contain more pointers
- white - the objects whose liveness is in doubt
A collection begins with the root set gray and everything else white. The collection is finished when there is no more grey stuff left. Everything that remains white at the end of collection is garbage and can be released whenever the collector wants. The collector maintains a list of scanned pages and tracks all writes to it (a write to a scanned grey or black page makes rescanning that page necessary). This algorithm can also be interrupted without having to start from the beginning, if you have a mechanism (like CPU-level page locking) to be notified when a write to a scanned page occurs.
| [reply] |
I'll admit that I have no real experience with garbage collection (outside Perl) and little technical knowledge of it. I'm just going by what was referenced in the request itself. One was a 1998 survey that, under "Mark and Sweep" says:
"As with all tracing schemes, once GC is started, it has to go through all the live objects non-stop in order to complete the marking phase. This could potentially slow down other processes significantly, not to mention having to stop the requestor process completely."
You must be talking about something other than "mark and sweep" (which is what the suggestion proposed) or your definition of mark and sweep doesn't match that of the survey.
If this is using concepts that are 20 years out of date, then a link to more appropriate reference material would be appreciated.
| [reply] |