On Mon, Aug 5, 2013 at 12:35 AM, Bennie Kloosteman <[email protected]>wrote:
> Shap , > > Wouldnt you just use a seperate stack like memory structure rather than > the actual stack ? You wouldnt want to increase the default stack size and > risk over flows ( unless very small) . What is the gain by putting it on > the stack ? Is the locality of data with variables worth it ? > That boils down to an implementation decision. There are basically three choices: (1) implement all statically sizable regions in the stack itself, or (2) build a parallel region stack, or (3) use a hybrid solution. Barring some impediment originating in the run time environment, it will be more efficient to stack-allocate any in-region object whenever possible. It eliminates the need to manage a second stack when the region size is static. In addition, on many processors, management of the primary stack is supported directly by the instruction set. Finally, as you say, there are locality advantages. On platforms where alloca() is present and useful, it also makes sense to stack-allocate any statically bounded number of dynamically sized allocations (e.g. you are allocating vectors, but we can see that you will allocate at most two of them). The argument for doing this is essentially the same as the argument for using alloca() in unsafe code. In practice, a couple of issues can get in the way: 1. You need to respect the platform-dependent bounds on alloca() in general. 2. In multi-threaded code, stack allocation may increase the stack size that needs to be reserved for each per-thread stack. Both of these are potential concerns, but integrating regions with the conventional stack doesn't really make these issues any worse than they were before. What it comes down to is that the stack frames get bigger. That's all. When the compiler sees [conservatively] unbounded in-region allocation, or when non-presizable allocation in a region hosted by stack frame A may be performed in a younger stack frame B, then the region cannot live within stack frame A. At that point you have to go do a parallel region stack having dynamic "frame" sizes, or you can just give up and allocate those objects from the GC heap in the normal way. If you do that, you won't get 100% of the hypothetical stack allocation benefit, but you'll get the majority of it. Allocation of dynamically sized objects isn't that common, and *unbounded* allocation of such objects is even less so. Taken together, you won't end up falling back on allocating in the GC heap very often. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
