Escape analysis

[Steven Schveighoffer]

"Bill Baxter" wrote
> On Tue, Oct 28, 2008 at 10:54 PM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>>
>> What I'd prefer is allocate closure when you can prove it, allow
>> specification when you can't.  That is, allocate a closure automatically 
>> in
>> simple cases like this:
>>
>> int *f() {int x = 5; return &x;}
>>
>> And in cases where you can't prove it, default to not allocating a 
>> closure,
>> and allow the developer to specify that a closure is necessary:
>
> So basically programmers have to memorize all the rules the compiler
> uses to prove when it's necessary to allocate a closure, and then run
> those rules in their heads to determine if the current line of code
> will trigger allocation or not?

First, the compiler does not have any sound rules for this.  It currently 
allocates a closure on a knee jerk reaction from taking the address of a 
stack variable.  And its either this or substitute in your statement "prove 
when it's *not* necessary to allocate a closure", which is about as hard and 
probably 10x more common.

Second, for 90% of functions that don't require you to allocate closures, 
you don't have to think about any rules.

For the 9% of functions which return a pointer to local data, proven by the 
compiler, you don't have to think about rules.

For the last 1% of functions, the documentation should clarify how your data 
can escape, and then you have to think about how that affects your usage of 
it.  The docs could say 'best to allocate a closure unless you know what you 
are doing'.

> And when the compiler gets a little smarter, the programmers need to
> get smarter, too.  In lock step.

Not really.  If the compiler can some day store the scope dependency 
information in the object file (and get rid of reading source to determine 
function signature), then this whole manual requirement goes away.

> That doesn't sound like a good solution to me.

Then let's go back to D1's solution -- no closures ;)

For example, NONE of tango uses closures (as evidenced by the fact that it's 
D1), and it uses pointers to stack data very often (to improve performance). 
So if closure-by-default is the choice, then I'll have to mark all these 
usages as non-closure, which is going to make the whole code base look 
awful.

With the way Walter is thinking of implementing, it might be impossible to 
specify correctly.

-Steve