Diego Novillo writes:
> Andrew Haley wrote:
>
> > http://www.research.ibm.com/people/g/gupta/escape.ps
> >
> > But I probably wouldn't recommend you to do it in a gcj-specific way.
> > gcj is merely the Java language front-end for gcc, and there may be a
> > plan for escape analysis that will suit all gcc's languages that can
> > use it.
> >
> Oh, excellent. It's been in my wish list for a while. I agree with
> Andrew, this analysis should not be done in the individual front ends.
> At worst, I could envision langhooks if we needed to get some
> FE-specific information.
>
> Choi's paper is a good start. I remember it being quite reasonable, but
> I am not aware of recent results in the literature. We already have
> some primitive (well, embarrassing) support for determining escape
> points. See tree-ssa-alias.c:is_escape_site.
I remember the weird thing about that paper (it's been a long time
since I read it) is that it didn't talk much about inheritance. It
seems to me that inheritance is one of the greatest problems for an
object-oriented language...
> Essentially, a good escape analysis technique should probably be
> incorporated at that point. I have not yet thought about the details,
> but I'd be happy to help with the implementation.
In theory it doesn't look all that difficult do do in the simple
cases, but a good implementation would need a lot of knowledge about
the way the class library behaves, and therefore what might escape. A
database, I suppose. But just a skeleton implementation that does a
few simple things would be nice.