Responding to all of this in haste, because I'm swamped this morning. Raoul: The Bacon work is excellent, and I need to read it more carefully - especially the concurrency part - but the 2.4ms pause times shouldn't have to be that high. The URC work is also good. For BitC, we're looking at something more similar to the C4 collector or the Stopless collector. Doing the Bacon approach really well requires a really good optimizer, which we won't have for a long time. I want a truly concurrent solution. You may want to do a google search on "bitc-dev garbage collection" to find the previous threads. There were a bunch of long discussions about six months ago.
Sandro, David: I disagree somewhat about the simplest model. I'm not aware of *any* GC model in which release is guaranteed to be prompt for non-memory resources. If nothing else you can end up with a bug that preserves a *reachable* cycle, and that stuff will *never* get released. The ONLY correct model is explicit release for such resources, and once you do that it no longer matters what the GC framework is where that issue is concerned. Because of this, I feel that something like unwind-protect or try-catch-finally is really important to have. There *are* a few programs that aren't covered by that, but those have to be written with care no matter what you do. For all of these reasons, the notion of releasing resources in the finalizer should be viewed as a last-gasp recovery measure rather than a primary means of resource management. Raoul: A drop-in replacement for Boehm isn't just a matter of an API. There are a whole bunch of issues that qualitatively change the mark phase, and there are a lot of GC techniques you can use in safe languages that cannot be used in C. People like Boehm because it's simple. Hans is really smart, and he's done an excellent piece of work. But my experience has been that Boehm works exceptionally badly on the kinds of codes where it would be nicest to have: large server codes. It also works very badly as the percentage of the heap virtual address space in use crosses about 20%. Somewhere just below there the false aliasing effects become insurmountable, and it becomes effectively impossible to collect *anything*. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
