Escape analysis (full scope analysis proposal)

Michel Fortin michel.fortin at michelf.com
Tue Nov 4 03:54:31 PST 2008


On 2008-11-03 11:21:08 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Michel Fortin wrote:
>> On 2008-11-03 00:39:34 -0500, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> said:
> [snip]
>> If you want more details, I can provide them as I've thought of the 
>> matter a lot in the last few days. I just don't have the time to write 
>> about everything about it right now.
> 
> It may be wise to read some more before writing some more. As far as I
> understand it, your idea, if taken to completion, is very much like
> region analysis as defined in Cyclone.
> 
> http://www.research.att.com/~trevor/papers/pldi2002.pdf
> 
> Here are some slides:
> 
> http://www.cs.washington.edu/homes/djg/slides/cyclone_pldi02.ppt

Pretty interesting slides.

Yeah, that looks pretty much like my idea, in concept, where I call 
regions scopes. But I'd have made things simpler by having only local 
function regions (on the stack) and the global region 
(dynamically-allocated garbage-collected heap), which mean you don't 
need templates at all for dealing with them. I also belive we can 
completly avoid the use of named regions, such as:

	{
		int*`L p;
		L: { int x; p = x; }
	}

The problem illustrated above, of having a pointer outside the inner 
braces take the address of a variable inside it, solves itself if you 
allow a variable's region to be "promoted" automatically to a broader 
one. For instance, you could write:

	{
		int* p;
		{ int x; p = x; }
	}

and p = x would make the compiler automatically extend the life of x up 
to p's region (local scope), although x wouldn't be accessible outside 
of the the inner braces other than by dereferencing p.

If the pointer was copied outside of the function, then the only 
available broader region to promote x to would be the heap. I think 
this should be done automatically, although it could be decided to 
require dynamic allocation to be explicit too; this is of little 
importance to the escape analysis and scopre restriction problem.


> My hope was that we can obtain an approximation of that idea by defining
> only two regions - "inside this function" and "outside this function".
> It looks like that's not much gain for a lot of pain.
> 
> So the question is - should we introduce region analysis to D, or not?

I think we should at least try. I don't think we need everything 
Cyclone does however; we can and should keep things simpler.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/




More information about the Digitalmars-d mailing list