On Mon, Jul 29, 2013 at 10:41 PM, David Jeske <[email protected]> wrote:
> stop-the-world GC is an achilles heel > V8 lack of support for concurrent shared data is an achilles heel > Rust's lack of concurrent data (I think because of the mechanics of owned > pointers) is an achilles heel > V8 lack of support for types is, in my view, a more basic achilles heel. Concerning support for concurrent data and concurrency, this was an Achilles heel of BitC as well. I definitely recognize the importance, and you know that I put some work into typing immutability. That said, I haven't seen a language-level concurrency model that seems universal enough to be the "right" concurrency model to bless into the language. This is, admittedly, a failing. It seems that any choice will polarize the user base, and I don't feel that I understand the issues well enough to make a good choice on this. LRU caches are real programs! However, I accept your implication that > specific one-off algorithms can be hand-coded in unsafe or manual-RC if we > must. > Actually, that *wasn't* my implication. What I was saying was that an LRU cache is a relatively small portion of a larger program. Looking at the LRU cache alone isn't very meaningful. > > >> My problem with ARC is that I don't know how to type acyclic data >> structures, and ARC isn't resource-safe (because it can exhaust memory) >> unless we can type that. >> > > Programs which allocate are not resource safe, because they can exhaust > memory. > Yes. But programs that *intend* to exercise resource discipline can very easily build inadvertent cycles. We actually got bit by this in the BitC compiler. For various reasons, the AST structure has a parent pointer, and there are cross-pointers between declarations and definitions. Each of these creates a cycle. Turns out *none * of them (not even the parent pointer) can be weak pointers or borrowed pointers given the way we use the data structure. ARC wouldn't work for us. > Anything long-running with tenured churn is not solved by regions, > especially with dependency graphs. > More generally, things that have large heaps with tenured churn are *the* challenge case for GC. It's not the duration of the program so much as the size of the tenured live set that is being churned. Regions *do* help in some cases, because they let us GC distinct parts of the heap separately. But they aren't a general resolution. Regions are more useful on things that stay close to the stack, most notably inner references, stack allocation, and eager collection of temporaries. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
