This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: implementing escape analysis


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.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]