Current Status

Tue Feb 16 15:38:00 GMT 1999

> Does the bytecode compiler perform any optimizations?

Not much. Mainly constant folding. One reason is that bytecode
is emitted from the internal tree representation, but most of the
hardcore gcc optimizations are done on the lower-level rtl
representation. There are long-term plans to do more Gcc optimizations
at the tree level, but that won't happen for a while.
> Are loops unrolled,

No.
> methods inlined,

No. It is very limited you can do in terms in inlining of reasonable
Java code without violating the access specifiers and hence producing
invalid bytecode. It doesn't seem worth it to me. Better to inline
when compiling to native code, either using gjc or a JIT (i.e.
*after* verification).
> etc, within the bytecode? If so, this is an excellent reason to
> start using GCJ,

In general, gcj -C produces decent but not great bytecode. It is
comparable to Sun's javac; in some respects we are better, in some
worse.
Of course the emphasis of this project is on producing fast
native code, not fast bytecode, so working on bytecode optimization
has low priority.
> as no other bytecode compiler that I am aware
> of performs any optimizations.

There are I believe stand-alone bytecode optimizers. I've seen a
few research papers, but I haven't actually tried such an optimizer.
	--Per Bothner
Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner