On Fri, Aug 2, 2013 at 11:12 AM, David Jeske <[email protected]> wrote:
> On Fri, Aug 2, 2013 at 10:55 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> Because it never escapes, that temporary could be stack allocated. Region >> analysis can easily detect this, and allocating the temporary in that way >> reduces GC pressure. >> > > I'm looking for examples where regions help but CLR-like stack-based > value-types don't. > That's easy enough: there are *many* algorithms that use boxed types, and would be very inconvenient to transition to unboxed types. Among those, there are many examples where region-driven stack allocation is nonetheless useful and valuable. > In CLR this carry-case can easily be an out-argument value-type copy to > the caller's stack. > Not in the simple implementation, because the size of the outgoing value is statically unknown, and also because we don't know [statically] whether the storage for the carry is required at all. One way or another, we're stuck doing two allocations in at least *some* cases. But yes, an implementation using your approach could eliminate the second of the two allocations in the majority of cases. The catch is that doing so would preclude use of regions for cleaning up the temporary. > The thing is, because use of this kind of region might also require GC > inside the region, it's not clear to me that there is a useful general case > solution to this which is obviously better than generational collection. > In this case, the regions are being used to detect stack allocation, and we can see at static compile time that the region size is statically bounded and small. No GC should ever be performed on this region in a correct implementation. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
