This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: The problems with StringBuilders...
- From: Radu Racaru <radu dot racaru at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: David Daney <ddaney at avtrex dot com>, GCJ Hackers <java at gcc dot gnu dot org>
- Date: Tue, 4 Oct 2005 17:09:09 +0300
- Subject: Re: The problems with StringBuilders...
- References: <4341BA40.4020701@avtrex.com> <17218.20752.604872.475685@zapata.pink> <768a7cef0510040636n5fa75b34ue7746eb8d8099904@mail.gmail.com> <17218.35124.598779.272054@zapata.pink>
- Reply-to: Radu Racaru <radu dot racaru at gmail dot com>
On 10/4/05, Andrew Haley <aph@redhat.com> wrote:
> Radu Racaru writes:
> > Escape analysis is an old item on the gcj todo list, fortunately
> > I've seen it working in Excelsior JET to say that it really does
> > what it should do regarding the performance.
>
> Ah, that's interesting. What do they do with inheritance? Perhaps
> methods have to be final to be analyzed, or they do whole-program
> optimization?
they have a paper here http://www.excelsior-usa.com/pdf/StackAlloc.pdf
and more here
http://www.excelsior-usa.com/publications.html
>
> > Sun has implemented the escape analysis logic in their new 1.6
> > version, the first fruit to come is simple lock coarsening
> > (backported to 1.5_05) followed by uncontended synchronization and
> > stack allocation. I really like to see this technique build on gcj
> > (gcjx)
>
> Sure. We know how to do most of this stuff, but...
>
> Andrew.
>