On Fri, Aug 2, 2013 at 8:20 AM, Matt Rice <[email protected]> wrote: > On Sat, Jul 27, 2013 at 1:29 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> The *disadvantage* of first-class regions is that you have an explicit >> new() operator. This can lead to unbounded allocation within the region >> (e.g. inside a *for* loop), and in turn can induce a requirement for >> region-by-region GC. >> > > I suppose this makes me wonder about weak regions, which seems somewhat > conflating issues as typically you consider weak references (not weak > objects). but if one can surmise that if the references to a region are > only weak, you could at least avoid the regionional gc there, >
Umm.. I don't think so. If all references into a region were weak, then none of the objects in that region would be live. > ...this appears a failure to satisfy the LIFO lifetime guarantees of > regions... > Strictly speaking, LIFO is too strong a constraint. The actual requirement is that there be a subtype relation on regions, which is satisfied by having a partial order. It's pretty common to imagine all of this happening on the stack, which leads to a simplifying mental assumption that everything is LIFO. It's perfectly fine for region i to have multiple child regions j0 j1 ... jn that are live at the same time. What *tends* to be true is that j0 j1 ... jn will live in the same stack frame, and are "collected" by the exit of that stack frame. In that case j0 j1 ... jn don't have usefully distinguishable lifespans, and it's easier to imagine them as a single region. *However* when region polymorphism is introduced at procedure parameters and return values this becomes less clear. Objects in a caller region can now be manipulated by a callee. The lifetime of a region is still bounded by the stack frame in which it is allocate [*], but it's no longer easy to point at a single stack frame and say "that's the [single] frame in which this region can be touched". In any case, LIFO isn't strictly required, and while it makes inference more difficult, the partial order doesn't need to be a *complete* partial order. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
