Escape Analysis on reddit

[Steven Schveighoffer]

"Michel Fortin" wrote
> On 2008-10-31 22:47:59 -0400, "Steven Schveighoffer" <schveiguy at yahoo.com> 
> said:
>
>> Yes, my point in all this is, if we are going to 'solve' the scope escape
>> issue which today causes unnecessary heap allocations, let's not make new
>> syntax that makes things harder or impossible to do and *still* have the
>> heap allocation problem.
>
> But declaring arguments as scope solve the heap allocation problem, except 
> where not heap-allocating would create a bug because of someone keeping 
> the reference for too long.

What I was talking about is possible cases where it can be proven (with all 
source code available) that a heap allocation is not required, but the 
compiler will not let it compile unless it is heap-allocated.  Therefore, 
you have to do the heap allocation to get it to work.

So we would still have the heap allocation problem, but now you have to 
resolve it manually.

>
>> It's worth a lot, I agree.  But not at the cost of invalidating tested
>> efficient designs such as Tango.
>
> If you can't annotate Tango's code to be scope-correct, then there are 
> probably hidden bugs in there.

It depends on what 'scope correct' means.  If the syntax to annotate is 
expressive enough, then it should be possible in most cases.

Tango is used quite a bit, and most code has bugs, but generally, scope 
escape bugs are rare, and special care is taken by the devs to make sure it 
doesn't happen.

> If D scope syntax isn't expressive enough to annotate valid and efficient 
> designs, then the syntax is probably not well enough.

Yes, this is what I'm concerned about.

>
>> FWIW, I think with changes to the compiler/linker, this can be all 
>> detected
>> automatically without any extra syntax.  Consider that the linker 
>> currently
>> resolves dependencies of symbols.  It could also resolve incomplete 
>> escape
>> analysis graphs.  If the graphs don't match up, it's a linker error. 
>> This
>> would be needed in the case of interfaces and virtual functions.
>
> Here you're expecting the linker to perform escape analysis on comiled 
> code, a world where pointers, numbers and raw data are the same thing: 
> bytes and values in registers. That's probably a million times harder to 
> do than when working on the semantic tree of a D program, if that's even 
> possible.

I mean that the linker would be given a scope-graph metadata (in the object 
file), which contains simple dependency edges between parameters of 
functions and their return values.  The graph is generated by the compiler 
like you said, when working on the semantic tree.  The linker just resolves 
undefined vertices, connecting the incomplete graphs to see if the entire 
graph is valid.  It only makes sense for values that contain references, so 
code like this:

int f(scope int x)

should mean nothing to the compiler.  So the linker only has to worry about 
references, and doesn't really need to understand the types of the 
parameters, just where they can escape to.

-Steve