need to focus on java performance?

[Tom Tromey]

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.

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.

Per> One thing worth considering is "whole-package" compilation: a
Per> compilation option to say that there are no other classes in
Per> the package(s) we're currently compiling.  That means that we
Per> know all references to any default-access (package-private)
Per> fields, methods, and classes, which could enable some worthwhile
Per> optimizations.

This idea has come up before.

Unfortunately it isn't clear to me that we can successfully optimize
this and maintain the BC properties needed by the big java programs
out there.  The issue is that all instance fields and methods still
need that extra layer of indirection.

We do pay for our approach in 2 ways that I'm aware of.  One is that
we compile everything PIC.  The other is that BC itself comes with a
pretty big price -- 15% if I remember correctly.  That is a lot of
overhead to have to overcome.

Tom