This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Question on compiling to bytecode
Jim White wrote:
I don't know what specific optimizations that GCJ could make on Java
source that it wouldn't make on Java bytecode, but I'm skeptical that it
would have a material effect in most applications.
The main one historically is loop optimizations: Gcc doesn't infer
loops from the control flow, but depends on the front-ends annotating
the intermediate RTL code. This is fixable - and for all I know has
been fixed. Another issue is initialization of arrays, which is
more a space optimizations.
If a particular
sequence is identified, it would be a straight forward matter to adjust
Kawa's compiler, GCJ's optimizer, or to use a bytecode tuning stage.
I agree.
As far as Java bytecode performance goes, beware of assuming that
because it is doing static compilation that GCJ is delivering superior
performance. My understanding is that Sun's Hot Spot JVM (which is
available without charge in the JDK and JRE) is typically faster (apart
from bytecode loading/compilation time) than GCJ.
It varies. GCJ is faster on some benchmarks and slower on others.
Finally, be sure that you've actually got a working system (or at least
the part that is performance critical) before expending resources on
tuning performance of the language engine or libraries. There are
almost always large tuning options with better return-on-investment that
a little profiling will illuminate directly.
This is most important. The difference between Kawa->Java->native using
GCJ, Kawa->classes->native using GCJ, and Kawa->classes->HotSpot is
likely to be minor in the big picture. If not, it is hard to predict
until you have a working prototype.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/