David: Regions may not solve the problem that you are obsessing about right now. :-) And the problem you are obsessing about is definitely important.
But "region, effect, and escape" inference is the underlying formalism that justifies stack allocation, and also the underlying formalism that justifies borrowed pointers. I agree completely that stack allocation is a different problem from the one you are presently concerned about. I think my view goes more like this: given that we clearly need to do region analysis for *those* purposes, it's worth thinking a bit to see what other problems we can exploit that work to manage. The tenured churn problem isn't one of those problems, *but* Detecting the *difference* between tenured churn and stable object sets with changing inter-object references helps us reduce the scanning workload on the "churned heap". *If* that's possible, it's a benefit, because it reduces the effective size of the heap we have to scan. It still may not be enough to solve the problems that are currently of interest to you. On Sat, Aug 3, 2013 at 10:08 PM, David Jeske <[email protected]> wrote: > > The trouble and place this starts to break-down for me, is that very > quickly we want scoping more narrow than a specific parent call-stack. For > example, if looping on some bignum operations, we don't necessarily want > all the carries from calls to survive for the duration of our stack-frame, > but we do want them to survive one, maybe two, maybe three iterations of > some expression evaluation loop. > > It's this "maybe one, maybe two" part that bothers me. Pretty quickly > we're either determining reachability, or we're holding onto them too long. > Yes. This "one, maybe two" problem is an example of a region whose size is not statically boundable. Such regions may indeed need GC, though it's at least a very fast, generational-style GC that does not have to consider pointers from tenured space to new space. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
