On Tue, Jul 30, 2013 at 1:39 PM, David Jeske <[email protected]> wrote:
> For the sake of clarity, my mental model is a CLR extension for a strictly > hierarchical region system, where every box knows its region, heap pointers > are only allowed to point within the same region or a parent region, > root-set/stack borrowed pointers may point to any region and thus establish > the liveliness for a region. If there are no root-set/stack pointers to a > region, it is dead and can be reclaimed. I also assume there is a global > C4-class-GC running over all regions (though one could GC subregions > independently). > I think it's also useful to add a notion of region-based "borrowed" references. A borrowed reference is guaranteed not to be the last reference to an object. In consequence, overwriting a borrowed reference cannot reduce the live set. Mainly useful to show when GC cannot help. They should be region-based because that makes them significantly more flexible. > (1) web-server / request processor - we would use a region for each > (threaded) web-request handler. This could offer us more prompt, more > efficient reclamation than GC-tracing, since it would be known the region > was collectable as soon as the stack-frame exited, without any tracing. > Yes. It also creates sub-scopes for collection in the event that those regions *do* need to be collected. > Other uses? > Yes. One that is somewhat subtle, but causes a lot of allocation in low-level libraries. There are a bunch of cases where interior pointers cannot be returned safely unless you have a region-based type system. In languages that require memory safety, the usual workarounds are (1) return a dynamically allocated copy, or (b) add indirection in the original data type so that you can share substructure. Eliminating this class of allocation is very helpful. There are a bunch of examples of this in the early Cyclone and Popcorn papers. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
