need to focus on java performance?

Mon May 22 15:48:00 GMT 2006

Andrew Haley wrote:
> The top performance-busters for the large-scale gcj apps I've tried
> (jonas and eclipse, mostly) are:
>> 1. garbage collection
> 2. stack traces
>> Big java apps often seem to spend almost all of their runtime in
> libraries, particularly libgcj. So, while clever compilation
> techniques may be good for microbenchamrks, they may not be quite so
> good for applications. It's important to concentrate on what
> applications do, and not obsess about code generation minutiae unless
> profiling warrants it.
>> > Oh, I remember. Stack trace generation is a big loser for us. We've
> > talked several times about if and how we can change stack traces and
> > the exception implementation to have better performance. The current
> > approach was designed for C++, the tradeoffs are really wrong for
> > Java. In particular in C++ exceptions are assumed to be rare, but in
> > Java they are common.
>> This is a well-known gotcha for JIT compilers too. In a well-known
> paper about Java code generation [1] it is implied that the overhead
> of unwinding DWARF is so great that JIT-compiling can sometimes reduce
> performance.
>> I discovered something very interesting yesterday: Valgrind translates
> the DWARF info into a much faster form at load time. This doesn't
> make much sense for C++, but it makes a lot of sense for java. We
> could lift that code, or the idea, and put it into gcc's unwinder.
>
I imagine that most of the stack traces are needed for security checks, 
and not exceptions.
If stack traces are really done so much, would it make any sense to 
compile all code with a frame pointer, and walking those instead of 
using the DWARF unwinder? In the recent past that was done on many 
archetectures. Perhaps changing it was a mistake.
David Daney