After I wrote the previous about region allocation, it occurred to me that there is a potentially useful special case.
The main problem with regions is loops. If you have a loop with an allocation inside it, all of the allocations performed within the loop tend to end up in the same region, but aside from a few variables that survive across the iteration boundary, most of the results computed in pass n are dead by pass n+1. So you'd like to GC those, but the region hasn't exited so region-based collection cannot reclaim them. However... The usual region subtyping relationship is based on nested lifespans. That is: it's a stack-like mechanism (ignoring first-class regions here). We don't want to implement the region storage on the stack itself, because region sizes can be fairly large and there can be intervening allocations. But it's perfectly possible to implement the region stack separately from the call stack, and it is also possible to keep a region-specific set of roots. If this is done, then it should be possible to perform a compacting micro-collection of the current "top" region in such a way that the reclaimed space can be allocated easily. This certainly isn't the same as turning off GC, but it *may* give enough control over the GC-imposed latency to serve the needs of some algorithms. Unfortunately, it appears to work only for single-threaded algorithms. :-( shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
