I want to step back from the GC/Regions discussion to point out a couple of things.
We're dealing with two very distinct goals here: 1. Memory safety 2. Reclamation of memory with acceptable pause bounds The only issue that I really feel strongly about in this is the first one. The second one, to my knowledge, simply doesn't have a universal solution. GC is a means to the first goal, and in some cases the second. Regions are an occasionally useful optimization on that means. Regions are particularly important for mostly-allocation-free libraries. But these aren't the *only* mechanisms, and it is reasonable to examine compromises on the second goal. Such as: - Deferring reclamation (regions) - Failing to accomplish some reclamation (cycles in ARC-based schemes) - Deferring ARC cycle collection to a backing GC, accepting temporary heap leaks as the cost of this practice. - Type-aware heaps using explicit free, such that type-safe aliasing with allegedly, but not provably non-live pointers might occur. - Linear typing, which can be viewed as a form of ARC-at-compile-time - Linear borrowing (to coin a term) which allows us to go from mutable to deep-frozen and back to mutable DAGs or DCGs in some cases. All of these choices, and probably others, are appropriate for some programs. I'm not taking a position on which ones should be used for a given program. Some of them can be built as libraries. Those, in my view, should not be embedded in the language. Of these, I personally think that ARC and variants of linear typing are the most promising tools I can see in the near term. In several cases, the thing I would *really* like to be able to distinguish is some notion of a "sub heap". Specifically, I'd really like to be able to say "this here reference slot that lives in sub-heap X will always point to some other object in sub-heap X. If we can get to that, then I think we can solve the cycle problem in many cases.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
