There is one case where assessing heap allocation is straightforward: the case where you don't do any.
The pools concept has been tried in other languages. The necessary region analysis, done conservatively, is not that difficult. The problem is that it *is* done conservatively, and there are cases that are pathologically bad. For this reason, pools do not replace GC effectively for many programs. > There are situations where a garbage collector is not desirable... I can name some, but they are *very* special cases, and nearly all of them are cases where a "zero allocations" policy is appropriate. The other extreme is cases where GC effectively becomes disk GC by virtue of paging, but that one is manageable by using an appropriately specialized runtime, and it is rare. I would be very interested to know which situations *you* have in mind, and *why* GC is inappropriate for those situation. > With this in mind, would it be possible to have a compromise between full GC > and no memory management (at all?) by using a pool allocator which is scoped > to a particular frame. Yes and no. The problem with this is that we need to do escape analysis on the values, and this requires general region analysis. Region analysis in turn introduces a level of annotation requirement on the code that we have been hoping to avoid. Assuming that region analysis is done, it is certainly not hard to introduce a stack-allocated pool "handle" to support explicit deallocation. Apart from this, however, the same region analysis has the effect of narrowing the scope for in-region GC. Once you know the lifetime of a region, and the fact that pointers into that region do not escape, it is very easy to identify the roots that point in to that region, and it is potentially simple to GC that region in isolation from other regions. > The challenge is ensuring closures don't escape their "scope". While our current escape analysis pass is badly boogered, determining the escape of closures is not intrinsically harder than analyzing any other escape. There is a type-based escape analysis methord. >I vaguely recall reading somewhere that when building in no-gc mode, BitC will >disallow certain features > in order to avoid heap allocation. That was the original plan, and that is what the compiler currently implements, but I have subsequently concluded that "noalloc" should be handled using effect analysis. Same end result, but the feature exclusion is done by the type checker rather than a magic mode. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
