To balance my skepticism about first-class regions, I decided to spend some time thinking and articulating what practical applications regions could be *good for* and what there limits might be. I hope this is useful/appropriate.
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'm going to wave my hands at the fact that CLR does not allow borrowed pointers (refs) in on-stack value types (only arguments) -- I don't think it's material. (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. We need to know all in-region objects which must be finalized, since they could hold OS resources which need teardown. If the number is small (which it typically is), we could manually track them to avoid scanning the region. Seems like a win vs processes or apartment threading, since we not only get the prompt/quick teardown of those systems, but we also get trivial shared-data through access to the parent region. (2) database - we would use a region for each client context to hold query and cursor context. Arguments much the same as above. I think per-request data private data tends to be smaller here, because of the need for locking and coordination among different requests. I'm not sure this is much of a win. (3) 3d authoring application - we could use regions for large temporary indexing data-structures related to a temporary editing context. Segregating their state into a region would allow faster and frequent GC of just that sub-region, especially useful because there is more churn in this editing state than the whole program dataset. Further, when the editing context ends, the region can be promptly declared dead without tracing the entire program heap. The details of the root-set reference mechanisms can be important here. (1) We need to return the UI thread to the main event loop, so these references will either need to be held in a frozen continuation on the main UI thread, or a separate thread which is activated when necessary. (2) sometimes these datasets are cached, in case they are used again soon. This would demand some flexibility in the root-set reference. (we need to be able to create, hold, and release sub-regions in arbitrary orders) Doing this in a particular stack frame is practical. (4) web browser - Chrome today is already running page-contexts in separate processes for security reasons. Within a process, the generated page-context could be held in a region. This would allow the process to be quickly flushed-and-reused without tracing the heap to determine liveliness, while keeping IPC and other data-structures in the parent region in-tact. VS a traditional heap, there would be increased costs for same-region-assignment checks, and tracking finalizers. The former would probably be more expensive than the latter, but worth it, as web sessions are often very short lived. Like in (3), there is value in control over the order of multiple sub-region creation/hold/release, so we can decide when to cache and when to drop existing contexts. Doing this in a specific frame is practical. Other uses?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
