In modular systems programming, I can see the validity of escape inference for stack/region optimization only if the functions are fully internal or this inference is performed as part of the run-time JIT.
However, if we wish no-escape to be a trustable property of a module export, it needs to be explicitly committed to by the module author with some form of borrowed pointer argument (such as with CLR "ref", or Rust "&"). Likewise, a module export has no visibility into the escaping of return values, since it's callers are unknown when the module is compiled and packaged. On Mon, Aug 5, 2013 at 6:40 AM, Jonathan S. Shapiro <[email protected]>wrote: > What I think you mean to be saying is that there is no way to *explicitly* > stack-allocate > an unboxed type *in the CLR*. If it were designed to do so, the JIT > engine is certainly free to perform the region analysis that is necessary > to do what you are describing. > Clarification... In CLR you can stack-allocate an unboxed scalar or struct by declaring it as a stack variable. What you can't do is (safely) stack-allocate unboxed arrays or dynamically stack-allocate unboxed types. This requires unsafe/stackalloc. > Curiously, doing that wouldn't require *any* changes to the GC (except > perhaps removing a sanity check), *even* if no borrowed pointer type is > introduced. > Isn't CLR "ref" already a borrowed pointer type? It seems like they could have abstracted "ref" onto local stack variables and allowed the following code safely.... struct Bar {} ref Bar[] foo = stackalloc Bar[10]; However, this would quickly push down a Rust-like path, where we'd want authors to decide between "ref" and "non-ref" pointer types intelligently. Seems complicated. Laslly even if the benefit of regions themselves is low the analysis which >> pushes more types automatically onto the stack is a win .. since it makes >> the GC heap smaller and uses the faster stack allocation scheme. >> > > Umm. Bennie? How do you push those objects on to the stack without doing > the region analysis necessary to know that it is safe? > I think he was saying... "Region analysis is good even without separate region heaps at all... because it helps you move heap objects onto the stack."
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
