Conclusion first this time, try to resist the temptation to counter-point before reading the rationale below.
Conclusion.. The reason I continue to be un-sold on regions, is two-fold, (a) cases seem to very quickly degenerate into situations where some amount of sub-reclamation would be beneficial, and (b) generational collection and the young-generation is already really-fast, really-efficient, and solves this problem in a flexible and more general way. In other words, I don't see regions solving a problem with GC which is practically trouble-some today. IMO, the problematic GC cases are the big heap and tenured churn. Rationale.. > > - Allocate a result word-vector whose size is the larger of the input > sizes, plus an extra word for potential carry-out > > I see and accept this case where temporary yet variable sized (and thus dynamically allocated) data must survive for the lifetime of some *parent* call stack, not our own. 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. Thoughts I have to about region-like mechanisms creating dual-classes of pointers quickly start to look like non-general forms of generational garbage collection. Since young-generation scavenge is actually the fast, great, and working part of generational GC theory, I don't understand what fire regions are putting out.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
