Re: need to focus on java performance?

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > Per> I know Tom has been experimenting with
 > Per> some optimization passes, and I think that is a good start.
 > 
 > FWIW I haven't actually done any measurements of the results of these
 > passes.  I suspect they aren't that important :-(.  (Of course it is
 > hard to know without really doing the test, since distributed overhead
 > like this is hard to measure with things like oprofile.)
 > 
 > Andrew has been doing a lot of profiling and tuning lately.
 > 
 > The "indirect classes" patch was a consequence of this.  As I recall
 > his observation was that GC is about 25% of the runtime on his test
 > application; this patch lets the GC scan much less memory, resulting
 > in a big improvement.
 > 
 > Hmm.. just yesterday he mentioned a breakdown of the top
 > performance-busters on the phone, and I've already forgotten :-(.  I
 > thought there was some data out on the web somewhere but I can't seem
 > to find it atm.  Maybe it was private email.  Anyway it can "easily"
 > be collected by oprofiling an eclipse or jonas run.

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.

The most important thing about gcj performance is that we aren't
hampered by a lack of ideas to improve it.  We're hampered by a lack
of people to do the work.

For example, there is one real piece of low-hanging fruit: array
bounds check elimination.  This is 99% done, but it still doesn't work
with gcj.  This is because the aliasing code in gcc needs to be made a
little bit smarter about handling read-only fields.  I have been
thinking for a long time that I'd do this myself, but I never have the
time.  That's the *real* problem -- not a lack of ideas about how to
make things go faster.

Andrew.

[1]  Characterizing Java(TM) Application Performance, Ghulam Lashari,
Suresh Srinivas.   http://www.cis.upenn.edu/~lashari/performance.pdf