The short answer to your question is.... Most of the GC papers out there over-promise through the imprecision of language or narrow domain-specific techniques. Including the paper you referenced (see below).
You and I are among the few, even on a PL list as geeky as bitc, who care very much about the nitty gritty details of GC. Most here are focused on PL and typing issues (which I completely respect) and trust that GC people will solve GC problems eventually. I think the lack of a strong GC community may also be in part because GC implementations are so runtime specific, making it hard to get a critical mass of GC interested folks who also care about the same run-time. Witness the emptiness which is the Mono-GC-List <http://lists.ximian.com/pipermail/mono-gc-list/>. IMO, the most cutting edge general-purpose GC techniques are true pauseless tracing-collection (no world stop), and the integration of GC and software transactional memory. High-performance low-latency applications need to tackle not only GC pauses, but parallelization -- and because of the nature of compacting collectors and transactional memory elements there may be a benefit to solving them together. Here are a couple of my favorites: "C4: The continuously Concurrent Compaction Collector <http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf>" "A Unified Theory of Garbage Collection <http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf>" "Concurrent GC leveraging transactional memory <http://dl.acm.org/citation.cfm?id=1345238>" "Concurrent Programming with Revisions and Isolation Types <http://research.microsoft.com/pubs/132619/revisions-oopsla2010.pdf>" --- As for the specific paper you referenced... "Memory Efficient Hard Real-Time Garbage Collection" -- I admit to only skimming it, but it was very un-remarkable. With respect, that paper could be re-titled "Hard Real-Time Reference Counting, with static collection analysis". Their short section on cycles tries to suggest a "new technique", object aging, which appears to me to be isomorphic with generational mark-sweep. "RTRC does not completely replace the competitive techniques, since RTRC > has some problems when it comes to cyclic data structures. Even though both > manual and automatic approaches to handle cyclic data structures are > presented in Chapter 4, some systems may contain too much cyclic data > structures and be too complex to handle manually to benefit from RTRC."
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
